Bug 847644 - 18 Alpha TC1 install discs fail to boot, drop to emergency mode
18 Alpha TC1 install discs fail to boot, drop to emergency mode
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
18
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
AcceptedBlocker
:
Depends On:
Blocks: F18Alpha/F18AlphaBlocker
  Show dependency treegraph
 
Reported: 2012-08-13 04:21 EDT by Andre Robatino
Modified: 2013-01-10 01:53 EST (History)
11 users (show)

See Also:
Fixed In Version: anaconda-18.5-1.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-21 13:04:54 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dracut's output (202.96 KB, text/plain)
2012-08-14 08:25 EDT, Xibo Ning
no flags Details

  None (edit)
Description Andre Robatino 2012-08-13 04:21:40 EDT
Description of problem:
On booting any of the 18 Alpha TC1 install discs (i386 or x86_64, DVD or netinst) one is dropped to an emergency prompt. Most of the messages have to do with dracut. There is also an earlier line

SELinux: unable to find usable policy file:  No such file or directory

Version-Release number of selected component (if applicable):
18 Alpha TC1

How reproducible:
always

Additional info:
This is in a VirtualBox 4.1.18 VM, but vbox has worked reliably in BIOS boot before (EFI boot is a different story) so I think it's safe to assume this is a general problem.
Comment 1 Vadim Rutkovsky 2012-08-13 06:22:40 EDT
Here is a full log of qemu test - http://fpaste.org/c97b/
Comment 2 Joachim Backes 2012-08-13 07:31:14 EDT
Same with Fedora-18-Alpha-TC1-x86_64-netinst.iso
Comment 3 Vadim Rutkovsky 2012-08-13 07:50:26 EDT
Solved by adding 'root=live:CDLABEL=Fedora\x2018-Alpha-TC1\x20x86_64' to boot line
Comment 4 Adam Williamson 2012-08-13 22:34:32 EDT
I see a lot of 'basename: command not found' in the log, for what it's worth. Seems like that's missing from some environment it needs to be in.
Comment 5 Xibo Ning 2012-08-14 08:24:48 EDT
When installing F18 in kvm from Fedora-18-Alpha-TC1-x86_64-DVD.iso, dracut always fails because '/dev/root does not exist'.
Removing 'quiet' from kernel commandd line and adding the following options to kernel command line, I get more detailed dracut output:
    rd.shell rd.debug log_buf_len=2M
I find /lib/dracut/hooks/pre-udev/30-block-genrules.sh has something with '/dev/root':

    if [ "${root%%:*}" = "block" ]; then
        {
            printf 'KERNEL=="%s", SYMLINK+="root"\n' \
                ${root#block:/dev/}
            printf 'SYMLINK=="%s", SYMLINK+="root"\n' \
                ${root#block:/dev/}
        } >> /etc/udev/rules.d/99-root.rules

        printf '[ -e "%s" ] && { ln -s "%s" /dev/root 2>/dev/null; rm "$job"; }\n' \
            "${root#block:}" "${root#block:}" > $hookdir/initqueue/settled/blocksymlink.sh
        wait_for_dev "${root#block:}"
    fi

But /dracut-state.sh has the following line:
    export root="anaconda-auto-cd"
Comment 6 Xibo Ning 2012-08-14 08:25:41 EDT
Created attachment 604284 [details]
dracut's output
Comment 7 Adam Williamson 2012-08-14 15:01:49 EDT
anaconda team do daily boot.iso composes for testing, and they claim those images are working fine, so the problem must be something in the releng compose process. dennis, any idea what that might be?
Comment 8 Dennis Gilmore 2012-08-14 17:11:46 EDT
no idea we are using f18 chroots on a f18 box the same as we always do. all fully updated
Comment 9 Adam Williamson 2012-08-14 18:52:29 EDT
jesse and brian think the lack of 'basename' that I identified - it was taken out of dracut last month - could indeed be causing this. they're looking at replacing use of basename with bash tricks now (which is what dracut did).

<jlk> so instead of using $(basename $1), dracut does $(${1##*/})
 so we could do similar in our dracut code
Comment 10 Jesse Keating 2012-08-15 15:09:27 EDT
Root cause here was a change in dracut behaviour in how the shells from one stage to another were handled.  In our repo-genrules.sh script we make use of a variable that is defined in /lib/anaconda-lib.sh, which is sourced into the shell in earlier dracut stages.  Previously this sourcing would be persistent across the dracut stages so we could rely on the variable existing.  In current dracut that assumption fails, and we have to handle this and (re) source in anaconda-lib.sh if necessary.

A patch was submitted and pushed to fix this up.  The basename failure was orthogonal to this issue.  root= is not required, nor desired to be in the command line, the only reason it worked as a work around was because the existence of root= on the command line bypassed the bit of code where we relied on anaconda-lib.sh variable.

This issue will be fixed in the next build of anaconda.
Comment 11 Adam Williamson 2012-08-16 01:15:41 EDT
TC2 seems to confirm the fix; boot proceeds as expected.
Comment 12 Andre Robatino 2012-08-16 01:31:23 EDT
There's no visible sign of the expected mediacheck when using the default boot menu item, though. Is it not working, or just not printing the usual output?
Comment 13 Adam Williamson 2012-08-16 02:26:57 EDT
It takes notably longer than a non-check boot, so it's doing _something_. That's outside the scope of this bug, anyhow.
Comment 14 Adam Williamson 2012-08-16 15:00:07 EDT
Discussed at 2012-08-16 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-08-16/f18-alpha-blocker-review-3.2012-08-16-16.00.html . Accepted as a blocker per criterion "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods" (note, the meeting summary incorrectly cited a different criterion, this was just a mistake). We're confident this is fixed with the new anaconda build, it just needs to go stable before the bug is closed.
Comment 15 Adam Williamson 2012-08-21 13:04:54 EDT
anaconda 18.6 is now stable, so closing this.

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