On Wed, 5 Jun 2019 10:14:01 -0500
Roger Heflin <rogerheflin(a)gmail.com> wrote:
There is a systemd started in the initrd, after the switchroot it
restarts/execs init and that is the real systemd on the real disk
that will run the system.
That's what I'm seeing then.
If you have quiet removed you should see the kernel say it mounted a
filesystem (it won't tell you what it mounted, but it will say it
mounted one). I have yet to see this sort of issue be a systemd
issue, it has generally been a failure to find and mount the rootlv.
It shows dracut mounting, and then unmounting before switch root,
several filesystems, including /boot and /sysroot. That's with the
dracut kernel printing to terminal turned on.
Mount up the new disks on someplaces like you did and cd into the /
for the new image and chroot . and then do ls -lL against the files
it is complaining about, it will show you the file at the end of the
lin, and this should be exactly what is seen when it is booting. If
the chroot . complains about started /bin/bash, either it is missing
or some libraries are not all there.
It is as you say. When I do a chroot to the system that won't boot, it
won't because it says it can't find /bin/sh. Yet they *are* there. It
is like the path hasn't been set.
I unpacked the rescue image, expecting to find something which pointed
to the old system, and there was nothing obvious. If it is there, I
couldn't find it. Maybe it is created during initial boot before the
switch root.
Anyway, the core issue seems to be that path is not set up on the new
system, so once it switches root it can't find anything even though it
is there.