The System will kernel panic if cdroot is passed to the initramfs and a squashfs filesystem is mounted Reproducible: Always Steps to Reproduce: 1.Boot squashfs livecd with the cdroot argument 2. 3. Actual Results: Kernel Panic Expected Results: System Boots successfuly The check done at https://github.com/robbat2/genkernel/blob/de034a52625200a6ef0286540435f6c4bf55230c/defaults/linuxrc#L1051 Will always fail since /newroot/sbin is a symlink on a squashfs based image
@Brian, some parts don't add up here: 1. you say the check fails, but want to make sure you're talking about the same one that you seem to have linked: elif [ ! -x ${CHROOT}/${init} ]; then '/newroot/sbin/init' SHOULD always pass that -x test. 2. You mention a kernel panic. Once you're in initramfs, you generally SHOULDN'T get a kernel panic. Can you capture the panic? (even a readable cameraphone picture of the screen is good).
Created attachment 511286 [details] Image of Kernel Panic Image of Kernel Panic if /sbin/init can't be found in newroot
Created attachment 511288 [details] test if statement check for /sbin/init in newroot if statement check for /sbin/init in newroot
Created attachment 511290 [details] File listing of newroot File listing of newroot
Created attachment 511292 [details, diff] Linuxrc patch This patch will add ${FS_LOCATION} to the check, to work correctly with squashfs mounted filesystems
Hi, I have attached an image showing the the file test "test if statement check for /sbin/init in newroot" since we haven't switched to the chroot yet this does not work since the symlink will not link correctly See "File listing of newroot" to see the current folder structure for /newroot The system kernel panics due to that "elif [ ! -x ${CHROOT}/${init} ]; then" returns true so we hit the following, see "Image of Kernel Panic" ################## # If we get here, something bad has happened splash 'verbose' bad_msg "A fatal error has occured since ${init} did not" bad_msg "boot correctly. Trying to open a shell..." ################## I have attached a patch that fixes this though, We need to just take ${FS_LOCATION} into consideration when checking for /sbin/init
Ah, I see how it fails in this case. It's the symlink at '${CHROOT}/sbin' that is invalid when you're outside the chroot, so you can't use the -x test. I don't like depending on FS_LOCATION in this case. How about: elif chroot "${CHROOT}" /usr/bin/test ! -x /${init} ; then That makes is explicitly clear that we want to test if /${init} is going to work, inside the context of the new root. If some other bug writes a symlink that happens to be valid outside the chroot, but invalid inside it, your FS_LOCATION variant wouldn't catch the issue.
Yea I agree, doing the if statement using the chroot command would be a more sane option.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=7106119b1375fce44bdef2c56bead46a3a02b848 commit 7106119b1375fce44bdef2c56bead46a3a02b848 Author: Robin H. Johnson <robbat2@gentoo.org> AuthorDate: 2017-12-25 06:59:06 +0000 Commit: Robin H. Johnson <robbat2@gentoo.org> CommitDate: 2017-12-25 06:59:06 +0000 linuxrc: fix init test for cdroot/squashfs. In a cdroot-squashfs environment, the /sbin/init path is an absolute symlink that is ONLY valid inside the chroot. As such, doing a executable test -x on it, from outside the chroot will fail, because the symlink destination is not valid outside $CHROOT. Improve the test to be done inside the chroot. Alternatively, it could detect a symlink and dereference it inside the chroot. Closes: https://bugs.gentoo.org/639034 Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> defaults/linuxrc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
