[2018-11-12 22:54] Andreas Henriksson <andr...@fatal.se> > 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. > [...]
There is already number of versions of `inittabs'. Well, those in `debian/share/' are chooses at package build time. I have no idea what is `systemd-nspawn', but my wild guess is that we can: * just add /usr/share/inittab.systemd-nspawn * create seperate binary packages bin:inittab and bin:inittab-systemd-nspawn Opinions?
