Hi Lorenzo, On Mon, Jan 09, 2023 at 02:39:25AM +0100, Lorenzo wrote: > This need to be adjusted in the initcripts package, as a quick fix I'm > going to add a dependency on e2fsprogs too.
Would you be able to go the longer route and make initscripts handle this in a better way? Given that you can simply press ctrl-d, I think this does qualify as non-rc severity. When the next report with a btrfs comes along, will you add a dependency on btrfs-progs? > > > > So I went on to retry with e2fsprogs added and this is what I got: > > > > | Begin: Running /scripts/local-bottom ... done. > > | Begin: Running /scripts/init-bottom ... done. > > | [ 1.484294] Not activating Mandatory Access Control as > [...] > > | Cleaning up temporary files.... > > | Cleaning up temporary files.... > > | - runit: leave stage: /etc/runit/1 > > | - runit: enter stage: /etc/runit/2 > > | runsvchdir: default: current. > > > > In particular, the user has no way to log into the system as no getty > > is being spawned. I see that the autopkgtest has to do this manually > > via "ln -s /etc/sv/getty-ttyS0 /etc/service/". Do you think there > > could be a better way to achieve this such that at least the console= > > kernel command line parameter is automatically issued a getty? > > This one is a separate issue: true that a serial-getty is not > automatically started (there are gettys on tty[1-6] for standard usage) > but a getty-ttyS0 service that can be enabled and tuned to the right > device exists, so I don't think that this last part is RC.. Sure there > is no documentation on how to do it and anyway there is room for > improvement. I've opened a separate (#1028270) bug for the "no way to > login" issue above, if you disagree with the non-RC severity of > #1028270 please change the severity of that one as I'm going to close > this one by adding two dependency to runit-init. I mostly agree. Let's turn this bug into just the mount dependency only and handle the other issues at non-rc severity. As for becoming an init alternative, I suggest going the same route that systemd went: documenting a way to boot with runit by providing a init=... kernel command line parameter and have it mature that way a little longer. Keep in mind that the init package was not added to gain choice, but it was a tool to ease the transition from sysvinit to systemd. init is not essential and nothing depends on init (the package), so runit-init can be used without being an alternative there. Helmut
