Bug#858211: systemd: uninterruptible wait if swap is missing, even in rescue boot

[Michael Biebl]

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20170319/079d005d/attachment-0002.sig>