Bug 847644 - 18 Alpha TC1 install discs fail to boot, drop to emergency mode
Summary: 18 Alpha TC1 install discs fail to boot, drop to emergency mode
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 18
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F18Alpha, F18AlphaBlocker
TreeView+ depends on / blocked
Reported: 2012-08-13 08:21 UTC by Andre Robatino
Modified: 2013-01-10 06:53 UTC (History)
11 users (show)

Fixed In Version: anaconda-18.5-1.fc18
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-08-21 17:04:54 UTC
Type: Bug

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

Description Andre Robatino 2012-08-13 08:21:40 UTC
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:

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 10:22:40 UTC
Here is a full log of qemu test - http://fpaste.org/c97b/

Comment 2 Joachim Backes 2012-08-13 11:31:14 UTC
Same with Fedora-18-Alpha-TC1-x86_64-netinst.iso

Comment 3 Vadim Rutkovsky 2012-08-13 11:50:26 UTC
Solved by adding 'root=live:CDLABEL=Fedora\x2018-Alpha-TC1\x20x86_64' to boot line

Comment 4 Adam Williamson 2012-08-14 02:34:32 UTC
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 12:24:48 UTC
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' \
            printf 'SYMLINK=="%s", SYMLINK+="root"\n' \
        } >> /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:}"

But /dracut-state.sh has the following line:
    export root="anaconda-auto-cd"

Comment 6 Xibo Ning 2012-08-14 12:25:41 UTC
Created attachment 604284 [details]
dracut's output

Comment 7 Adam Williamson 2012-08-14 19:01:49 UTC
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 21:11:46 UTC
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 22:52:29 UTC
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 19:09:27 UTC
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 05:15:41 UTC
TC2 seems to confirm the fix; boot proceeds as expected.

Comment 12 Andre Robatino 2012-08-16 05:31:23 UTC
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 06:26:57 UTC
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 19:00:07 UTC
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 17:04:54 UTC
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.