On Mon, Apr 14, 2025 at 09:32:55PM +0200, Andras Korn wrote: > On Mon, Apr 14, 2025 at 05:45:48PM +0100, Andrew Bower wrote: > > > On Mon, Apr 14, 2025 at 04:28:36PM +0200, Andras Korn wrote: > > > During a dist-upgrade, the getty-run package was pulled in, and a(n > > > IMO misleadingly named) getty-ttyS0 service enabled by default. > > > > IMO the system should not start anything on a serial port without user > > configuration > > (Incidentally, I agree, but this bugreport is about something else.) > > > A simple remedy to this issue would therefore be to configure this > > service 'down' by default until enabled by the user. > > Or just install it but don't symlink it into /etc/services.
Yes, I think that would be the preferred way - saves a running runsv instance. > (I submit that it's easier to fix a system that you can't log into because > you realize after a reboot that there is no getty than a system you don't > want to reboot just now that you can't get into because there are two > concurrent gettys.) > > > However, it does seem a bit harsh to rate this as critical as this > > service was also enabled by default in bookworm and the system does need > > to have been configured by the user already for the reported scenario to > > occur, in which case the superfluous service could have been disabled. > > My justification for "critical" is that this runit service was enabled > automatically and that it "broke the system" (fsvo). > > With that said, if you think it should be downgraded, I won't object further. I'm just another user commenting, not the maintainer - I'll leave it to him to triage! But it's a sensitive time for raising critical bugs with the trixie freeze as we don't want runit cut out of the release! :-) > Re bookworm: this particular system uses sid and was upgraded frequently. The > console login functionality wasn't tested frequently; for all I know it > could've been broken for years. I see.
