Here is a full log of qemu test - http://fpaste.org/c97b/

Same with Fedora-18-Alpha-TC1-x86_64-netinst.iso

Solved by adding 'root=live:CDLABEL=Fedora\x2018-Alpha-TC1\x20x86_64' to boot line

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.

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"

Created attachment 604284 [details]
dracut's output

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?

no idea we are using f18 chroots on a f18 box the same as we always do. all fully updated

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

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.

TC2 seems to confirm the fix; boot proceeds as expected.

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?

It takes notably longer than a non-check boot, so it's doing _something_. That's outside the scope of this bug, anyhow.

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.

anaconda 18.6 is now stable, so closing this.