Description of problem: After runnning preupgrade on an updated F16 install rebooting into the new system from grub menu fails stating dracut failed to set root= argument Version-Release number of selected component (if applicable): preupgrade-1.1.10-1.fc16.noarch dracut-013-20.fc16.noarch How reproducible: every reboot into preugraded F17 system Steps to Reproduce: 1. update f16 system 2. install then run preupgrade 3. reboot into F17 system Actual results: kernel panic Expected results: upgrade should complete Additional info: I don't know where any of the logs are stored This is in a Vbox system (32Gb HD, 1Gb RAM)
Created attachment 566650 [details] failed boot screenshot Picassa album with failed boot screenshot and grub menu entry for Upgrade to F17
I see: repo=hd::.... with two ":" anyway, it seems like the whole process is fully ready for anaconda
(In reply to comment #2) > I see: repo=hd::.... with two ":" > > anyway, it seems like the whole process is fully ready for anaconda anyway, it seems like the whole process is not fully thought through with the new anaconda layout.
I tried adding repo=hd:UUID=<blkid inserted> and root=UUID=<blkid inserted> but it still didn't boot into anaconda
Having this symptom after selecting preupgrade from grub on physical hardware. Also investigating as it worked fine on another machine.
I'm seeing the same issue. I tried inserting the "UUID=<blkid inserted>" into repo as per comment #4, but dracut fails with something to the effect of "couldn't find root". My grub config looks like this: setparams 'Upgrade to Fedora 17 (Beefy Miracle)' linux /upgrade/vmlinuz preupgrade repo=hd:UUID=<blkid>:/var/cache/yum/preupgrade ks=hd:UUID=<blkid>:/upgrade/ks.cfg stage2=hd:UUID=<blkid>:/upgrade/squashfs.img acpi=off initrd /ugprade/initrd.img (I had previously needed to add "acpi=off" to get this to boot on this machine).
Alex: it's very unlikely to be 'the same' issue; preupgrade was known to be broken before Beta, which is when most of the above reports come from, but it should have been working since then, and we verified in Beta validation testing that it is. So this may be somehow specific to your setup. Can you give us at least the precise output from dracut? Maybe a picture? Thanks! I think the original bug here is likely a dupe of one of the ones we closed around Beta time. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #7) > Alex: it's very unlikely to be 'the same' issue; preupgrade was known to be > broken before Beta, which is when most of the above reports come from, but it > should have been working since then, and we verified in Beta validation testing > that it is. So this may be somehow specific to your setup. Can you give us at > least the precise output from dracut? Maybe a picture? Thanks! I will try and do that. I believe it's almost identical to the googleplus image above, but I'll try to capture my screen and post it here. > I think the original bug here is likely a dupe of one of the ones we closed > around Beta time.
Created attachment 585886 [details] screenshot of dracut kernel panic This is a screenshot of the failed boot attempt.
Also, I was trying to change component to "preupgrade" (from "anaconda"), but for some reason, the component inadvertantly got set to "0xFFFF", I can't see how to change it back to "preupgrade".
I'm seeing the same issue here.
OK, I meant to post this a while back. I surmised that my main problem was my small (200Mb) /boot partition, separate to the rest of the hard drive partitioned as LVM (which made it difficult to resize /boot). I 'resolved' my issue by buying a new hard drive and installing fresh... Posted mostly in case others have a similar config with the same symptoms.
Similar problem for me, dracut failed to set root
http://postimage.org/image/yna25ph6t/ Here is the error I get.
That's not a 'similar problem'. The error about /dev/root is an extremely generic one. Pretty much _anything_ that fails during the dracut stage will result in that error message, because the ultimate point of the dracut stage is to set up /dev/root for the second stage... So, basically, posting that error message tells us nothing. =) Are there any other errors _prior_ to it? That'd be much more interesting. Your kernel cmdline may also help.
I don't see any obvious errors - is there a log somewhere? I did get a couple of 404 file not found errors, then ``XX responds: file exists'' or similar. I saved the squashfs.img file oh my / partition and altered my grub.cfg to read stage2=hd:/var/cache/squashfs.img but this didn't change the final error I got (unsurprisingly).
You can get a log by passing the parameter 'rd.debug'. Then there should be a file /run/initramfs/init.log .
Here's the file: http://pastebin.com/Z2B6ep1w Quite long, I can't find what's wrong except Unable to process initqueue and some repitition
It would be much better to attach the file, as pastebins expire. However, you should really probably create a new bug. As I've already said, your bug is likely not this bug, so we should be discussing it separately.
(In reply to comment #18) > Here's the file: > http://pastebin.com/Z2B6ep1w > > Quite long, I can't find what's wrong except Unable to process initqueue and > some repitition ////lib/url-lib.sh@70(curl_fetch_url): curl --location --retry 3 --fail --show-error --progress-bar --remote-name http://mirror01.th.ifl.net/fedora/linux/releases/17/Fedora/x86_64/os/LiveOS/squashfs.img/.treeinfo curl: (22) The requested URL returned error: 404 you should open a new bug against anaconda
(In reply to comment #20) > (In reply to comment #18) > > Here's the file: > > http://pastebin.com/Z2B6ep1w > > > > Quite long, I can't find what's wrong except Unable to process initqueue and > > some repitition > > ////lib/url-lib.sh@70(curl_fetch_url): curl --location --retry 3 --fail > --show-error --progress-bar --remote-name > http://mirror01.th.ifl.net/fedora/linux/releases/17/Fedora/x86_64/os/LiveOS/ > squashfs.img/.treeinfo > > curl: (22) The requested URL returned error: 404 > > you should open a new bug against anaconda stage2=http://mirror01.th.ifl.net/fedora/linux/releases/17/Fedora/x86_64/os/LiveOS/squashfs.img seems to be from preupgrade... try to replace it with: stage2=http://mirror01.th.ifl.net/fedora/linux/releases/17/Fedora/x86_64/os/LiveOS/
(In reply to comment #21) > (In reply to comment #20) > > (In reply to comment #18) > > > Here's the file: > > > http://pastebin.com/Z2B6ep1w > > > > > > Quite long, I can't find what's wrong except Unable to process initqueue and > > > some repitition > > > > ////lib/url-lib.sh@70(curl_fetch_url): curl --location --retry 3 --fail > > --show-error --progress-bar --remote-name > > http://mirror01.th.ifl.net/fedora/linux/releases/17/Fedora/x86_64/os/LiveOS/ > > squashfs.img/.treeinfo > > > > curl: (22) The requested URL returned error: 404 > > > > you should open a new bug against anaconda > > stage2=http://mirror01.th.ifl.net/fedora/linux/releases/17/Fedora/x86_64/os/ > LiveOS/squashfs.img > > seems to be from preupgrade... try to replace it with: > > stage2=http://mirror01.th.ifl.net/fedora/linux/releases/17/Fedora/x86_64/os/ > LiveOS/ ah... sorry: stage2=http://mirror01.th.ifl.net/fedora/linux/releases/17/Fedora/x86_64/os/ see bug 826272
Yes. This is https://bugzilla.redhat.com/show_bug.cgi?id=813973 .
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.