Bug 798779 - Preupgrade from F16->F17 fails
Preupgrade from F16->F17 fails
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: preupgrade (Show other bugs)
17
i386 Linux
high Severity high
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-29 15:19 EST by Timothy Davis
Modified: 2013-08-01 12:21 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 12:20:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
failed boot screenshot (79 bytes, text/plain)
2012-02-29 15:48 EST, Timothy Davis
no flags Details
screenshot of dracut kernel panic (1.62 MB, image/jpeg)
2012-05-21 16:59 EDT, Alex Lancaster
no flags Details

  None (edit)
Description Timothy Davis 2012-02-29 15:19:37 EST
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)
Comment 1 Timothy Davis 2012-02-29 15:48:44 EST
Created attachment 566650 [details]
failed boot screenshot

Picassa album with failed boot screenshot and grub menu entry for Upgrade to F17
Comment 2 Harald Hoyer 2012-03-01 06:22:37 EST
I see: repo=hd::.... with two ":"

anyway, it seems like the whole process is fully ready for anaconda
Comment 3 Harald Hoyer 2012-03-01 06:29:30 EST
(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.
Comment 4 Timothy Davis 2012-03-01 11:50:32 EST
I tried adding repo=hd:UUID=<blkid inserted> and root=UUID=<blkid inserted>
but it still didn't boot into anaconda
Comment 5 Benjamin Hahne 2012-04-18 11:14:41 EDT
Having this symptom after selecting preupgrade from grub on physical hardware.  Also investigating as it worked fine on another machine.
Comment 6 Alex Lancaster 2012-05-11 19:15:43 EDT
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).
Comment 7 Adam Williamson 2012-05-11 20:34:04 EDT
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
Comment 8 Alex Lancaster 2012-05-17 17:27:23 EDT
(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.
Comment 9 Alex Lancaster 2012-05-21 16:59:44 EDT
Created attachment 585886 [details]
screenshot of dracut kernel panic

This is a screenshot of the failed boot attempt.
Comment 10 Alex Lancaster 2012-05-21 18:00:53 EDT
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".
Comment 11 Zeeshan Ali 2012-05-28 13:30:08 EDT
I'm seeing the same issue here.
Comment 12 Benjamin Hahne 2012-05-29 05:40:39 EDT
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.
Comment 13 MikeLeeds 2012-05-30 15:49:55 EDT
Similar problem for me, dracut failed to set root
Comment 14 MikeLeeds 2012-05-30 16:51:59 EDT
http://postimage.org/image/yna25ph6t/

Here is the error I get.
Comment 15 Adam Williamson 2012-05-30 21:37:05 EDT
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.
Comment 16 MikeLeeds 2012-05-31 06:04:59 EDT
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).
Comment 17 Adam Williamson 2012-05-31 12:21:36 EDT
You can get a log by passing the parameter 'rd.debug'. Then there should be a file /run/initramfs/init.log .
Comment 18 MikeLeeds 2012-05-31 13:10:14 EDT
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
Comment 19 Adam Williamson 2012-05-31 14:08:07 EDT
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.
Comment 20 Harald Hoyer 2012-06-04 03:28:32 EDT
(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
Comment 21 Harald Hoyer 2012-06-04 03:29:53 EDT
(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/
Comment 22 Harald Hoyer 2012-06-04 03:32:22 EDT
(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
Comment 23 Adam Williamson 2012-06-04 14:24:12 EDT
Yes. This is https://bugzilla.redhat.com/show_bug.cgi?id=813973 .
Comment 24 Fedora End Of Life 2013-07-04 01:19:58 EDT
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.
Comment 25 Fedora End Of Life 2013-08-01 12:21:00 EDT
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.

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