Hi, I spent some more time looking at the getty/inittab problem when running inside systemd-nspawn.
The issue boils down to needing a getty on /dev/console, since systemd-nspawn gives limited access to the base system and thus /dev is very sparsely populated. Only very few things inside /dev gets bind-mounted in (in addition to what debootstrap created in your chroot to begin with which is also very sparse). In addition to this, even if you add an inittab line that spawns a getty on /dev/console you'll still have the problem of getting annoyed by the messages about gettys on /dev/tty* respawning too fast (because /dev/tty* doesn't exist, except for /dev/tty). I'm not sure if inittab provides flexibility enough so that there is a 'one size fits all' solution. Maybe my inittab-fuu is just weak though and someone else can come up with a solution. It would really be nice to have a working "out of the box" solution but having atleast an example with a description of what to add and remove related to systemd-nspawn inside /etc/inittab could be helpful (similar to how there's an example on how to use serial gettys). I wonder how much most people will care about fiddling to get sysvinit running and assume most will probably jut give up quickly. Maybe a solution could be to have some higher level tool, like mkosi, have a template for sysvinit that installs sysvinit-core plus sets up /etc/inittab for use with systemd-nspawn to give people a way to create a testable chroot with a single command. Regards, Andreas Henriksson
