0

I have a gentoo system, which uses systemd, a custom kernel, a custom initramfs, and a custom init script. This system was working. Now it does not. Clearly something must have changed, but I have no idea what.

When the init script launches the init system (exec switch_root /mnt/root /var/lib/systemd/systemd), I get the following error:

Welcome to Gentoo/Linux!

[!!!!!!] Failed to isolate default target, freezing.

What does this error mean? What can I do to resolve it?

  • This site(freedesktop.org/wiki/Software/systemd/Debugging) lists some systemd debug options. Specifically, try adding "systemd.log_level=debug systemd.log_target=console systemd.journald.forward_to_console=1 console=tty1" to your kernel args. It may help get more information to add to your question. – Cody Creager Aug 14 '18 at 4:23
  • The questioner is asking what a specific message means, what causes systemd to emit it, and how to avoid that. That could be answered in a mere 3 paragraphs. – JdeBP Aug 14 '18 at 7:07
  • @CodyCreager Is there some way I can pass those options directly to systemd when I switch_root? Adding arguments is easy, changing the kernel command line is not. – Ethan Reesor Aug 15 '18 at 1:43
  • @JdeBP If you can provide that 3 paragraph answer, please do – Ethan Reesor Aug 15 '18 at 1:44
1

In systemd jargon, isolating a unit is a slightly special form of starting or activating it, that can mostly (although I'll come back to this) be regarded as identical to activation. systemd at bootstrap isolates one of three targets, according to whether the system is being started in emergency, rescue, or normal mode. The first two are specified by -b and -s on the kernel command line that are passed along to the first process, and isolate emergency.target and rescue.target respectively. Normal mode isolates the default.target unit, which is an alias (set with systemctl set-default) for some other concrete target such as graphical.target or multi-user.target. A failure to isolate the first unit (from which everything else flows) is a fairly drastic error, and when that happens systemd emits a message and freezes.

It is unusual for default.target to not be isolatable, and it hints at either some serious misconfiguration (like the person who masked sysinit.target) or a highly unusual setup (such as a violation of one of the systemd premises, such as /usr and /etc being the same filesystem as, or at least mounted along with, /). Diagnosing this further involves the aforementioned emergency and rescue modes. Simply bootstrap into those modes instead of the normal mode, and then manually start the default.target unit, looking at what happens, what errors occur, and what is in the logs. This is where the difference between isolation and activation is important. One must not isolate default.target, as that shuts off the emergency/rescue mode login session as part of isolating the unit. One must start it.

I seem to have a paragraph spare.

Further reading

  • My root partition is encrypted. After unlocking, I have /dev/mapper/main. I mount that as root. However, systemd sees the entry for root in my fstab and fails to understand that I have already mounted it, causing boot timeouts. For a while, I fixed that by masking dev-mapper-main.device. However, recently I've been getting the failure to isolate error. So my choices are failure to isolate or boot timeout, both because systemd apparently doesn't realize I've already mounted root. – Ethan Reesor Aug 15 '18 at 20:27
1

To understand why my system wouldn't boot, I followed @CodyCreager's suggestion, mostly. I added --log-level=debug and --log-target=console to exec switch_root ..., which had the intended effect. I don't know how to achieve the same effect as adding systemd.journald.forward_to_console=1 to the kernel arguments. But I got enough information without doing that.

As far as why my system isn't booting... that wouldn't help anyone. I am doing custom things in my initramfs, and custom things with my systemd setup, and systemd is not happy about it. Specifically, I am using an encrypted filesystem and I'm having trouble getting systemd to figure that out.

  • Regarding your encrypted filesystem, assuming it's the root filesystem, are you using a script in initramfs to unlock the LUKS container? That would create a /dev/disk/by-uuid/* device which you can reference in /etc/fstab. – Emmanuel Rosa Aug 15 '18 at 9:08
  • My initramfs/init script unlocks the container and mounts it as root. The unlocked device is /dev/mapper/main. I use that in my fstab. But systemd apparently can't figure out that its already mounted. So I masked dev-mapper-main.device, and that worked for a while. Now it doesn't. My solution is to have two fstabs, one in my root, and one in my initramfs. – Ethan Reesor Aug 15 '18 at 20:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.