Hi Joey, Joey Hess <jo...@debian.org> writes: > Version: 44-12 Note that we also have 204-2 in experimental. It’d be interesting to see if the failure mode has changed in that version.
> But for entirely different reasons; I have no encrypted filesystems to > fail; in my case a locally written /etc/network/if-up.d/local was trying > to start aiccu when lo came up, which basically deadlocked things. > (I did not bother waiting 5 minutes to see if systemd would time it > out.) I tried reproducing your issue by creating /etc/network/if-up.d/local containing "#!/bin/sh\nsleep 5d" and making it executable, but my machine boots fine (with systemd 204, though). Could you provide the precise contents of that file that lead to the lock-up please? Also, just in case we still cannot reproduce the issue afterwards, could you boot with systemd.log_level=debug (and without quiet) and provide the output? You can dump it using dmesg once you actually reach a shell, which should be a matter of letting it time out. Also, booting with systemd.confirm_spawn=1 might be helpful. It will ask you for confirmation before spawning each unit, so this should help you figure out which unit precisely is the problem here. > 1. With the default "quiet" boot parameter, systemd outputs very little > useful information. > But, d-i started adding "quiet" to grub command lines only to suppress > verbose and generally not useful kernel messages; the intent was not > to make the init system so quiet that the user can't tell what's > going on! This can easily be fixed by adding systemd.show_status=1 to the cmdline. Given that d-i does not install systemd by default, this is a manual step currently. > 2. Why does networking need to come up before gettys are started? My > laptop has no network filesystems. The only failure mode that should > prevent a getty from being started should be a fsck failure or root > filesystem mount failure, which should lead to a recovery shell. > Systemd has failure modes where no shell is started. The getty service file has no dependency on the network. > The combination of these behaviors yields a system that fails shut; > it can't easily be debugged without an arbitrary amount of complication. Well, that is a bit of an exaggeration :). There is http://freedesktop.org/wiki/Software/systemd/Debugging/ which describes a number of steps that you can take to end up with a running system and/or get more information about what failed. > (Now happily running systemd for the first time. README.Debian > seems out of date re su exit code being busted by PAM, and lightdm works > which it didn't used to.) Indeed, thanks. I’ve fixed this with http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=commitdiff;h=6ae0edf -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
