On Wed, 5 Jun 2019 07:31:46 -0500
Roger Heflin <rogerheflin@xxxxxxxxx> wrote:
> Based on not finding bash, I would think that t may not be finding
> your rootlv.
>
> That generally means either the driver for the disk controller/scsi,
> or a critical filesystem component, or something else is missing in
> the required pieces to find the rootlv. You said you aren't using LVM
> so that simplifies some things.
I can edit the partitions when I boot from another partition.
>
> If you have a serial port and a serial crossover cable and/or enough
> scroll back if you remove quiet you should be able to see the disk
> controller init and other messages so you can confirm what is or is
> not getting found.
Don't have.
>
> Ripping apart the initrd and/or using lsinitrd to check various
> components to see if all the pieces are there and/or all of the
> settings are right in the initrd files is probably a good idea.
>
> I have had dracut get confused and not include critical parts because
> of system config issues when dracut was being run, but most of those
> should have went away when you did hostonly=no.
I used the protocol in the man page for dracut to modify the grub.cfg
in the new clone and have all kernel output during initialization sent
to the terminal. It made no difference to the final output.
Here is that output, that I finally wrote down.
"""
Starting Switch Root
systemd-journald received SIGTERM from PID1 (systemd).
systemd[1] No /sbin/init, trying fallback
Failed to execute /sbin/init
systemd[1] Failed to execute /bin/sh, giving up: No such file or
directory
systemd[1] Freezing execution
"""
There were 15 suppressed messages with the kernel sending to the
terminal in this case.
The messages make no sense. It looks like systemd is starting, which
means that it found /usr/lib/systemd/systemd on the root filesystem in
order to start it. But that is just a link from /sbin/init, a link
that exists on the new filesystem. And once it is started, it has no
access to the filesystem that it was just started from, because it then
says /sbin/init failed even though it is running. What?
Existing system:
# ls -nZ /sbin/init
lrwxrwxrwx. 1 0 0 system_u:object_r:bin_t:s0 22 Feb 20 10:06 /sbin/init -> ../lib/systemd/systemd
# ls -nZ /usr/lib/systemd/systemd
-rwxr-xr-x. 1 0 0 system_u:object_r:init_exec_t:s0 1793800 Feb 20 10:07 /usr/lib/systemd/systemd
# ls -nZ /usr/bin/sh
lrwxrwxrwx. 1 0 0 system_u:object_r:bin_t:s0 4 Jun 18 2018 /usr/bin/sh -> bash
# ls -nZ /bin/sh
lrwxrwxrwx. 1 0 0 system_u:object_r:bin_t:s0 4 Jun 18 2018 /bin/sh -> bash
New system:
# ls -nZ /mnt/s2r4/sbin/init
lrwxrwxrwx. 1 0 0 system_u:object_r:bin_t:s0 22 Feb 20 10:06 /mnt/s2r4/sbin/init -> ../lib/systemd/systemd
# ls -nZ /mnt/s2r4/usr/lib/systemd/systemd
-rwxr-xr-x. 1 0 0 system_u:object_r:init_exec_t:s0 1793800 Feb 20 10:07 /mnt/s2r4/usr/lib/systemd/systemd
# ls -nZ /mnt/s2r4/usr/bin/sh
lrwxrwxrwx. 1 0 0 system_u:object_r:bin_t:s0 4 Jun 18 2018 /mnt/s2r4/usr/bin/sh -> bash
# ls -nZ /mnt/s2r4/bin/sh
lrwxrwxrwx. 1 0 0 system_u:object_r:bin_t:s0 4 Jun 18 2018 /mnt/s2r4/bin/sh -> bash
Could dracut be using some internal logic to start systemd from the
existing system during switch root? And then passing the wrong root
UUID (the old one) to that systemd, which then fails because it isn't
mounted? How would it even do that when that partition isn't mounted?
Unless it is keeping an internal copy, and that copy is somehow branded
with the old system root. But that would contravene the nohostonly
switch.
The man page says,
"""
Specifying the root Device
This is the only option dracut really needs to boot from
your root partition.
...
Because device node names can change, dependent on the drive ordering, you are encouraged to use the filesystem identifier (UUID) or filesystem label (LABEL) to specify your root partition:
root=UUID=19e9dda3-5a38-484d-a9b0-fa6b067d0331
"""
>From the grub.cfg on the new system.
root=UUID=0d9def12-bc96-4323-942f-fb9f4ba325bf
>From the grub.cfg on the old system.
root=UUID=2fc9417a-303e-43d4-91af-ba8807a58ae1
And blkid confirms these are accurate.
Aaaarrrrggggghhhhh!
Is this a bug in dracut? i.e. nohostonly isn't nohostonly.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
