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 attachment 142715 [details, diff] 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
