There are 4 targets in systemd. what you wanted is emergency.target
I think you can try these steps:
- reboot the system
- interrupt the boot loader menu countdown by pressing any key
- move the cursor the entry to be started
- press e to edit the current entry
- move the cursor tho the entry to the line that starts with linux16. This is the kernel command line.
6.append systemd.unit=desired.target
- press ctrl+x to boot with these changes.
This is rhel7's method . I think it is maybe similar with suse .
Once you enter into emergency mode, root password is still needed.
good luck:)
It is literally only mount failures, that's all you would need to change.
So the letter of your request would be trivial to answer. Create a drop-in file:
# /etc/systemd/system/local-fs.target.d/nofail.conf
# Clear OnFailure= (set it to nothing)
[Unit]
OnFailure=
I believe this will add no new problem, beyond those that linux sysvinit already suffered by allowing this partial failure scenario.
However you also pointed out the question of how long systemd should wait for the specified block devices to become available. I can see no way to configure this, without providing a replacement for the fstab generator as a whole. https://www.freedesktop.org/software/systemd/man/systemd.generator.html
If you dump a large amount of less widely-used code here, it seems unlikely to increase system resilience. I think the closest solution would be to patch the existing fstab generator. It's not massively complex, I suspect you could get away with it / keep up with any significant changes.
Technically, if your distribution had a self-contained mountall
sysvinit script, you could try hooking that in. But that will significantly change the boot process - it's actually more of a fork. I would not recommend that approach.
https://unix.stackexchange.com/a/393711/29483
If you search through the unit files, there are only a very few ways
for the boot to fall back to emergency.target
. It's usually when a
.mount
unit for a local filesystem fails, causing local-fs.target
to fail. Or when your initramfs fails to mount the root filesystem,
if your initramfs uses systemd.
local-fs.target
has OnFailure=emergency.target
. And it gets
failed because units for local filesystems are automatically added to
the Requires list of local-fs.target (unless they have
DefaultDependencies=no
).
$ systemctl show --property Requires local-fs.target
Requires=-.mount home.mount boot.mount boot-efi.mount
Best Answer
The failure should have shown a red
[ FAIL ]
on the console (instead of[ OK ]
), with the unit's description next to it. Typically the first failures are most important. Use shift+pageup on the console to scroll up and view the past few screenfuls of output. This might not work if there's too much output.This works even if you don't normally see
[ OK ]
messages, e.g. due toquiet
on the kernel command line as used by Debian. On the first failure, systemd switches to verbose mode.Otherwise, you can use
systemctl
. Without any options, it shows a massive list of known units with failures highlighted in red. To show just the failed ones, usesystemctl --state=failed
orsystemctl --failed
.If you search through the unit files, there are only a very few ways for the boot to fall back to
emergency.target
. It's usually when a.mount
unit for a local filesystem fails, causinglocal-fs.target
to fail. Or when your initramfs fails to mount the root filesystem, if your initramfs uses systemd.local-fs.target
hasOnFailure=emergency.target
. And it gets failed because units for local filesystems are automatically added to the Requires list of local-fs.target (unless they haveDefaultDependencies=no
).