[systemd-devel] failing boot start jobs delay reboot

[Felix Miata]

Has anything been done in more recent releases about this? I do a lot of
cloning, and sometimes produce typos on grub cmdlines and fstab lines. This
produces long delays in init followed by emergency mode when the
non-essential mount fails and fstab for that device does not include the
nofail option. When I recognize early in init that I have made a fstab typo,
I try to CAD to choose another boot choice that isn't broken and fix the
typo, but that produces yet another start job wait for the same broken job,
often followed by a gazillion failed to save sound card state messages from
holding down CAD.

openSUSEes, Mageias & Fedoras (including Factories, Cauldrons & Rawhides)
comprise most of my installations subject to these self-inflicted delays that
I can't recall being a problem with sysvinit.

[Andrei Borzenkov]

В Mon, 19 Jan 2015 17:59:41 -0500

Post by Felix Miata
Has anything been done in more recent releases about this? I do a lot of
cloning, and sometimes produce typos on grub cmdlines and fstab lines. This
produces long delays in init followed by emergency mode when the
non-essential mount fails and fstab for that device does not include the
nofail option. When I recognize early in init that I have made a fstab typo,
I try to CAD to choose another boot choice that isn't broken and fix the
typo, but that produces yet another start job wait for the same broken job,
often followed by a gazillion failed to save sound card state messages from
holding down CAD.
openSUSEes, Mageias & Fedoras (including Factories, Cauldrons & Rawhides)
comprise most of my installations subject to these self-inflicted delays that
I can't recall being a problem with sysvinit.

"Self inflicted delays" during boot or during Ctrl-Alt-Del?

[Felix Miata]

Post by Andrei Borzenkov

Post by Felix Miata
Has anything been done in more recent releases about this? I do a lot of
cloning, and sometimes produce typos on grub cmdlines and fstab lines. This
produces long delays in init followed by emergency mode when the
non-essential mount fails and fstab for that device does not include the
nofail option. When I recognize early in init that I have made a fstab typo,
I try to CAD to choose another boot choice that isn't broken and fix the
typo, but that produces yet another start job wait for the same broken job,
often followed by a gazillion failed to save sound card state messages from
holding down CAD.
openSUSEes, Mageias & Fedoras (including Factories, Cauldrons & Rawhides)
comprise most of my installations subject to these self-inflicted delays that
I can't recall being a problem with sysvinit.

"Self inflicted delays" during boot or during Ctrl-Alt-Del?

Both. When they occur during init they repeat during shutdown. Even when I
let init complete and succeed to fix the typo or oversight, the init failure
gets remembered and repeated at shutdown. Often the start job is on account
of a volume label that has been replaced, usually along with a UUID, because
the clone is a partition on the same HD. Fedora is particularly frustrating
by embedding dependent root volume label and not obeying root= on cmdline
(openSUSE obeys root=). Those typos usually have to be fixed by chroot to run
dracut.

[Andrei Borzenkov]

Post by Felix Miata

Post by Andrei Borzenkov

Post by Felix Miata
Has anything been done in more recent releases about this? I do a lot of
cloning, and sometimes produce typos on grub cmdlines and fstab lines. This
produces long delays in init followed by emergency mode when the
non-essential mount fails and fstab for that device does not include the
nofail option. When I recognize early in init that I have made a fstab typo,
I try to CAD to choose another boot choice that isn't broken and fix the
typo, but that produces yet another start job wait for the same broken job,
often followed by a gazillion failed to save sound card state messages from
holding down CAD.
openSUSEes, Mageias & Fedoras (including Factories, Cauldrons & Rawhides)
comprise most of my installations subject to these self-inflicted delays that
I can't recall being a problem with sysvinit.

"Self inflicted delays" during boot or during Ctrl-Alt-Del?

Both.

Back upon a time initscripts used delays as well waiting for devices
to appear. I think later it was basically converted to wait for
udevsettle. For usual end user system udevsettle does not do much and
so is more or less instant.

I'm not sure whether this will be feasible today as default solution.
You could try experimenting with adding x-systemd.device-timeout=1s to
/etc/fstab and forcing udevsettle before local-fs-pre.target.

Post by Felix Miata
When they occur during init they repeat during shutdown. Even when I
let init complete and succeed to fix the typo or oversight, the init failure
gets remembered and repeated at shutdown.

Yes, that's the problem. For once, traditional workflow of

- stop in emergency shell when mount fails
- fix /etc/fstab
- ^D to continue boot

no more works, because /etc/fstab is not reevaluated so systemd will
still try the same broken mount again. Also I have observed delays
during shutdown/reboot /probably/ triggered by failed mounts but am
not sure how to reproduce them. If you have simple step by step guide
how to trigger such delays, would be great.

Post by Felix Miata
Often the start job is on account
of a volume label that has been replaced, usually along with a UUID, because
the clone is a partition on the same HD. Fedora is particularly frustrating
by embedding dependent root volume label and not obeying root= on cmdline
(openSUSE obeys root=). Those typos usually have to be fixed by chroot to run
dracut.
--

[Felix Miata]

Post by Andrei Borzenkov

Post by Felix Miata
When they occur during init they repeat during shutdown. Even when I
let init complete and succeed to fix the typo or oversight, the init failure
gets remembered and repeated at shutdown.

Yes, that's the problem. For once, traditional workflow of
- stop in emergency shell when mount fails
- fix /etc/fstab
- ^D to continue boot
no more works, because /etc/fstab is not reevaluated so systemd will
still try the same broken mount again. Also I have observed delays
during shutdown/reboot /probably/ triggered by failed mounts but am
not sure how to reproduce them. If you have simple step by step guide
how to trigger such delays, would be great.

Given what I have written in this thread, I am puzzled that you ask this. Try
what I just did (on multiboot host gx28c with 8 or more volume lines in eash
installation's fstab; 'fdisk -l | grep /dev/sda | wc -l' produces 24 on this
host):

1-have fstab entries for openSUSE 13.1 and TW mount using the form LABEL=
2-in TW's fstab, misspell the volume label for 13.1
3-boot TW
4-when the waiting for dev-disk-by\x2dlabel-<LABEL>.device (failing volume's
label) start job appears, right away CAD, and shutdown will proceed normally
for a short time, after which the waiting for
dev-disk-by\x2dlabel-<LABEL>.device previously experienced will institute a
similar delay before reboot completes
5-boot 13.1
6-restore TW's fstab to have correct volume label spellings next boot

I repeated on same host using Fedora 20 and 21 to get similar delays.

For both TW and F21 I also tried letting init proceed into emergency shell,
fixing fstab, then CAD, whereupon reboot proceeded quickly for both.

To reach Fedora 20 emergency shell after a very long wait (>3 minutes here on
2.8GHz 32 bit single core P4), include a misspelled root volume after LABEL=
on cmdline. (Warning: /dev/disk/by-label/fedor23 does not exist; Generating...)

[Lennart Poettering]

Post by Andrei Borzenkov

Post by Felix Miata
When they occur during init they repeat during shutdown. Even when I
let init complete and succeed to fix the typo or oversight, the init failure
gets remembered and repeated at shutdown.

Yes, that's the problem. For once, traditional workflow of
- stop in emergency shell when mount fails
- fix /etc/fstab
- ^D to continue boot
no more works, because /etc/fstab is not reevaluated so systemd will
still try the same broken mount again.

Yeah, systemd will require a "systemctl daemon-reload" first. It might
be a good idea if distros would mention that in a comment in the
default fstab file they install.

Lennart

[Michael Biebl]

Post by Lennart Poettering

Post by Andrei Borzenkov
- stop in emergency shell when mount fails
- fix /etc/fstab
- ^D to continue boot
no more works, because /etc/fstab is not reevaluated so systemd will
still try the same broken mount again.

Yeah, systemd will require a "systemctl daemon-reload" first. It might
be a good idea if distros would mention that in a comment in the
default fstab file they install.

Hm, I vaguely remember that we discussed quite a while ago. Wasn't the
idea to trigger the daemon-reload automatically when exiting the
emergency/rescue shell?

Could be as simple as changing emergency.service from

ExecStart=-/bin/sh -c "/sbin/sulogin; /bin/systemctl --fail --no-block default"

to
ExecStart=-/bin/sh -c "/sbin/sulogin; /bin/systemctl daemon-reload;
/bin/systemctl --fail --no-block default"


Michael

[Lennart Poettering]

Post by Michael Biebl

Post by Lennart Poettering

Post by Andrei Borzenkov
- stop in emergency shell when mount fails
- fix /etc/fstab
- ^D to continue boot
no more works, because /etc/fstab is not reevaluated so systemd will
still try the same broken mount again.

Yeah, systemd will require a "systemctl daemon-reload" first. It might
be a good idea if distros would mention that in a comment in the
default fstab file they install.

Hm, I vaguely remember that we discussed quite a while ago. Wasn't the
idea to trigger the daemon-reload automatically when exiting the
emergency/rescue shell?
Could be as simple as changing emergency.service from
ExecStart=-/bin/sh -c "/sbin/sulogin; /bin/systemctl --fail --no-block default"
to
ExecStart=-/bin/sh -c "/sbin/sulogin; /bin/systemctl daemon-reload;
/bin/systemctl --fail --no-block default"

I am not convinced this would be a good idea. I mean, I fail to see
why we should add an automatism in this specific case while we don't
have any automatism when you edit the file in any other context, for
example when the system is fully up.

I think this is really a documentation issue: the fstab file should
contain a nice hint to run "systemctl daemon-reload" to make systemd
consider it. And we could even update the rescue mode help text that
is shown right before sulogin to say the same. But otherwise, I am not
convinced anything should happen automatically here...

Lennart

[Lennart Poettering]

Post by Felix Miata

Post by Andrei Borzenkov

Post by Felix Miata
Has anything been done in more recent releases about this? I do a lot of
cloning, and sometimes produce typos on grub cmdlines and fstab lines. This
produces long delays in init followed by emergency mode when the
non-essential mount fails and fstab for that device does not include the
nofail option. When I recognize early in init that I have made a fstab typo,
I try to CAD to choose another boot choice that isn't broken and fix the
typo, but that produces yet another start job wait for the same broken job,
often followed by a gazillion failed to save sound card state messages from
holding down CAD.
openSUSEes, Mageias & Fedoras (including Factories, Cauldrons & Rawhides)
comprise most of my installations subject to these self-inflicted delays that
I can't recall being a problem with sysvinit.

"Self inflicted delays" during boot or during Ctrl-Alt-Del?

Both. When they occur during init they repeat during shutdown. Even when I
let init complete and succeed to fix the typo or oversight, the init failure
gets remembered and repeated at shutdown. Often the start job is on account
of a volume label that has been replaced, usually along with a UUID, because
the clone is a partition on the same HD. Fedora is particularly frustrating
by embedding dependent root volume label and not obeying root= on cmdline
(openSUSE obeys root=). Those typos usually have to be fixed by chroot to run
dracut.

Hmm, Fedora doesn't obey root=? That sounds like a bug.

Harald?

[Felix Miata]

Post by Lennart Poettering

Post by Felix Miata
Both. When they occur during init they repeat during shutdown. Even when I
let init complete and succeed to fix the typo or oversight, the init failure
gets remembered and repeated at shutdown. Often the start job is on account
of a volume label that has been replaced, usually along with a UUID, because
the clone is a partition on the same HD. Fedora is particularly frustrating
by embedding dependent root volume label and not obeying root= on cmdline
(openSUSE obeys root=). Those typos usually have to be fixed by chroot to run
dracut.

Hmm, Fedora doesn't obey root=? That sounds like a bug.

I think it's only a problem due to Fedora's configuration of its Dracut
hostonly option used by default. AFAICR, its rescue initrds have always
worked. I can't remember now, but it may possibly be Mageia with hostonly
enabled disobeys root= too, locking onto root's UUID when the initrd was
built. It's never been a problem I've observed in openSUSE, which let dracut
evolve a lot longer before switching to it from mkinitrd.

Post by Lennart Poettering
Harald?

[Chris Murphy]

Post by Felix Miata

Post by Lennart Poettering

Post by Felix Miata
Both. When they occur during init they repeat during shutdown. Even when I
let init complete and succeed to fix the typo or oversight, the init failure
gets remembered and repeated at shutdown. Often the start job is on account
of a volume label that has been replaced, usually along with a UUID, because
the clone is a partition on the same HD. Fedora is particularly frustrating
by embedding dependent root volume label and not obeying root= on cmdline
(openSUSE obeys root=). Those typos usually have to be fixed by chroot to run
dracut.

Hmm, Fedora doesn't obey root=? That sounds like a bug.

I'm not sure what it means, Fedora doesn't obey root=. Since a long
time it uses root=UUID= and this has worked for me.

Post by Felix Miata
I think it's only a problem due to Fedora's configuration of its Dracut
hostonly option used by default. AFAICR, its rescue initrds have always
worked.

The problem(s) with Fedora rescue initramfs:

1. It behaves differently depending on whether its /lib/modules have
been deleted because the originally installed kernel has been removed
due to yum.conf installonly_limit=3 being reached. If deleted, user
gets dropped to a dracut prompt. And if not they get a complete boot
to a login prompt. It's better than a kernel panic, but the
inconsistency is not a good UX.

2. "rescue" is a generic term, but this nohostonly initramfs is really
meant to get a close to full boot when changing hardware such that the
hostonly initramfs does't work. So the use case is not really rescue.

3. A user might think "rescue" is for fsck or something basic. But
that can be done with rd.break=cmdline it doesn't require the rescue
initramfs.

4. Confusion with rescue.target and emergency.target. Both of which
require a root password, and Fedora now doesn't require a root
password at install or setup time, so the user can actually get stuck
being unable to access rdsosreport.txt because they can't login.

So... it's slightly ickey right now for these edge cases. Anyway, room
for improvement.

[Felix Miata]

Post by Chris Murphy

Post by Lennart Poettering
Hmm, Fedora doesn't obey root=? That sounds like a bug.

I'm not sure what it means, Fedora doesn't obey root=. Since a long
time it uses root=UUID= and this has worked for me.

All current distros whose bootloaders I've used include a root= in each of
their bootloader stanzas. AFAIK, root=UUID= is used in Fedora's Grub2
stanzas. Maybe it went into Fedora's Grub Legacy cmdlines before the switch
to Grub2. I don't remember. I haven't installed any of Fedora's bootloaders
since Fedora dropped Grub Legacy, so don't have first-hand experience from
which to know otherwise.

Most distros do not require use of their own bootloaders to successfully
boot. I've been using openSUSE's Grub Legacy for booting all distros
installed on my own systems ever since Grub2 started becoming distros'
default bootloader. This has worked for all, except as described below.

In the pre-libata days, as I remember, any syntactically correct root= on
cmdline was what would be used to find /etc/fstab and get the root filesystem
up. Included among the possibles valid with post-libata distros have been:

root=/dev/sdX
root=/dev/disk/by-label/...
root=LABEL=...
root=/dev/disk/by-uuid/...
root=UUID=...

"What it means" is that traditional cmdline root= option still works with
openSUSE's configured-by-default initrds, but not with Fedora's
configured-by-default initrds. Translated, this means the following process
that works with non-Fedora root partitions fails with Fedora's root partitions:

1-boot anything other than intended logical source partition on a BIOS
multiboot system with 1 HD only
2-clone an existing unmounted logical source/root partition to some other
unmounted partition
3-configure a unique UUID and volume label on the clone
4-mount the clone and adjust its fstab appropriately
5-in the HD's bootloader menu (not the boot menu on the clone), clone the
source stanza and adjust it appropriately to use for the clone, using any of
the above listed (legal) root= forms.

When Fedora is the source and clone, attempting boot of clone using default
initrd produces an emergency shell, unlike openSUSE. To boot a Fedora clone
normally requires a chroot rescue (what I usually do) or a
/boot/initramfs-0-rescue*.img boot to rebuild its normal initrd(s). This
Fedora characteristic in effect produces an undesirable, and likely
unforeseeable by most, stumbling block to at least one backup/restore
scenario that involves no change of hardware that Fedora's Dracut hostonly
configuration seems to suggest would be safe.

[Chris Murphy]

Post by Felix Miata

Post by Chris Murphy

Post by Lennart Poettering
Hmm, Fedora doesn't obey root=? That sounds like a bug.

I'm not sure what it means, Fedora doesn't obey root=. Since a long
time it uses root=UUID= and this has worked for me.

All current distros whose bootloaders I've used include a root= in each of
their bootloader stanzas. AFAIK, root=UUID= is used in Fedora's Grub2
stanzas.

That's true unless LVM is being used, which happens to be the default,
in which case it's root=VG/LV.

Post by Felix Miata
When Fedora is the source and clone, attempting boot of clone using default
initrd produces an emergency shell, unlike openSUSE.

I'm unable to reproduce this problem on a BIOS system. Old volume is
Btrfs, new volumes is Btrfs (new volume UUID), and I just copy the
files from old to new (I actually used btrfs send receive). I of
course had to install a new bootloader with grub2-install, and create
a new grub.cfg with grub2-mkconfig in order for the correct new volume
root=UUID= to be set. And I also had to edit the fstab on the new
volume so that the right UUIDs are called for there too. The resulting
system boots fine.

However, on UEFI that's not the case, I get dropped to a dracut shell:

[ 188.409072] f21s2.localdomain dracut-initqueue[263]: Warning:
/dev/disk/by-uuid/083A-7E6C does not exist

That UUID is for the old FAT32 EFI System Partition. Somehow dracut is
baking in the EFI System partition UUID into the initramfs, instead of
honoring the correct one that I put into fstab. As a result boot fails
and will always fail until I rebuild the initramfs. So I'd definitely
consider that a bug.

https://bugzilla.redhat.com/show_bug.cgi?id=1187007

[Felix Miata]

Post by Chris Murphy

Post by Felix Miata

Post by Chris Murphy

Post by Lennart Poettering
Hmm, Fedora doesn't obey root=? That sounds like a bug.

I'm not sure what it means, Fedora doesn't obey root=. Since a long
time it uses root=UUID= and this has worked for me.

All current distros whose bootloaders I've used include a root= in each of
their bootloader stanzas. AFAIK, root=UUID= is used in Fedora's Grub2
stanzas.

That's true unless LVM is being used, which happens to be the default,
in which case it's root=VG/LV.

I've used LVM on exactly one HD, since wiped, too many years ago to remember
when or which.

Post by Chris Murphy

Post by Felix Miata
When Fedora is the source and clone, attempting boot of clone using default
initrd produces an emergency shell, unlike openSUSE.

I'm unable to reproduce this problem on a BIOS system.

What you describe below looks little like the process I described.

Post by Chris Murphy
Old volume is
Btrfs, new volumes is Btrfs (new volume UUID),

I didn't think any mention of filesystem type would be relevant in describing
my process, but all clones used as a Fedora / here have been either EXT3 or EXT4.

Post by Chris Murphy
and I just copy the

I wrote "clone" for a reason. I don't "just copy" files. I clone (logical,
root, autonomous) *partitions*, subsequently modifying only fstab, volume
label and UUID before attempting boot from it.

Post by Chris Murphy
files from old to new (I actually used btrfs send receive). I of
course had to install a new bootloader with grub2-install, and create

The process I wrote was intended to make it clear that no bootloader that may
have been on a Fedora / partition was used for booting a Fedora clone as
adjusted to its new location. It's a process that was relatively simple and
reliable until humanly memorable cmdline root= parameters what worked
formerly began being disregarded by Fedora's boot process in apparent favor
of incorporating a root filesystem UUID subject to change during
backup/restore process in its initrd.

Post by Chris Murphy
Somehow dracut is
baking in the EFI System partition UUID into the initramfs, instead of
honoring the correct one that I put into fstab. As a result boot fails
and will always fail until I rebuild the initramfs. So I'd definitely
consider that a bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1187007

Noted, commented, CC'd.

[Chris Murphy]

Post by Felix Miata
I wrote "clone" for a reason. I don't "just copy" files. I clone (logical,
root, autonomous) *partitions*, subsequently modifying only fstab, volume
label and UUID before attempting boot from it.

Clone is a generic term, it doesn't require a particular process. Are
you changing the volume UUID with, e.g. tune2fs -U random?

Post by Felix Miata

Post by Chris Murphy
files from old to new (I actually used btrfs send receive). I of
course had to install a new bootloader with grub2-install, and create

The process I wrote was intended to make it clear that no bootloader that may
have been on a Fedora / partition was used for booting a Fedora clone as
adjusted to its new location. It's a process that was relatively simple and
reliable until humanly memorable cmdline root= parameters what worked
formerly began being disregarded by Fedora's boot process in apparent favor
of incorporating a root filesystem UUID subject to change during
backup/restore process in its initrd.

Like I said, I can't reproduce this behavior. The BIOS system boots
fine without rebuilding the initramfs just by changing fstab and
grub.cfg UUIDs to match the root volume's UUID. Therefore I see no
evidence root= is ignored on Fedora.

The failed UEFI boot is strictly due to the old ESP UUID not being
found. The failure has nothing to do with root=.

dracut -f -v --debug shows only on UEFI is there a wait for device by uuid
/usr/lib/dracut/modules.d/99base/module-***@113(install):
wait_for_dev /dev/disk/by-uuid/5AC5-5766

[Harald Hoyer]

Post by Chris Murphy

Post by Felix Miata
I wrote "clone" for a reason. I don't "just copy" files. I clone (logical,
root, autonomous) *partitions*, subsequently modifying only fstab, volume
label and UUID before attempting boot from it.

Clone is a generic term, it doesn't require a particular process. Are
you changing the volume UUID with, e.g. tune2fs -U random?

Post by Felix Miata

Post by Chris Murphy
files from old to new (I actually used btrfs send receive). I of
course had to install a new bootloader with grub2-install, and create

The process I wrote was intended to make it clear that no bootloader that may
have been on a Fedora / partition was used for booting a Fedora clone as
adjusted to its new location. It's a process that was relatively simple and
reliable until humanly memorable cmdline root= parameters what worked
formerly began being disregarded by Fedora's boot process in apparent favor
of incorporating a root filesystem UUID subject to change during
backup/restore process in its initrd.

Like I said, I can't reproduce this behavior. The BIOS system boots
fine without rebuilding the initramfs just by changing fstab and
grub.cfg UUIDs to match the root volume's UUID. Therefore I see no
evidence root= is ignored on Fedora.
The failed UEFI boot is strictly due to the old ESP UUID not being
found. The failure has nothing to do with root=.
dracut -f -v --debug shows only on UEFI is there a wait for device by uuid
wait_for_dev /dev/disk/by-uuid/5AC5-5766

will follow up in private email and on the bugzilla

[Lennart Poettering]

Post by Felix Miata

Post by Lennart Poettering

Post by Felix Miata
Both. When they occur during init they repeat during shutdown. Even when I
let init complete and succeed to fix the typo or oversight, the init failure
gets remembered and repeated at shutdown. Often the start job is on account
of a volume label that has been replaced, usually along with a UUID, because
the clone is a partition on the same HD. Fedora is particularly frustrating
by embedding dependent root volume label and not obeying root= on cmdline
(openSUSE obeys root=). Those typos usually have to be fixed by chroot to run
dracut.

Hmm, Fedora doesn't obey root=? That sounds like a bug.

I think it's only a problem due to Fedora's configuration of its Dracut
hostonly option used by default. AFAICR, its rescue initrds have always
worked. I can't remember now, but it may possibly be Mageia with hostonly
enabled disobeys root= too, locking onto root's UUID when the initrd was
built. It's never been a problem I've observed in openSUSE, which let dracut
evolve a lot longer before switching to it from mkinitrd.

Hmm, but even in hostonly mode I'd assume that kernel cmdline settings
override the included settings... Still sounds like a bug...

Lennart

[Lennart Poettering]

Post by Felix Miata
Has anything been done in more recent releases about this? I do a lot of
cloning, and sometimes produce typos on grub cmdlines and fstab lines. This
produces long delays in init followed by emergency mode when the
non-essential mount fails and fstab for that device does not include the
nofail option. When I recognize early in init that I have made a fstab typo,
I try to CAD to choose another boot choice that isn't broken and fix the
typo, but that produces yet another start job wait for the same broken job,
often followed by a gazillion failed to save sound card state messages from
holding down CAD.
openSUSEes, Mageias & Fedoras (including Factories, Cauldrons & Rawhides)
comprise most of my installations subject to these self-inflicted delays that
I can't recall being a problem with sysvinit.

Hmm, so there has been a long-standing TODO list item to show some job
data when C-a-d is pressed 3 times within 1s, and reboot the machine
immediately on 3 times within 10s or so. I figure that would already
make you happy?

Lennart

[Lennart Poettering]

Post by Lennart Poettering

Post by Felix Miata
Has anything been done in more recent releases about this? I do a lot of
cloning, and sometimes produce typos on grub cmdlines and fstab lines. This
produces long delays in init followed by emergency mode when the
non-essential mount fails and fstab for that device does not include the
nofail option. When I recognize early in init that I have made a fstab typo,
I try to CAD to choose another boot choice that isn't broken and fix the
typo, but that produces yet another start job wait for the same broken job,
often followed by a gazillion failed to save sound card state messages from
holding down CAD.
openSUSEes, Mageias & Fedoras (including Factories, Cauldrons & Rawhides)
comprise most of my installations subject to these self-inflicted delays that
I can't recall being a problem with sysvinit.

Hmm, so there has been a long-standing TODO list item to show some job
data when C-a-d is pressed 3 times within 1s, and reboot the machine
immediately on 3 times within 10s or so. I figure that would already
make you happy?

So, I actually implemented this now. Or actually, I only implemented
the part about C-A-D triggering a reboot. I picked 7x per 2s as limit
though, seemed easier to me.

It should be easy to extend this to show information about running
jobs after 3x too.

http://cgit.freedesktop.org/systemd/systemd/commit/?id=2e5c94b9aaefce46835b623e800cfc168995ea3f

Hope this is useful,

Lennart

[Felix Miata]

...

Post by Lennart Poettering
So, I actually implemented this now. Or actually, I only implemented
the part about C-A-D triggering a reboot. I picked 7x per 2s as limit
though, seemed easier to me.
It should be easy to extend this to show information about running
jobs after 3x too.
http://cgit.freedesktop.org/systemd/systemd/commit/?id=2e5c94b9aaefce46835b623e800cfc168995ea3f
Hope this is useful,

No objection from this non-programmer. Thanks. :-)

Out of curiosity, I looked at that URL, little there I understand, but I did
notice a comment string that seemed like might include a typo: "C-A-D too more".

[Lennart Poettering]

Post by Felix Miata
...

Post by Lennart Poettering
So, I actually implemented this now. Or actually, I only implemented
the part about C-A-D triggering a reboot. I picked 7x per 2s as limit
though, seemed easier to me.
It should be easy to extend this to show information about running
jobs after 3x too.
http://cgit.freedesktop.org/systemd/systemd/commit/?id=2e5c94b9aaefce46835b623e800cfc168995ea3f
Hope this is useful,

No objection from this non-programmer. Thanks. :-)
Out of curiosity, I looked at that URL, little there I understand, but I did
notice a comment string that seemed like might include a typo: "C-A-D too more".

Thanks for the pointer. Will fix.

Lennart