On Thu, Oct 23, 2014 at 08:49:20PM -0700, Cameron Norman wrote: > On Thu, Oct 23, 2014 at 8:13 PM, Josh Triplett <j...@joshtriplett.org> wrote: > > On Thu, Oct 23, 2014 at 10:21:27PM -0400, Sam Hartman wrote: > >> >>>>> "Josh" == Josh Triplett <j...@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 -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141027144303.GA1984@jtriplet-mobl1
