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
-s on the kernel command line that are passed along to the first process, and isolate
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
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
/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.