Bug 1286866 - Installer image boot broken with dracut 044: squashfs not set up
Installer image boot broken with dracut 044: squashfs not set up
Product: Fedora
Classification: Fedora
Component: dracut (Show other bugs)
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: dracut-maint-list
Fedora Extras Quality Assurance
Depends On:
Blocks: F24AlphaBlocker
  Show dependency treegraph
Reported: 2015-11-30 18:10 EST by Adam Williamson
Modified: 2015-12-01 02:58 EST (History)
5 users (show)

See Also:
Fixed In Version: dracut-044-6.git20151201.fc24
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-12-01 02:58:43 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2015-11-30 18:10:26 EST
Even with https://bugzilla.redhat.com/show_bug.cgi?id=1285903 fixed, Rawhide nightly boot.iso's fail to boot, and this is still dracut's fault. I think I know what got broken.

If you boot a 2015-11-30 Rawhide nightly boot.iso , it fails to boot because /dev/root doesn't exist. In fact, /dev/root is a symlink to /dev/mapper/live-rw, which doesn't exist. On a working image (2015-11-12 is what I'm comparing with), /dev/mapper/live-rw is a symlink to /dev/dm-0 , which exists.

There is also an interesting error: "umount: /run/initramfs/squashfs: mountpoint not found"

What I think is going on is actually pretty simple: the changes in dracut 044 have made it so dmsquash-live-root.sh no longer sets up the squashfs for anaconda images properly. Specifically, this commit:


more specifically, the very first change in that commit. It makes it so this block:

    SQUASHED_LOOPDEV=$( losetup -f )
    mkdir -m 0755 -p /run/initramfs/squashfs
    mount -n -t squashfs -o ro $SQUASHED_LOOPDEV /run/initramfs/squashfs

only happens "if [ -e /run/initramfs/live/${live_dir}/${squash_image} ]". Previously, it happened "if [ -e "$SQUASHED" ]". Frederick Grose was, I think, assuming that $SQUASHED only gets set in that block anyway, but that is incorrect. It can also be set earlier in dmsquash-live-root.sh:

if [ -f $livedev ]; then
    # no mount needed - we've already got the LiveOS image in initramfs
    # check filesystem type and handle accordingly
    fstype=$(det_img_fs $livedev)
    case $fstype in
        squashfs) SQUASHED=$livedev;;

and that, I believe, is the case we hit with an anaconda boot. So in this case, the block of code that's intended to mount /run/initramfs/squashfs - from where an FSIMG will be found, and set up as /dev/mapper/live-rw - never gets run, so we never get an FSIMG and we never get a /dev/mapper/live-rw.
Comment 1 Adam Williamson 2015-11-30 18:12:42 EST
This again is an automatic blocker, "Complete failure of any release-blocking TC/RC image to boot at all under any circumstance - "DOA" image (conditional failure is not an automatic blocker)".
Comment 2 Adam Williamson 2015-11-30 18:41:35 EST
I can't be entirely sure, but I *think* the logic change was purely an erroneous 'optimization' - it's not significant to the live overlay case - so the fix would simply be to revert that change:

From 6a4d4912e1a853f0ed8e574fccfac1e076b79093 Mon Sep 17 00:00:00 2001
From: Adam Williamson <awilliam@redhat.com>
Date: Mon, 30 Nov 2015 15:31:33 -0800
Subject: [PATCH] fix squashfs setup for anaconda installer images (RHBZ

 modules.d/90dmsquash-live/dmsquash-live-root.sh | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/modules.d/90dmsquash-live/dmsquash-live-root.sh b/modules.d/90dmsquash-live/dmsquash-live-root.sh
index fa44a03..68d076c 100755
--- a/modules.d/90dmsquash-live/dmsquash-live-root.sh
+++ b/modules.d/90dmsquash-live/dmsquash-live-root.sh
@@ -203,6 +203,9 @@ fi
 # we might have an embedded fs image on squashfs (compressed live)
 if [ -e /run/initramfs/live/${live_dir}/${squash_image} ]; then
+if [ -e "$SQUASHED" ] ; then
     if [ -n "$live_ram" ]; then
         echo "Copying live image to RAM..."
         echo "(this may take a few minutes)"
Comment 3 Harald Hoyer 2015-12-01 02:58:43 EST
Many thanks for your detailed analysis!


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