No path is required when the full path is supplied like that. I would verify in the new filesystem that execute is set on everything including the directories. I would also do a ldd bash outside of the new system and check to see if all of the right libraries exist in the "new" image in the right place with the right permissions and checksums. You might try executing the "new" system /bin/bash and see if it works and/or validate it has the same checksum as the one on the working system. The switchroot should not be setting noexec on that filesysetm and outside of the various executable bits on files and directories I don't think there is a way to prevent execute of something, though there may be things besides selinux that could block it. I have seen a script say no execute when the #! executable is not set but exists, but bash should be a compiled program so that should not be an issue. Effectively the first exec of bin bash is a simple exec and should only required the executable to be there and the library and/or library path to have the needed pieces in it (/etc/ld.so.conf and /etc/ld.so.conf.d defined the library path) and should have all of the right libraries with the right checksums that the ldd says it needed. It sounds like once you get the chroot . to work things may work right. Something odd happened with the rsync I would suspect. On Wed, Jun 5, 2019 at 4:33 PM stan <upaitag@xxxxxxxx> wrote: > > On Wed, 5 Jun 2019 10:14:01 -0500 > Roger Heflin <rogerheflin@xxxxxxxxx> 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. > _______________________________________________ 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
