Bug 639034 – sys-kernel/genkernel-3.5.2.4 kernel panic when booting the initramfs with the squashfs filesystem and cdroot

• Product: Gentoo Hosted Projects
• Status: RESOLVED FIXED

[Description Brian Munro 2017-11-28 06:46:40 UTC]

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

[Comment 1 Robin Johnson 2017-12-20 19:24:40 UTC]

@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).

[Comment 2 Brian Munro 2017-12-21 06:03:09 UTC]

Created attachment 511286 [details]
Image of Kernel Panic

Image of Kernel Panic if /sbin/init can't be found in newroot

[Comment 3 Brian Munro 2017-12-21 06:05:07 UTC]

Created attachment 511288 [details]
test if statement check for /sbin/init in newroot

if statement check for /sbin/init in newroot

[Comment 4 Brian Munro 2017-12-21 06:05:33 UTC]

Created attachment 511290 [details]
File listing of newroot

File listing of newroot

[Comment 5 Brian Munro 2017-12-21 06:19:02 UTC]

Created attachment 511292 [details, diff]
Linuxrc patch

This patch will add ${FS_LOCATION} to the check, to work correctly with squashfs mounted filesystems

[Comment 6 Brian Munro 2017-12-21 06:25:12 UTC]

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

[Comment 7 Robin Johnson 2017-12-21 06:49:42 UTC]

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.

[Comment 8 Brian Munro 2017-12-21 08:16:26 UTC]

Yea I agree, doing the if statement using the chroot command would be a more sane option.

[Comment 9 Larry the Git Cow 2017-12-25 07:01:57 UTC]

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 <[e-mail]>
AuthorDate: 2017-12-25 06:59:06 +0000
Commit:     Robin H. Johnson <[e-mail]>
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 <[e-mail]>

 defaults/linuxrc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)