The linuxrc script used by an initramfs created with genkernel uses the following block (located around line 645, location varies betwenn the different genkernel versions) the check if the root filesystem is sane: if [ -d ${NEW_ROOT}/dev -a -x "${NEW_ROOT}${REAL_INIT:-/sbin/init}" ] || [ "${REAL_ROOT}" = "/dev/nfs" ] then break else bad_msg "The filesystem mounted at ${REAL_ROOT} does not appear to be a valid /, try again" got_good_root=0 REAL_ROOT='' fi When using systemd as init, the $REAL_INIT variable has the value /usr/lib/systemd/systemd. Now if /usr is located on a seperate partion, the check fails because is not mounted when the check is done. The boot then halts with the message: "The filesystem mounted at /dev/xxx does appear to be a valid /, try again. If I remove the check, the system boots, with systemd as init. This issues appear with the stable genkernel version, the lastest ~arch version and with the lastest genkernel-next version.
dracut is especially meant for this setup: module usrmount
(In reply to stareagle from comment #0) > The linuxrc script used by an initramfs created with genkernel uses the > following block (located around line 645, location varies betwenn the > different genkernel versions) the check if the root filesystem is sane: ... > When using systemd as init, the $REAL_INIT variable has the value > /usr/lib/systemd/systemd. Now if /usr is located on a seperate partion, the > check fails because is not mounted when the check is done. The boot then > halts with the message: "The filesystem mounted at /dev/xxx does appear to > be a valid /, try again. > > If I remove the check, the system boots, with systemd as init. > > This issues appear with the stable genkernel version, the lastest ~arch > version and with the lastest genkernel-next version. Do you have a patch for genkernel to remove the check? I would like very much to be able to boot my systems with systemd.
As a workaround I commented out the lines described by stareagle leaving just the break in /usr/share/genkernel/defaults/linuxrc : 643 # if [ -d ${NEW_ROOT}/dev -a -x "${NEW_ROOT}${REAL_INIT:-/sbin/init}" ] || [ "${REAL_ROOT}" = "/dev/nfs" ] 644 # then 645 break 646 # else 647 # bad_msg "The filesystem mounted at ${REAL_ROOT} does not appear to be a valid /, try again" 648 # got_good_root=0 649 # REAL_ROOT='' 650 # fi
So you're using separate /usr with systemd? That's looking for trouble, systemd does not support separate /usr. However, I also think that genkernel is trying to be too smart here...
(In reply to Fabio Erculiani from comment #4) > So you're using separate /usr with systemd? That's looking for trouble, > systemd does not support separate /usr. Sure it does, assuming you get /usr mounted before you execute systemd.
(In reply to Mike Gilbert from comment #5) To restate the problem: genkernel's linuxrc is checking for the presence of the specified init just after the root filesystem is mounted, but this is too soon; it needs to mount all of the necessary file systems before checking to see if $REAL_INIT is present and executable.
(In reply to mpcww from comment #3) > As a workaround I commented out the lines described by stareagle leaving > just the break in /usr/share/genkernel/defaults/linuxrc : > > 643 # if [ -d ${NEW_ROOT}/dev -a -x > "${NEW_ROOT}${REAL_INIT:-/sbin/init}" ] || [ "${REAL_ROOT}" = "/dev/nfs" ] > 644 # then > 645 break > 646 # else > 647 # bad_msg "The filesystem mounted at > ${REAL_ROOT} does not appear to be a valid /, try again" > 648 # got_good_root=0 > 649 # REAL_ROOT='' > 650 # fi I tried to convert this changes to a patch file for genkernel. With this patch I first reemerged genkernel and then generated with genkernel a new initramfs. If I boot with this initramfs, it fails with: >> Using mount -t ext3 -o ro mount: mounting /dev/md125 on /newroot failed: Device or resource busy !! Could not mount specified ROOT, try again !! Please file a bug report with this message [ **.******] kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
Created attachment 355224 [details, diff] /usr/local/portage/sys-kernel/genkernel/files/genkernel-3.4.47_systemd.patch
Created attachment 355226 [details] /usr/local/portage/sys-kernel/genkernel/genkernel-3.4.47.ebuild An ebuild to use the systemd patch.
(In reply to Mike Gilbert from comment #5) > (In reply to Fabio Erculiani from comment #4) > > So you're using separate /usr with systemd? That's looking for trouble, > > systemd does not support separate /usr. > > Sure it does, assuming you get /usr mounted before you execute systemd. Yes, sorry for the mistake, I misread the problem. Ok, then I believe that the code mounting the entries in initramfs.mount should be moved before (or in the middle of) the REAL_ROOT mount code.
Created attachment 355232 [details, diff] /usr/local/portage/sys-kernel/genkernel/files/genkernel-3.4.47_systemd.patch
(In reply to Juergen Rose from comment #7) > (In reply to mpcww from comment #3) > > As a workaround I commented out the lines described by stareagle leaving > > just the break in /usr/share/genkernel/defaults/linuxrc : > > > > 643 # if [ -d ${NEW_ROOT}/dev -a -x > > "${NEW_ROOT}${REAL_INIT:-/sbin/init}" ] || [ "${REAL_ROOT}" = "/dev/nfs" ] > > 644 # then > > 645 break > > 646 # else > > 647 # bad_msg "The filesystem mounted at > > ${REAL_ROOT} does not appear to be a valid /, try again" > > 648 # got_good_root=0 > > 649 # REAL_ROOT='' > > 650 # fi > > I tried to convert this changes to a patch file for genkernel. With this > patch I first reemerged genkernel and then generated with genkernel a new > initramfs. If I boot with this initramfs, it fails with: > > >> Using mount -t ext3 -o ro > mount: mounting /dev/md125 on /newroot failed: Device or resource busy > !! Could not mount specified ROOT, try again > !! Please file a bug report with this message > [ **.******] kernel panic - not syncing: Attempted to kill init! > exitcode=0x00000100 Sorry, I used the wrong comment symbols in the first submitted patch. With the corrected patch the booting is a little bit better. It comes until ... [ TIME ] Timed out waiting for device dev-mapper-vg1\x2dsrc.device [DEPEND] Dependency failed for /usr/src_condor [DEPEND] Dependency failed for Local File Systems. [ ***.******] systemd[1]: Job dev-mapper-vg1\x2dportage.device/start timed out [ ***.******] systemd[1]: Job dev-mapper-vg1\x2dvtmp.device/start timed out [ ***.******] systemd[1]: Job dev-mapper-vg1\x2dftp.device/start timed out [ ***.******] systemd[1]: Job dev-mapper-vg1\x2dopt.device/start timed out [ ***.******] systemd[1]: Job dev-mapper-vg1\x2dtmp.device/start timed out Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" to try again to boot into default mode. Give root password for maintenance If I login as root, I see that /, /dev/mapper/vg1-usr as /usr and two further disk partitions are mounted. Performing 'journalctl -xb' I see: ... /etc/mtab is not a symlink or not pointing to /proc/self/mount... ... Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory. ... failed to execute '/lib/udev/usbseat.sh' 'usbseat.sh': No such file or directory ... Job dev-mapper-vg1\x2dsrc.device/start timed out. Timed out waiting for device dev-mapper-vg1\x2dsrc.device Dependency failed for /usr/src_condor Dependency failed for Local File Systems Triggering OnFailure= dependencies of local-fs.target. Dependency failed for File Systems Check on /dev/mapper/vg1-src/ ... followed by similar messages for the other logical volumes. I.e., also /var is not mounted ... Failed to start Console System Startup Logging. 'systemctl default' reports again that Job dev-mapper-vg1\x2dusr.device/start timed out, followed by corresponding messages about the other logical volumes Any hint is appreciated.
(In reply to Juergen Rose from comment #12) Please, one bug = one issue. This is a separate bug and has to do with genkernel using mdev instead of udev, which makes lvm kaputt. See bug #424637, the only way to get it to work is (at this time) using genkernel-next and run it with --udev so that udev gets embedded into the initramfs and enabled at runtime.
Thanks Fabio for the hint.
This should be fixed in the latest genkernel-next release (v24).
(This was solved in genkernel-next)
(In reply to Pacho Ramos from comment #16) > (This was solved in genkernel-next) (Drop blocker as we will tell people to use genkernel-next when using systemd)
*** Bug 508678 has been marked as a duplicate of this bug. ***
I would accept a patch to move the check until after /usr is mounted, by simply removing the check doesn't seem like a great idea just to support such an usual setup.
Yes, that specific check should be deferred until /usr is mounted for systemd, but I think we need to replace it's present position with some other test to test that we found a filesystem usable for booting. It should be a test that ALSO fails if the blockdev for /usr is accidentally passed as rootfs. I suggest: test -x /bin/sh && test -e /etc/fstab
williamh: opinion on detecting if a filesystem is a good candidate for the rootfs (before /usr gets mounted into it. Existing test: test -d ${NEWFS}/dev && \ test -x ${NEWFS}${REAL_INIT:-/sbin/init} Proposed: test -x ${NEWFS}${REAL_INIT:-/sbin/init} || \ test -L ${NEWFS}${REAL_INIT:-/sbin/init} || \ test -x ${NEWFS}/bin/sh (followed by a better test for init after /usr is mounted)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=76a837bc21ffd8a7d350cd3c648947f45e6a07a7 commit 76a837bc21ffd8a7d350cd3c648947f45e6a07a7 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2019-07-15 15:30:39 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2019-07-15 15:30:39 +0000 linuxrc: Relax NEWROOT validation If the root device specified by the user is invalid then all we are going to lose is the possibility to ask for a new root device in a nice way. So no need to be smart here. Closes: https://bugs.gentoo.org/479730 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> defaults/linuxrc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)