Bugzilla Bug 208477

When using an "initramfs" file from genkernel (3.4.9) the "check_loop()"
procedure fails and "ash" starts. After simply existing by typing "exit" the
cdboot continues without problems.



Reproducible: Always




Kernel commandline:  kernel /boot/vmlinuz-2.6.23-gentoo-r3 root=/dev/ram0
init=/linuxrc looptype=squashfs loop=/livecd.squashfs udev nodevfs cdroot
dodmraid real_root=/dev/loop0 video=vesafb:1024x768-32@85,mtrr:2,ywrap
splash=verbose,theme:default CONSOLE=/dev/tty1 quiet nodhcp

Fails how? What's the error? Got any output? Is this on a CD? Is this a custom
built CD? We need some information that we can actually use

Ok, looking at the genkernel code, you only get a failure there if you've
pointed it to a loop file that doesn't exist. Do you actually have a
"livecd.squashfs" in your CD root? The "standard" filename that catalyst uses
is "image.squashfs".

If you're using genkernel on a "real" machine and this isn't a CD, you need to
remove a *bunch* from your command line:

looptype=squashfs loop=/livecd.squashfs udev nodevfs cdroot

Also, you need to change real_root=/dev/loop0 to actually point to your real
root device.  It should be something like /dev/sda3 or /dev/hda3.

Now, nodhcp does nothing on a live system.  It only affects the CD.

On a real machine the initramfs from genkernel run fine.

I am using it on a custom build liveCD
(http://gentoo-wiki.com/HOWTO_build_a_LiveCD_from_scratch).

Yes I have a "livecd.squashfs" on the CD.

The interessting thing is, that the procedure shows up the error message and
starts the "ash" shell, but when I do nothing but typing "exit" followed by
pressing "enter" the CD keeps on starting without problems! 

In other words: The "check_loop()" procedure does not find an existing
"livecd.squashfs" file, but the following procedure is able to read it.

I am a little bit confused about that.

The only "obvious" problem I see is that there's not a leading / in the path of
the loop file to check in check_loop(). Please add one, rebuild your initramfs,
and let us know if that fixes it.

I am seeing the same error trying to boot a livecd with almost (I don't have
quiet nodhcp) same boot parameters (seems like we followed the same guide).
Only difference is that I get kernel panic once I exit from ash.

The error is coming from:

                bad_msg "Invalid loop location: ${LOOP}"
                bad_msg 'Please export LOOP with a valid location, or reboot
and pass a proper loop=...'
                bad_msg 'kernel command line!'

i.e.

Invalid loop location: livecd.squashfs

I do see /newroot/mnt/cdrom mounted with correct livecd.squashfs in there with
'df' inside the shell. So, I don't know why that check failed.

Where is /bin/ash coming from?

First, I have no idea why people are following that guide. It is *much* easier
(not to mention "supported") to use catalyst to create a Gentoo-based LiveCD.
The genkernel code that handles the loopback image is meant for use in
conjunction with what catalyst generates. Any usage outside of that is
"unsupported".

Since we don't see the problem with our CDs generated by catalyst, chances are
we won't be able to fix this. If you can track down the issue (and perhaps even
provide a patch), it'll be a lot more likely that it will get fixed.

(In reply to comment #7)
> First, I have no idea why people are following that guide. It is *much* easier
> (not to mention "supported") to use catalyst to create a Gentoo-based LiveCD.
> The genkernel code that handles the loopback image is meant for use in
> conjunction with what catalyst generates. Any usage outside of that is
> "unsupported".

Is there a way to make catalyst use my existing chroot (that I created for this
livecd environment)?

Okay, this is fixed in SVN. It was due to the mount command returning before
the CD was actually mounted, which made the check fail.

(In reply to comment #9)
> Okay, this is fixed in SVN. It was due to the mount command returning before
> the CD was actually mounted, which made the check fail.
> 

I can test it out really quick and not wait for the next release if its
possible to get the fix as a patch against 3.4.9? With SVN, I will probably
need to emerge few things. Is that a possibility?

I would like to have a patch too.

Created an attachment (id=142715) [details]
diff since 3.4.9

I'm not going to break apart the patch, so you get the entire diff since 3.4.9.

I had a look to the patch and could not find any changes changes related to
this problem. Where is the difference after applying the patch.

> Change &>/dev/null to >/dev/null 2>&1 because busybox ash sucks

So, it was putting 'mount' in the background and happily proceeding...that
explains. Will give it a shot. Thanks for the patch.

Seems to work.

We could probably release the one line change as r1 on 3.4.9 because it is a
major breakage (I hit a kernel panic because of this). But that's up to you. I
guess depends when you plan to do 3.5.0 or 3.4.10.

We'll likely do 3.4.10, which we will use for the 2008.0 release.

Andrew, With this patch applied I still get an error thrown that says (I am
typing it because kernel panicked)

"mount: Mounting /dev/loop0 on /newroot/mnt/livecd failed: Invalid argument"

Then it says "Copying read write contents to tmpfs" and throws a bunch of "cp:
etc no such file or directory" errors and "switch_root: bad init '/sbin/init'"
and boom kernel panic.

Seems like the root of the problem is the mount problem. When I made it die
earlier in the process by creating a livecd directory instead of livecd file in
the root folder of the CD, it threw me into shell where I could see /dev/loop0
being there. And when I manually fired the same command which mounts the
squashfs file system, it threw the same "Invalid argument" error, although all
arguments were valid (at least the paths).

The kernel has support for loopback.

Got any ideas?

That's a completely different issue. Try downgrading squashfs-tools or using a
newer gentoo-sources (like 2.6.24) that is patched for squashfs-3.3 support. I
ran into this same problem while testing the fix for this bug. Downgrading
squashfs-tools and recreating the squashfs fixed it.

I just released genkernel 3.4.10_pre1, which has this fix included.  Feel free
to REOPEN this bug or make a comment if it is not resolved.

I am still hitting "mount: Mounting /dev/loop0 on /newroot/mnt/livecd failed:
Invalid argument", with squashfs-tools-3.2_p2 (tried 3.3 as well),
gentoo-sources-2.6.24 and genkernel-3.4.10_pre4. And I kept wondering why it
panics instead of throwing the shell. And then, I found a bug with
test_success:

test_success() {
        error_string=$1
        error_string="${error_string:-run command}"
        # If last command failed send error message and fall back to a shell
        if [ "$?" != '0' ]
        then
                bad_msg 'Failed to $1; failing back to the shell...'
                run_shell
        fi
}

That $? check will always succeed because error_string="${error_string:-run
command}" always succeeds. You need to store $? before hand, as soon as you
enter the function.

the above problem is being followed up in another bug:

http://bugs.gentoo.org/show_bug.cgi?id=212794