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. 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. The only other 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. On Wed, Jun 5, 2019 at 9:52 AM stan <upaitag@xxxxxxxx> wrote: > > 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
