Red Hat Bugzilla – Bug 490544
composed DVD fails Rescue mode; modules.dep not found; cannot load squashfs
Last modified: 2013-01-10 00:06:04 EST
Description of problem: A DVD composed by pungi from today's rawhide (Mon.Mar.16) will not Rescue any system. The DVD boots and gets part way through initialization, but then fails. The immediate top-level message is a dialog box "Disc Not Found. The Fedora disk was not found in any of your CDROM drives. ..." Version-Release number of selected component (if applicable): pungi-2.0.12-1.fc11.noarch How reproducible: always Steps to Reproduce: 1.rm -f $(find /ext4/Fedora11 -name RPM-GPG-KEY-fedora'*') 2.rm -rf /ext4/Fedora11/11/i386/os-disc1 3.pungi -c /usr/share/pungi/rawhide-fedora.ks --destdir=/ext4/Fedora11 --name Fedora --ver 11 --nosource --force 4. Burn the DVD, boot Rescue mode. Choose language and keyboard. Choose Local CD/DVD. Actual results: "Disc Not Found. The Fedora disk was not found in any of your CDROM drives. ..." Nothing can be done. No shell, etc. Expected results: Useful Rescue mode. Additional info: Today's boot.iso from mirrors works, using anaconda 11.5.0.29. When pungi-composed DVD Rescue mode fails, then looking on VT3 I see "anaconda version 11.5.0.12 on i386 starting" [note that is at least two weeks old] and "ERROR: failed to mount loopback device /dev/loop on /mnt/runtime as /loop/install.img: mount: unknown filesystem type 'squashfs'". On VT4 I see "modprobe: FATAL: Could not load /lib/modules/2.6.29-0.237.rc7.git4.fc11.i586/modules.dep: No such file or directory"
Created attachment 335449 [details] gzipped i386.log from pungi run /ext4/Fedora11/logs/i386.log 2346257 bytes compressed 18394009 bytes uncompressed
This sounds like you've got an old anaconda package in a repo somewhere that is getting picked up for some unknown reason, perhaps you have an old .i386 one around somewhere?
What version of squashfs-tools do you have on the box you're building on?
$ rpm -q anaconda anaconda-11.5.0.30-1.i586 $ rpm -q squashfs-tools squashfs-tools-4.0-0.20090126.i586 # yum update squashfs-tools Loaded plugins: dellsysidplugin2, refresh-packagekit rawhide/metalink | 8.5 kB 00:00 Setting up Update Process No Packages marked for Update I also did not find any stale anaconda-11.5.0*.rpm on the box doing the compose. I am re-doing the compose after removing all /var/cache/pungi/rawhide/*.sqlite and *.gz files. After that, I'll look for anaconda-11.5.0*.rpm in $(cat mirrorlist.txt) .
The re-composed and re-burned DVD still has the same problem. After reproducing the error, then I compared the DVD to the re-composed Fedora-11-i386-DVD.iso; they were equal up to EOF on Fedora-11-i386-DVD.iso . [I believe that the burn process appends some sectors of zeroes in order to avoid read problems on some drives that cannot detect End-Of-Media reliably.] Then I mounted images/install.img and looked around. /proc/mounts shows: ----- /dev/sr0 /media/Fedora\04011\040i386\040DVD iso9660 ro,nosuid,nodev 0 0 /dev/loop0 /mnt squashfs ro 0 0 ----- so the squashfs filesystem looks OK so far. The top level of the squashfs filesystem has: ----- drwxr-xr-x. 19 root root 460 2009-03-16 19:35 etc drwxr-xr-x. 2 root root 3 2009-03-16 19:35 firmware drwxr-xr-x. 6 root root 3017 2009-03-16 19:35 lib drwxr-xr-x. 2 root root 3 2009-03-16 19:35 modules drwxr-xr-x. 2 root root 3 2009-03-16 19:35 proc drwxr-xr-x. 8 root root 124 2009-03-16 19:35 usr drwxr-xr-x. 5 root root 50 2009-03-16 19:27 var ----- and the directory 'modules' is empty (contains no files except the hardlinks "." and ".." for the current and parent directory). Inside the top-level 'lib' directory, there is another 'modules' which is a symlink: ----- lrwxrwxrwx. 1 root root 8 2009-03-16 19:35 modules -> /modules ----- This looks strange to me.
Each of the 20 mirrors in mirrorlist.txt had the Package anaconda-11.5.0.30-1.i586.rpm, and all such *.rpm files had the same contents. VT3 of the failed Rescue still said "anaconda-11.5.0.12".
Re-assigning to anaconda because it looks like the problem arises in buildinstall. The Fedora-11-i386-DVD.iso has an /images/install.img which lacks a modules.dep, and has a /lib/modules -> /modules where /modules is an empty directory. Thus there are no kernel modules, and in particular no squashfs.ko. The first target filesystem was ext4. However, the same problem also occurs when the target filesystem is ext3, as verified by re-composing. The box had 4GB of RAM, but only 3.3GB was usable by today's rawhide kernel, kernel-2.6.29-0.258.rc8.git2.fc11.i586. Today's version is anaconda-11.5.0.33-1.i586.
I'm pretty certain that you've got some compose environment issues. The composes I'm doing here reflect the right anaconda version and rescue fails with a traceback due to storage rewrite stuff (fixed upstream). Make sure the version of anaconda you have installed is the version you wish to have in your compose and make sure you aren't re-using any output directories.
"... and make sure you aren't re-using any output directories." If that matters, then it's pungi's job to issue a warning for the "caching" which fouls the output. The documentation says nothing about the output directory must be empty. Re-running the compose, but first with rm -rf $DESTDIR/work/$ARCH # i.e., /ext4/Fedora11/work/i386 rm -rf $DESTDIR/$VERSION/$ARCH # i.e., /ext4/Fedora11/11/i386 achieves "success": the current installed anaconda (11.5.0.33) is used for the DVD.iso, and there are no visible complaints about missing modules.dep or squashfs.ko. [The Rescue itself fails due to a very early SIGSEGV in /sbin/loader.] Re-assigning back to pungi.
Pungi does warn you if you are re-using an existing directory, and makes you use --force. The problem is that many of the tools outside pungi's control have ... undefined results when used with pre-existing content. I think the best option for now is to just make pungi fail if the directory tree exists at all.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I've created an upstream ticket to track this, cleaning out anaconda leftovers in work. https://fedorahosted.org/pungi/ticket/102