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?
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.
/etc/fstab.
– Emmanuel Rosa
Aug 15 '18 at 09:08
/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
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.
/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