Am 19.03.2017 um 21:22 schrieb Nathan Dorfman: > Package: systemd > Version: 232-19 > Severity: normal > > Dear Maintainer, > > Boot is delayed for 90 seconds if swap partition configured in fstab can't > be found. > > A few things make this unreasonable: > > 1. I can't interrupt the wait. ^C should work here, as it does with legacy > init. On the other hand, at least Ctrl+Alt+Del works.
Since systemd starts everything in parallel, which service should ctrl+c apply to? > 2. I have to wait even if I'm booting in rescue mode (via the default grub > entry created by debian-installer). Booting directly to a rescue shell > shouldn't need to wait for swap at all. Actually, it's faster to reboot into > Tiny Core Linux, fix the fstab from there, and reboot into graphical debian > than just to wait for our own rescue shell :( See man systemd.special. The rescue.target does wait for all file systems specified in /etc/fstab. What you want is emergency.target for a case like yours. > rescue.target > A special target unit that pulls in the base system (including > system mounts) and spawns a rescue > shell. Isolate to this target in order to administer the system in > single-user mode with all file > systems mounted but with no services running, except for the most > basic. Compare with > emergency.target, which is much more reduced and does not provide > the file systems or most basic > services. Add "emergency" or systemd.unit=emergency.target to the kernel command line for that. > 3. If fstab specifies a UUID, I guess it's semi-plausible that we're waiting > for the swap device to be hot-plugged (heh). However, the wait is the same > if /dev/XdaN is specified directly. The attached fstab specifies /dev/vda5. > We know it doesn't exist. Root is already mounted from /dev/vda1, so I don't > think any hot-swapping is possible. What exactly are we waiting 90 seconds > for, at this point? It waits for the device to show up. A heuristic which concludes from the device name whether a device still can show up or not sounds very brittle to me and thus not a good idea. > Also, one thing that might or might not be wrong: > > 4. After the delay, multiuser boot proceeds normally, and there seems to be > no indication that anything is wrong. Shouldn't it drop to rescue instead > of proceeding with boot? If not, shouldn't there at least be an alert? I've > seen wall(1)-style messages from systemd before; maybe they'd make sense here. For missing swap devices it does not drop you into rescue mode. Missing file systems on the other hand will trigger rescue mode. I assume this is a reasonable choice. The error will show up in the journal, fwiw. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
