This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 490544 - composed DVD fails Rescue mode; modules.dep not found; cannot load squashfs
composed DVD fails Rescue mode; modules.dep not found; cannot load squashfs
Product: Fedora
Classification: Fedora
Component: pungi (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-03-16 18:22 EDT by John Reiser
Modified: 2013-01-10 00:06 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-05-25 18:01:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
gzipped i386.log from pungi run (2.24 MB, application/x-gzip)
2009-03-16 19:05 EDT, John Reiser
no flags Details

  None (edit)
Description John Reiser 2009-03-16 18:22:32 EDT
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):

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

When pungi-composed DVD Rescue mode fails, then looking on VT3 I see "anaconda version 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"
Comment 1 John Reiser 2009-03-16 19:05:36 EDT
Created attachment 335449 [details]
gzipped i386.log from pungi run

 2346257 bytes compressed
18394009 bytes uncompressed
Comment 2 Jesse Keating 2009-03-16 19:32:38 EDT
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?
Comment 3 Jeremy Katz 2009-03-16 21:48:00 EDT
What version of squashfs-tools do you have on the box you're building on?
Comment 4 John Reiser 2009-03-16 22:38:44 EDT
$ rpm -q anaconda
$ rpm -q squashfs-tools
# 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) .
Comment 5 John Reiser 2009-03-16 23:35:41 EDT
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.
Comment 6 John Reiser 2009-03-16 23:37:59 EDT
Each of the 20 mirrors in mirrorlist.txt had the Package anaconda-, and all such *.rpm files had the same contents.  VT3 of the failed Rescue still said "anaconda-".
Comment 7 John Reiser 2009-03-19 15:43:19 EDT
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-
Comment 8 Jesse Keating 2009-03-19 15:57:53 EDT
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.
Comment 9 John Reiser 2009-03-19 23:40:36 EDT
"... 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 ( 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.
Comment 10 Jesse Keating 2009-03-20 00:12:48 EDT
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.
Comment 11 Bug Zapper 2009-06-09 08:17:19 EDT
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:
Comment 12 Bug Zapper 2010-03-15 08:29:12 EDT
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:
Comment 13 Jesse Keating 2010-05-25 18:01:04 EDT
I've created an upstream ticket to track this, cleaning out anaconda leftovers in work.

Note You need to log in before you can comment on or make changes to this bug.