Bug#765803: Status of prompting / notification on upgrade for init system switch?
On Thu, Oct 23, 2014 at 08:49:20PM -0700, Cameron Norman wrote:
> On Thu, Oct 23, 2014 at 8:13 PM, Josh Triplett <josh@joshtriplett.org> wrote:
> > On Thu, Oct 23, 2014 at 10:21:27PM -0400, Sam Hartman wrote:
> >> >>>>> "Josh" == Josh Triplett <josh@joshtriplett.org> writes:
> >>
> >> Josh> - It can't check for generated lines for serial consoles or
> >> Josh> similar; finish-install can generate various additional
> >> Josh> inittab lines, which the check should include.
> >>
> >> Since when did systemd actually handle these correctly?
> >> I've generally found that systemd will give me a serial console only if
> >> the kernel console is that serial console.
> >> I've found that if I manually enable a serial console but have the
> >> kernel console go somewhere else, I end up with a system I cannot log
> >> into when I upgrade to systemd.
> >> This has been no end of frustration and I hope that your check correctly
> >> prompts in this case even when the line I generate is exactly the
> >> same as a line generated by the installer.
> >>
> >> If it's gotten better and I'd actually get a console in that case,
> >> that's of course fine too.
> >> It should either let me know I'm about to hurt myself or work:-)
> >> Either behavior is fine.
> >
> > TTBOMK, you'll automatically get a console on a serial port in a few
> > cases:
> >
> > - If the kernel console points there (console=ttyS0); note that this
> > works even if you change that console.
> >
> > - If the console is identified as a default system console (works for
> > virtual machine serial ports, and for systems with unusually named
> > standard console serial ports).
> >
> > See systemd-getty-generator.
> >
> > In other cases, you have to manually "systemctl enable
> > serial-getty@ttyX.service".
> >
> > I wonder if it might make sense to do a one-time migration that parses
> > /etc/inittab, looks for serial console getty lines, and enables
> > serial-getty@.service for any consoles it finds gettys for?
>
> If you are going to the work of parsing it all, would it not make
> sense to make a systemd generator out of it?
I didn't suggest attempting to handle all of inittab, only serial
console gettys. A generator would have to deal with several additional
issues that a one-time migration of specific bits would not.
Almost everything in the default inittab duplicates systemd
functionality, and it would not make sense to translate those lines
across with a generator: default runlevel, sysinit, single-user-mode,
invoking /etc/init.d/rc, invoking sulogin, the default ctrl-alt-del
handling, the powerfail handling, and the default gettys on ttys.
Keyboard requests could make sense to translate to
kbrequest.target.wants units. Modified ctrl-alt-del or powerfail lines
might or might not make sense to translate. Any runlevel-specific
service that isn't a getty or /etc/init.d/rc *might* make sense to
translate. And it isn't at all obvious how to handle services or gettys
specified for non-default runlevels; starting them could be dangerous.
So, any working inittab generator would have a pile of special cases to
skip over parts of the default inittab, which seems complex,
error-prone, and not particularly user-friendly.
Instead, I think it makes sense to scan inittab for serial console
lines, possibly limited to only those that run in the default runlevel.
Even that could potentially cause problems, but nonetheless it seems
worth doing to transparently work on systems where the user has a serial
console that for some reason isn't specified as a console on the kernel
command line.
- Josh Triplett
Reply to: