Bug 499321 - preupgrade backtrace
preupgrade backtrace
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
12
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Lumens
Fedora Extras Quality Assurance
anaconda_trace_hash:627ff8d3099a44e0b...
: Reopened
: 499407 499966 500533 501282 511929 540085 (view as bug list)
Depends On:
Blocks: F11Blocker/F11FinalBlocker 504274
  Show dependency treegraph
 
Reported: 2009-05-06 02:24 EDT by Jens Petersen
Modified: 2011-03-16 08:17 EDT (History)
52 users (show)

See Also:
Fixed In Version: anaconda-13.9-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 504274 (view as bug list)
Environment:
Last Closed: 2009-11-25 15:18:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Attached traceback automatically from anaconda. (48.50 KB, text/plain)
2009-05-06 02:25 EDT, Jens Petersen
no flags Details
Attached traceback automatically from anaconda. (48.14 KB, text/plain)
2009-05-06 05:12 EDT, Matthias Runge
no flags Details
Attached traceback automatically from anaconda. (72.43 KB, text/plain)
2009-05-08 00:21 EDT, Matt Domsch
no flags Details
Attached traceback automatically from anaconda. (91.69 KB, text/plain)
2009-05-08 04:41 EDT, Matthias Runge
no flags Details
Attached traceback automatically from anaconda. (47.30 KB, text/plain)
2009-05-08 06:51 EDT, Matthias Runge
no flags Details
Attached traceback automatically from anaconda. (46.85 KB, text/plain)
2009-05-08 23:02 EDT, Jens Petersen
no flags Details
Attached traceback automatically from anaconda. (70.40 KB, text/plain)
2009-05-09 06:25 EDT, Frank Murphy
no flags Details
Attached traceback automatically from anaconda. (80.08 KB, text/plain)
2009-05-10 08:06 EDT, Maxim Evdokimov
no flags Details
Attached traceback automatically from anaconda. (71.88 KB, text/plain)
2009-05-10 18:23 EDT, Matt Domsch
no flags Details
Attached traceback automatically from anaconda. (71.86 KB, text/plain)
2009-05-11 09:17 EDT, Andrew Jamison
no flags Details
Attached traceback automatically from anaconda. (49.88 KB, text/plain)
2009-05-14 21:48 EDT, Jens Petersen
no flags Details
Attached traceback automatically from anaconda. (47.38 KB, text/plain)
2009-05-15 02:59 EDT, Matthias Runge
no flags Details
Attached traceback automatically from anaconda. (85.29 KB, text/plain)
2009-05-15 08:58 EDT, Sesh
no flags Details
Attached traceback automatically from anaconda. (58.08 KB, text/plain)
2009-05-16 04:16 EDT, David Andersson
no flags Details
Attached traceback automatically from anaconda. (91.57 KB, text/plain)
2009-05-17 13:56 EDT, Alexandre Nazarenko
no flags Details
Attached traceback automatically from anaconda. (65.06 KB, text/plain)
2009-05-18 05:01 EDT, Ed Avis
no flags Details
Attached traceback automatically from anaconda. (67.78 KB, text/plain)
2009-05-18 06:52 EDT, Tomasz Torcz
no flags Details
Attached traceback automatically from anaconda. (58.83 KB, text/plain)
2009-05-27 21:58 EDT, Bob Tyler
no flags Details
Attached traceback automatically from anaconda. (82.72 KB, text/plain)
2009-06-04 13:47 EDT, James Laska
no flags Details
Attached traceback automatically from anaconda. (89.71 KB, text/plain)
2009-06-24 00:48 EDT, kiransringeri
no flags Details
Attached traceback automatically from anaconda. (71.73 KB, text/plain)
2009-06-24 02:13 EDT, Roman Rakus
no flags Details
Attached traceback automatically from anaconda. (83.81 KB, text/plain)
2009-07-01 09:17 EDT, Nitin Thakur
no flags Details
Attached traceback automatically from anaconda. (86.60 KB, text/plain)
2009-07-01 11:40 EDT, Nitin Thakur
no flags Details
Attached traceback automatically from anaconda. (45.06 KB, text/plain)
2009-07-03 09:30 EDT, Alexey Kuznetsov
no flags Details
Attached traceback automatically from anaconda. (82.01 KB, text/plain)
2009-07-06 21:45 EDT, Jim Constantine
no flags Details
Attached traceback automatically from anaconda. (81.89 KB, text/plain)
2009-07-06 22:53 EDT, Jim Constantine
no flags Details
Attached traceback automatically from anaconda. (96.28 KB, text/plain)
2009-07-10 05:26 EDT, Ask Bjørn Hansen
no flags Details
Attached traceback automatically from anaconda. (81.93 KB, text/plain)
2009-07-13 16:56 EDT, alauschke
no flags Details
Attached traceback automatically from anaconda. (81.16 KB, text/plain)
2009-07-15 16:27 EDT, zetsueii
no flags Details
Attached traceback automatically from anaconda. (78.94 KB, text/plain)
2009-07-20 15:37 EDT, Maui Jim
no flags Details
Attached traceback automatically from anaconda. (40.27 KB, text/plain)
2009-07-20 22:17 EDT, Paul Kennedy
no flags Details
Attached traceback automatically from anaconda. (162.30 KB, text/plain)
2009-07-21 18:52 EDT, Bob Cunningham
no flags Details
Attached traceback automatically from anaconda. (180.92 KB, text/plain)
2009-07-22 11:47 EDT, Bob Cunningham
no flags Details
Attached traceback automatically from anaconda. (180.89 KB, text/plain)
2009-07-22 13:36 EDT, Bob Cunningham
no flags Details
Attached traceback automatically from anaconda. (90.96 KB, text/plain)
2009-07-24 00:38 EDT, Greg Morgan
no flags Details
Attached traceback automatically from anaconda. (100.03 KB, text/plain)
2009-07-24 01:40 EDT, Greg Morgan
no flags Details
Attached traceback automatically from anaconda. (102.23 KB, text/plain)
2009-07-24 02:30 EDT, Thomas Hallgren
no flags Details
Attached traceback automatically from anaconda. (106.13 KB, text/plain)
2009-07-24 08:23 EDT, Thomas Hallgren
no flags Details
My /etc/fstab (824 bytes, text/plain)
2009-07-24 16:42 EDT, Thomas Hallgren
no flags Details
Attached traceback automatically from anaconda. (98.62 KB, text/plain)
2009-07-29 13:52 EDT, Peter R. Thorsen Jr.
no flags Details
Attached traceback automatically from anaconda. (54.37 KB, text/plain)
2009-08-09 08:12 EDT, Svilen Krustev
no flags Details
Attached traceback automatically from anaconda. (72.23 KB, text/plain)
2009-08-16 15:42 EDT, Jim Gribbin
no flags Details
Attached traceback automatically from anaconda. (56.08 KB, text/plain)
2009-08-20 09:03 EDT, Oliver Ruebenacker
no flags Details
Attached traceback automatically from anaconda. (87.30 KB, text/plain)
2009-09-05 02:47 EDT, Jim Constantine
no flags Details
Attached traceback automatically from anaconda. (56.08 KB, text/plain)
2009-09-17 08:52 EDT, Oliver Ruebenacker
no flags Details
Attached traceback automatically from anaconda. (123.46 KB, text/plain)
2009-09-28 22:00 EDT, Matthew
no flags Details
Attached traceback automatically from anaconda. (56.67 KB, text/plain)
2009-10-08 09:56 EDT, Oliver Ruebenacker
no flags Details
Attached traceback automatically from anaconda. (56.11 KB, text/plain)
2009-10-15 10:22 EDT, Oliver Ruebenacker
no flags Details
Attached traceback automatically from anaconda. (56.08 KB, text/plain)
2009-10-22 11:40 EDT, Oliver Ruebenacker
no flags Details
Attached traceback automatically from anaconda. (102.08 KB, text/plain)
2009-10-28 21:07 EDT, systemssoftware
no flags Details
Attached traceback automatically from anaconda. (56.68 KB, text/plain)
2009-10-29 12:51 EDT, Oliver Ruebenacker
no flags Details
Attached traceback automatically from anaconda. (56.69 KB, text/plain)
2009-11-05 15:42 EST, Oliver Ruebenacker
no flags Details
Attached traceback automatically from anaconda. (87.96 KB, text/plain)
2009-11-12 14:30 EST, Robert Weir
no flags Details
Attached traceback automatically from anaconda. (136.60 KB, text/plain)
2011-03-16 08:13 EDT, Peter
no flags Details
Attached traceback automatically from anaconda. (137.36 KB, text/plain)
2011-03-16 08:17 EDT, Peter
no flags Details

  None (edit)
Description Jens Petersen 2009-05-06 02:24:58 EDT
The following was filed automatically by anaconda:
anaconda 11.5.0.49 exception report
Traceback (most recent call first):
  File "/usr/lib/anaconda/gui.py", line 1377, in setScreen
    if not stepToClass[step]:
  File "/usr/lib/anaconda/gui.py", line 1535, in setup_window
    self.setScreen()
  File "/usr/lib/anaconda/gui.py", line 1545, in run
    self.setup_window(runres)
  File "/usr/lib/anaconda/gui.py", line 1292, in run
    self.icw.run (self.runres)
  File "/usr/bin/anaconda", line 966, in <module>
    anaconda.intf.run(anaconda)
KeyError: 'findrootparts'
Comment 1 Jens Petersen 2009-05-06 02:25:03 EDT
Created attachment 342596 [details]
Attached traceback automatically from anaconda.
Comment 2 Matthias Runge 2009-05-06 05:12:38 EDT
Created attachment 342621 [details]
Attached traceback automatically from anaconda.
Comment 3 Chris Lumens 2009-05-06 11:03:53 EDT
*** Bug 499407 has been marked as a duplicate of this bug. ***
Comment 4 Chris Lumens 2009-05-06 16:17:17 EDT
This should be fixed in the next build of anaconda.  Thanks for the bug report.
Comment 5 Matt Domsch 2009-05-08 00:21:24 EDT
Created attachment 342992 [details]
Attached traceback automatically from anaconda.
Comment 6 Matthias Runge 2009-05-08 04:41:03 EDT
Created attachment 343058 [details]
Attached traceback automatically from anaconda.
Comment 7 Matthias Runge 2009-05-08 04:42:58 EDT
sadly, this seemed to be the latest version of anaconda.
Comment 8 Matthias Runge 2009-05-08 06:51:20 EDT
Created attachment 343069 [details]
Attached traceback automatically from anaconda.
Comment 9 Jens Petersen 2009-05-08 23:02:54 EDT
Created attachment 343195 [details]
Attached traceback automatically from anaconda.
Comment 10 Alexander Boström 2009-05-09 04:00:11 EDT
I've seen this too, with anaconda version 11.5.0.51 on i386, started through preupgrade.

Any suggestions about information I can provide? Any workarounds?
Comment 11 Frank Murphy 2009-05-09 06:25:54 EDT
Created attachment 343201 [details]
Attached traceback automatically from anaconda.
Comment 12 Alexander Boström 2009-05-09 18:54:39 EDT
I think I figured it out.

In anaconda/kickstart.py, ClearPart.parse() is never called because we have no clearpart command in ks.cfg. Thus in fullCommandPass(), earlyKS.clearpart.type will be None.

In anaconda/storage/devicetree.py, handleUdevDeviceFormat() will call shouldClear() with clearPartType=None instead of CLEARPART_TYPE_NONE, which causes it to return True and thus handleUdevLVMPVFormat() is never called, so all logical volumes are ignored.

What is the right fix?

In pykickstart/commands/clearpart.py, FC3_ClearPart() could be changed to set self.type to CLEARPART_TYPE_NONE by default. But perhaps that would break something else?

Or ClearPart() could gain an __init__() that fixes self.type.

Or fix it in fullCommandPass(), handleUdevDeviceFormat() or shouldClear().
Comment 13 Maxim Evdokimov 2009-05-10 08:06:33 EDT
Created attachment 343259 [details]
Attached traceback automatically from anaconda.
Comment 14 Matt Domsch 2009-05-10 18:23:22 EDT
Created attachment 343305 [details]
Attached traceback automatically from anaconda.
Comment 15 Andrew Jamison 2009-05-11 09:17:46 EDT
Created attachment 343444 [details]
Attached traceback automatically from anaconda.
Comment 16 Matt Domsch 2009-05-11 09:25:03 EDT
Adding to F11Blocker, as this prevents preupgrade from working at all.
Comment 17 Chris Lumens 2009-05-11 10:02:23 EDT
*** Bug 499966 has been marked as a duplicate of this bug. ***
Comment 18 Chris Lumens 2009-05-11 15:11:27 EDT
Okay, I was able to reproduce it here.  Thanks for the thorough debugging, Alexander.  It was very helpful.  This should be fixed in the next build of anaconda.
Comment 19 Will Woods 2009-05-12 16:03:51 EDT
Fix confirmed using updates=http://clumens.fedorapeople.org/499321.img
Comment 20 Matt Domsch 2009-05-13 01:07:16 EDT
likewise, I confirm the fix using updates=http://clumens.fedorapeople.org/499321.img
Comment 21 Chris Lumens 2009-05-13 09:14:03 EDT
*** Bug 500533 has been marked as a duplicate of this bug. ***
Comment 22 Jamie Anderson 2009-05-14 10:02:04 EDT
Also fixed by using updates=http://clumens.fedorapeople.org/499321.img
Comment 23 Jens Petersen 2009-05-14 21:48:29 EDT
Created attachment 344069 [details]
Attached traceback automatically from anaconda.
Comment 24 Jens Petersen 2009-05-14 22:11:45 EDT
Leaving this open until this is fixed in rawhide.

-52 still doesn't preupgrade for me in kvm anyway.
Comment 25 Jens Petersen 2009-05-14 23:09:25 EDT
I see 499321.img working with -52 too at least.
Comment 26 Matthias Runge 2009-05-15 02:59:08 EDT
Created attachment 344085 [details]
Attached traceback automatically from anaconda.
Comment 27 Matthias Runge 2009-05-15 03:21:29 EDT
Steps to reproduce:
1. Install F10
2. Use preupgrade to upgrade to rawhide
3. reboot

My ks.cfg looks like:
# ks.cfg generated by preupgrade
lang en_IE.UTF-8
keyboard de
bootloader --upgrade
upgrade
reboot


%post
grubby --remove-kernel=/boot/upgrade/vmlinuz
rm -rf /boot/upgrade /var/cache/yum/preupgrade*
%end

I hope, this helps to tear down this bug.
Comment 28 Sesh 2009-05-15 08:58:49 EDT
Created attachment 344145 [details]
Attached traceback automatically from anaconda.
Comment 29 Chris Lumens 2009-05-15 14:53:07 EDT
Okay, pushed another fix for this issue.  Next build of anaconda, etc.
Comment 30 Will Woods 2009-05-15 16:29:11 EDT
Fix confirmed! 

I applied the aforementioned fix (git commit 49f88cf3) to anaconda 11.0.5.52 and created http://wwoods.fedorapeople.org/499321.img - everything works as expected with that image.
Comment 31 David Andersson 2009-05-16 04:16:39 EDT
Created attachment 344262 [details]
Attached traceback automatically from anaconda.
Comment 32 Alexandre Nazarenko 2009-05-17 13:56:25 EDT
Created attachment 344340 [details]
Attached traceback automatically from anaconda.
Comment 33 Ed Avis 2009-05-18 05:01:36 EDT
Created attachment 344404 [details]
Attached traceback automatically from anaconda.
Comment 34 Tomasz Torcz 2009-05-18 06:52:38 EDT
Created attachment 344415 [details]
Attached traceback automatically from anaconda.
Comment 35 Matthias Runge 2009-05-18 07:01:09 EDT
For those waiting to upgrade:
appending updates=http://clumens.fedorapeople.org/499321.img to the kernel command line at grub.conf worked for me. Just add the updates.... to the kernel command line after calling preupgrade and before reboot.

(Version anaconda 11.0.5.52)
Comment 36 Tomasz Torcz 2009-05-18 09:13:53 EDT
*** Bug 501282 has been marked as a duplicate of this bug. ***
Comment 37 Ed Avis 2009-05-19 02:46:19 EDT
I confirm that adding updates=http://clumens.fedorapeople.org/499321.img to the grub.conf line fixes it.  Thanks.
Comment 38 Will Woods 2009-05-19 12:16:26 EDT
This appears to be fixed with anaconda-11.5.0.53, which is in today's Rawhide.
Comment 39 Jens Petersen 2009-05-21 06:01:02 EDT
Yep also confirmed working with build 54.
Comment 40 Bob Tyler 2009-05-27 21:58:11 EDT
Created attachment 345693 [details]
Attached traceback automatically from anaconda.
Comment 41 James Laska 2009-06-04 13:47:27 EDT
Created attachment 346574 [details]
Attached traceback automatically from anaconda.
Comment 42 James Laska 2009-06-04 13:53:27 EDT
Reproduced with anaconda-11.5.0.59

= Steps to reproduce =

1) Complete install of F10
2) Initiate kickstart upgrade to F11 using the following kickstart

#version=F11
# Firewall configuration
firewall --disabled
# Upgrade existing installation
upgrade
# Root password
rootpw --iscrypted $1$xafj7qlW$6swjxMwu0po47drJVRcIZ/
# System keyboard
keyboard us
# System language
lang en_US
# Installation logging level
logging --level=info
# Use network installation
url --url=http://dell-t5400.test.redhat.com:80/cblr/links/F-11-RC4-i386
# Reboot after installation
reboot
# System timezone
timezone --isUtc America/New_York
# System bootloader configuration
bootloader --location=mbr --upgrade

3) Installer indicates it could not find the partition for the previous install
4) Select [Back] ... crash

Should this be filed as a new bug?
Comment 43 Radek Vykydal 2009-06-05 05:32:06 EDT
James, I've just pushed fix for bug #503310 and bug #503681 (commit 93fd07cd4cb46dad0d57bf216e603c8256751480) into rawhide which in my test fixed your case from comment #42. It doesn't address traceback from 4), but finds partition of previous install in 3).

Just a note:
For preupgrade it is not the case, but for upgrade set in ks, if there really are not any root parts to upgrade, we will meet the same traceback after going back from the message (which shouldn't be offered in this case), but I think it should be another bug.
Comment 44 James Laska 2009-06-05 10:33:40 EDT
Per discussion with Radek on IRC, I will close this bug out as the original issue affecting preupgrade is resolved. 

Bug#504274 will track the failure when upgrading via kickstart
Comment 45 Radek Vykydal 2009-06-23 11:52:09 EDT
I am reopening the bug because automatic reports having the traceback from description concerning preupgrade have been going to clone of this bug: bug #504274 which has the same traceback but deals only with ks upgrade case and is fixed in rawhide, so I am closing it.

Comments 3-14 from bug #504274 should belong this bug (they contain 9 tracebacks and some additional information).
I am adding their reporters to CC List of this bug.
Comment 46 kiransringeri 2009-06-24 00:48:25 EDT
Created attachment 349191 [details]
Attached traceback automatically from anaconda.
Comment 47 Roman Rakus 2009-06-24 02:13:42 EDT
Created attachment 349199 [details]
Attached traceback automatically from anaconda.
Comment 48 Nitin Thakur 2009-07-01 09:17:46 EDT
Created attachment 350107 [details]
Attached traceback automatically from anaconda.
Comment 49 Nitin Thakur 2009-07-01 11:40:13 EDT
Created attachment 350139 [details]
Attached traceback automatically from anaconda.
Comment 50 Alexey Kuznetsov 2009-07-03 09:30:08 EDT
Created attachment 350432 [details]
Attached traceback automatically from anaconda.
Comment 51 Jim Constantine 2009-07-06 21:45:04 EDT
Created attachment 350709 [details]
Attached traceback automatically from anaconda.
Comment 52 Jim Constantine 2009-07-06 21:57:34 EDT
Which is an update to this issue that was lodged of mine? I can't seem to find which one will suit my bug report... Our gateway is down for now but if someone knows what will fix this please let me know.
Comment 53 Jim Constantine 2009-07-06 22:53:18 EDT
Created attachment 350726 [details]
Attached traceback automatically from anaconda.
Comment 54 Ask Bjørn Hansen 2009-07-10 05:26:18 EDT
Created attachment 351227 [details]
Attached traceback automatically from anaconda.
Comment 55 alauschke 2009-07-13 16:56:39 EDT
Created attachment 351524 [details]
Attached traceback automatically from anaconda.
Comment 56 Andy Lindeberg 2009-07-15 14:22:51 EDT
*** Bug 511929 has been marked as a duplicate of this bug. ***
Comment 57 Bob Cunningham 2009-07-15 15:13:10 EDT
I'm the creator of Bug 511929, and I do not see how this bug is a duplicate of it, since I don't really understand what this bug talks about.

The workaround described in Comment #37 does not work for me, since the URL given in that comment is broken.

What must I do to perform a successful preupgrade from f10 to f11?

1. Is there a patched version of preupgrade somewhere that I can use?
2. Is there a workaround that works?
3. Will a fix to this bug be pushed into the f10 repositories?
4. Is there a better/safer way for me to upgrade, than using the currently broken f10 preupgrade method?
Comment 58 zetsueii 2009-07-15 16:27:06 EDT
Created attachment 353904 [details]
Attached traceback automatically from anaconda.
Comment 59 Radek Vykydal 2009-07-20 13:07:03 EDT
(In reply to comment #57)
> I'm the creator of Bug 511929, and I do not see how this bug is a duplicate of
> it, since I don't really understand what this bug talks about.
> 
> The workaround described in Comment #37 does not work for me, since the URL
> given in that comment is broken.
> 
> What must I do to perform a successful preupgrade from f10 to f11?
> 
> 1. Is there a patched version of preupgrade somewhere that I can use?
> 2. Is there a workaround that works?
> 3. Will a fix to this bug be pushed into the f10 repositories?
> 4. Is there a better/safer way for me to upgrade, than using the currently
> broken f10 preupgrade method?

The tracebacks attached to this bug are telling me that multiple causes can lead to anaconda not being able to find existing root partition. Quite a lot of them seem to be related to BIOS-RAID detection problems (changes between f10 and f11).
We don't have generic workaround or patch. Can you please attach traceback dump? It may help us to see what the cause in your case can be.

Now I can only suggest to try to upgrade using F11 installation disk (without using kickstart). Other possibility is to upgrade using yum, though I am not sure how well it works for f11 - you can see http://fedoraproject.org/wiki/YumUpgradeFaq.
Comment 60 Maui Jim 2009-07-20 15:37:51 EDT
Created attachment 354382 [details]
Attached traceback automatically from anaconda.
Comment 61 Bob Cunningham 2009-07-20 16:35:42 EDT
(In reply to comment #59)
> (In reply to comment #57)
> > I'm the creator of Bug 511929, and I do not see how this bug is a duplicate of
> > it, since I don't really understand what this bug talks about.
> > 
> > The workaround described in Comment #37 does not work for me, since the URL
> > given in that comment is broken.
> > 
> > What must I do to perform a successful preupgrade from f10 to f11?
> > 
> > 1. Is there a patched version of preupgrade somewhere that I can use?
> > 2. Is there a workaround that works?
> > 3. Will a fix to this bug be pushed into the f10 repositories?
> > 4. Is there a better/safer way for me to upgrade, than using the currently
> > broken f10 preupgrade method?
> 
> The tracebacks attached to this bug are telling me that multiple causes can
> lead to anaconda not being able to find existing root partition. Quite a lot of
> them seem to be related to BIOS-RAID detection problems (changes between f10
> and f11).
> We don't have generic workaround or patch. Can you please attach traceback
> dump? It may help us to see what the cause in your case can be.
> 
> Now I can only suggest to try to upgrade using F11 installation disk (without
> using kickstart). Other possibility is to upgrade using yum, though I am not
> sure how well it works for f11 - you can see
> http://fedoraproject.org/wiki/YumUpgradeFaq.  

Did you read my comment in 511929?

Upgrading via the DVD is also broken, though that method fails to announce the reason why.  When after selecting Upgrade, all that's permitted is a full install.  I can only assume the root detection failure occurs silently.

I've been trying to figure out how to capture the traceback when my local disks haven't been mounted, but I have so far been unsuccessful.  My Google searches have yielded nothing like a FAQ or HowTo for this.  Interestingly, on F10, anaconda has no man page or info page or Help entry.  All I've found is http://fedoraproject.org/wiki/Anaconda, which doesn't even mention tracebacks.  

I have nothing like the time, patience or talent needed to reverse-engineer this process.  If "someone" would update the wiki with a "Traceback HowTo" section, I'll give it a try.  The documentation for this process doesn't belong in Bugzilla or in an email.  Update the wiki, get the content reviewed by other anaconda experts, then I'll help test the documented process.  Basically, progress here appears to be stymied by an anaconda documentation bug.

The documented process for a yum upgrade seems to be quite a mess, and I'd rather avoid it.
Comment 62 Paul Kennedy 2009-07-20 22:17:53 EDT
Created attachment 354423 [details]
Attached traceback automatically from anaconda.
Comment 63 Radek Vykydal 2009-07-21 06:02:03 EDT
(In reply to comment #61)
 
> Did you read my comment in 511929?
> 

Yes I did. We have fixed a bug concerning detection of LVM and RAID devices when using kickstart in rawhide, but it doesn't seem to be your case as your upgrade fails to find root partitions without using kickstart.

> I've been trying to figure out how to capture the traceback when my local disks
> haven't been mounted, but I have so far been unsuccessful.  My Google searches
> have yielded nothing like a FAQ or HowTo for this.  Interestingly, on F10,
> anaconda has no man page or info page or Help entry.  All I've found is
> http://fedoraproject.org/wiki/Anaconda, which doesn't even mention tracebacks.  
> 
> I have nothing like the time, patience or talent needed to reverse-engineer
> this process.  If "someone" would update the wiki with a "Traceback HowTo"
> section, I'll give it a try.  The documentation for this process doesn't belong
> in Bugzilla or in an email.  Update the wiki, get the content reviewed by other
> anaconda experts, then I'll help test the documented process.  Basically,
> progress here appears to be stymied by an anaconda documentation bug.
> 

Sorry, I didn't realize that you were not seeing a traceback (exception), but just an error message, when I was asking for it. In such cases when you see error message or buggy behaviour, you can obtain log information by going to shell in virtual terminal 2 - Ctrl-Alt-F2, sending USR2 signal to anaconda:

# killall -USR2 anaconda

and copying generated dump file /tmp/anacdump.txt via scp or to removable device.

We need to update http://fedoraproject.org/wiki/Anaconda/BugReporting with this information.
Comment 64 Thomas Hallgren 2009-07-21 06:21:30 EDT
I have the exact same problem as described in Bug 511929.
Comment 65 Bob Cunningham 2009-07-21 12:25:02 EDT
(In reply to comment #63)
> (In reply to comment #61)
> 
> > Did you read my comment in 511929?
> > 
> 
> Yes I did. We have fixed a bug concerning detection of LVM and RAID devices
> when using kickstart in rawhide, but it doesn't seem to be your case as your
> upgrade fails to find root partitions without using kickstart.
> 
> > I've been trying to figure out how to capture the traceback when my local disks
> > haven't been mounted, but I have so far been unsuccessful.  My Google searches
> > have yielded nothing like a FAQ or HowTo for this.  Interestingly, on F10,
> > anaconda has no man page or info page or Help entry.  All I've found is
> > http://fedoraproject.org/wiki/Anaconda, which doesn't even mention tracebacks.  
> > 
> > I have nothing like the time, patience or talent needed to reverse-engineer
> > this process.  If "someone" would update the wiki with a "Traceback HowTo"
> > section, I'll give it a try.  The documentation for this process doesn't belong
> > in Bugzilla or in an email.  Update the wiki, get the content reviewed by other
> > anaconda experts, then I'll help test the documented process.  Basically,
> > progress here appears to be stymied by an anaconda documentation bug.
> > 
> 
> Sorry, I didn't realize that you were not seeing a traceback (exception), but
> just an error message, when I was asking for it. In such cases when you see
> error message or buggy behaviour, you can obtain log information by going to
> shell in virtual terminal 2 - Ctrl-Alt-F2, sending USR2 signal to anaconda:
> 
> # killall -USR2 anaconda
> 
> and copying generated dump file /tmp/anacdump.txt via scp or to removable
> device.

A the point in the boot process when the bug hits, I have NO FILESYSTEMS MOUNTED, so there is nowhere to save the traceback.  If I plug in a USB flash drive, it doesn't get recognized, and I have no idea how to mount it by hand.

> We need to update http://fedoraproject.org/wiki/Anaconda/BugReporting with this
> information.

It would be helpful if anaconda were improved to make it possible for someone with no Linux debug skills to get tracebacks to the right place, even when anaconda chokes at the very start.  I'd recommend a traceback cache online (assuming the network is found), where anaconda would automatically save each traceback with a unique ID that could then be referenced in a bug report.

Not only has reporting this bug been a royal PITA (you still have no traceback from me), but the anaconda repair process appears to have been derailed for most of this year (no fix since this issue was first reported long ago in Rawhide).

Right now, it feels like I'm being punished for trying to upgrade Fedora.

All I want is a kluge that will get me past this bug ASAP, and working with F11.  I can wait until F12 for a "real" anaconda fix to be found and committed.

Can we do an end-run around this bug?  Can the code that DOES correctly find my root on LVM be called before anaconda runs?  After all, it is obvious this code exists, since it works perfectly during every boot of F10.

Let's focus ALL current efforts on finding a workaround, so those of us affected by this bug can move on, and not remain trapped in F10.
Comment 66 Ask Bjørn Hansen 2009-07-21 17:55:01 EDT
Bob,

You can go to the shell (virtual terminal 2) and manually mount some of the partitions or a USB stick or whatever.

Alternatively then anaconda does have a "Save directly to bugzilla" option.  That's most likely how the dozens of tracebacks attached to this ticket were saved.
Comment 67 Bob Cunningham 2009-07-21 18:26:56 EDT
(In reply to comment #66)
> You can go to the shell (virtual terminal 2) and manually mount some of the
> partitions or a USB stick or whatever.

I haven't been able to get this to work for me.

> Alternatively then anaconda does have a "Save directly to bugzilla" option. 
> That's most likely how the dozens of tracebacks attached to this ticket were
> saved.  

How? Is this documented anywhere?
Comment 68 Bob Cunningham 2009-07-21 18:52:10 EDT
Created attachment 354603 [details]
Attached traceback automatically from anaconda.
Comment 69 Bob Cunningham 2009-07-21 19:04:45 EDT
(In reply to comment #68)
> Created an attachment (id=354603) [details]
> Attached traceback automatically from anaconda.  

OK!  This is from an F10 preupgrade reboot.

Here's /boot/upgrade/ks.cfg:

    # ks.cfg generated by preupgrade
    lang en_US.UTF-8
    keyboard us
    bootloader --upgrade --location=none
    upgrade --root-device=UUID=91229076-8038-4fd9-ac70-a897a38193cc
    reboot
    
    %post
    grubby --remove-kernel=/boot/upgrade/vmlinuz
    rm -rf /boot/upgrade /var/cache/yum/preupgrade*
    %end

Here's /etc/fstab:

    #
    # /etc/fstab
    # Created by anaconda on Mon Dec  1 04:02:35 2008
    #
    # Accessible filesystems, by reference, are maintained under '/dev/disk'
    # See man pages fstab(5), findfs(8), mount(8) and/or vol_id(8) for more info
    #
    UUID=91229076-8038-4fd9-ac70-a897a38193cc /     ext3    defaults        1 1
    UUID=9809bfed-9a0f-49b9-a797-4252cb170045 /boot ext3    defaults        1 2
    tmpfs                   /dev/shm                tmpfs   defaults        0 0
    devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
    sysfs                   /sys                    sysfs   defaults        0 0
    proc                    /proc                   proc    defaults        0 0
    UUID=be5c0d54-e813-446f-81e2-52bfff08de89 swap  swap    defaults        0 0
    /dev/cdrom              /media/cdrom            auto    noauto,ro,user  0 0

Here are the start of /boot/grub/grub.conf:

    # grub.conf generated by anaconda
    #
    # Note that you do not have to rerun grub after making changes to this file
    # NOTICE:  You have a /boot partition.  This means that
    #          all kernel and initrd paths are relative to /boot/, eg.
    #          root (hd0,0)
    #          kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
    #          initrd /initrd-version.img
    boot=/dev/sda
    default=1
    timeout=5
    splashimage=(hd0,0)/grub/splash.xpm.gz
    hiddenmenu
    title Upgrade to Fedora 11 (Leonidas)
	kernel /upgrade/vmlinuz preupgrade repo=hd::/var/cache/yum/preupgrade stage2=hd:UUID=9809bfed-9a0f-49b9-a797-4252cb170045:/upgrade/install.img ks=hd:UUID=9809bfed-9a0f-49b9-a797-4252cb170045:/upgrade/ks.cfg
	initrd /upgrade/initrd.img

Anything else needed?
Comment 70 Bob Cunningham 2009-07-21 19:07:47 EDT
Comment on attachment 354603 [details]
Attached traceback automatically from anaconda.

Ran F10 preupgrade, then rebooted.  After the "Upgrade Root Not Found" popup appeared, I hit Back, then saved this backtrace.
Comment 71 Radek Vykydal 2009-07-22 05:14:56 EDT
Bob, thanks for the traceback.

What makes this bug a big pain is that I am not able to reproduce it.
I can distinct two groups of tracebacks in this bug.

1) dm-raid (BIOS-RAID) related issues, typical log messages are:

[2009-06-11 17:08:56,773]    DEBUG: sda is part of a dmraid
[2009-06-11 17:08:56,775]    DEBUG: getFormat('None') returning DeviceFormat instance
[2009-06-11 17:08:56,786]    DEBUG: added sda (storage device) to device tree
[2009-06-11 17:08:56,793]    DEBUG: {'ID_REVISION': '3.AA', 'ID_VENDOR_ENC': 'ATA\\x20\\x20\\x20\\x20\\x20', 'ID_ATA_COMPAT': 'ST3300622AS_3NF1LKXA', 'ID_FS_VERSION': '02.00.00', 'ID_PATH': 'pci-0000:00:1f.2-scsi-1:0:0:0', 'ID_VENDOR': 'ATA', 'ID_SERIAL': '1ATA_ST3300622AS_3NF1LKXA', 'MINOR': '0', 'DEVTYPE': 'disk', 'ID_FS_UUID': '___', 'ID_FS_UUID_ENC': '\\x20\\x20\\x20\\x20\\x27\\x3e\\xca', 'ID_FS_TYPE': 'ddf_raid_member', 'ID_MODEL': 'ST3300622AS', 'MAJOR': '8', 'sysfs_path': '/devices/pci0000:00/0000:00:1f.2/host3/target3:0:0/3:0:0:0/block/sda', 'ID_FS_USAGE': 'raid', 'ID_TYPE': 'disk', 'ID_BUS': 'scsi', 'ID_EDD': 'int13_dev80', 'symlinks': ['block/8:0', 'disk/by-id/scsi-1ATA_ST3300622AS_3NF1LKXA', 'disk/by-id/ata-ST3300622AS_3NF1LKXA', 'disk/by-path/pci-0000:00:1f.2-scsi-1:0:0:0', 'disk/by-id/edd-int13_dev80'], 'ID_SERIAL_SHORT': 'ATA_ST3300622AS_3NF1LKXA', 'name': 'sda', 'ANACBIN': '/usr/sbin', 'ID_MODEL_ENC': 'ST3300622AS\\x20\\x20\\x20\\x20\\x20'}
[2009-06-11 17:08:56,795]    DEBUG: type detected on 'sda' is 'ddf_raid_member'
[2009-06-11 17:08:56,804]    DEBUG: getFormat('ddf_raid_member') returning DMRaidMember instance
[2009-06-11 17:08:56,938]    DEBUG: ignoring sda1 (/devices/pci0000:00/0000:00:1f.2/host3/target3:0:0/3:0:0:0/block/sda/sda1)
[2009-06-11 17:08:56,944]    DEBUG: ignoring sda2 (/devices/pci0000:00/0000:00:1f.2/host3/target3:0:0/3:0:0:0/block/sda/sda2)
[2009-06-11 17:08:56,950]    DEBUG: ignoring sda3 (/devices/pci0000:00/0000:00:1f.2/host3/target3:0:0/3:0:0:0/block/sda/sda3)

It concerns tracebacks from these comments:

#53 - 2 disks, seems like BIOS RAID was not detected/used in f10 so installation is on 2 disks, but is detected/used in f11
#4 from bug #504274 - 1 disk, detected as raid member
#8 from bug #504274 - 5 disks, one detected as raid member 
#10 from bug #504274 - 1 disk, detected as raid member
#58 - 2 disks, one detected as raid member

Maybe clearing raid metadata (see
https://bugzilla.redhat.com/show_bug.cgi?id=510772#c13 part 1)) would help, but please be sure about what are you doing and beware of data loss, I haven't tried the procedure.

#62 - ignoring partitions of sdb, but perhaps not dmraid issue

2) Tracebacks from the other comments (#55 #54, #60, #49, #46, #68 and #3 #9
#12 #14 from bug #504274).
These are usually having default partitioning layouts. When checking devices for root-ones, the actual root partition is mounted (as seems from log messages), but it is not added to rootParts. I suspect that this hunk of findExistingRootDevices() in storage/__init__.py:

        if os.access(anaconda.rootPath + "/etc/fstab", os.R_OK):
            (product, version) = getReleaseString(anaconda.rootPath)
            stingRootDevicesproduct: %s version: %s" % (product, version))
            if upgradeany or \
               anaconda.id.instClass.productUpgradable(product, version):
                rootDevs.append((device, "%s %s" % (product, version)))

Either os.access fails or (which seems unlikely) the product/version check fails. If the former is true I'd like to see if the root device is really mounted at the point of os.access check (though log messages suggest that it is) or why the access fails.

If anyone of you kind reporters wants to help, I prepared updates image, which patches anaconda for more logging information and also option to debug reproducer.

It is set up by adding line
updates=http://rvykydal.fedorapeople.org/updates.upgf11w.img
to boot parameters for Upgrade to F11 choice.
You can do it by hitting 'a' in grub boot selection menu (which can be invoked with Esc).

If you add also "debug", you can go to python debugger session in virtual terminal 1 (Ctrl-Alt-F1).
Comment 72 Bob Cunningham 2009-07-22 11:47:42 EDT
Created attachment 354723 [details]
Attached traceback automatically from anaconda.
Comment 73 Radek Vykydal 2009-07-22 12:46:00 EDT
(In reply to comment #72)

Bob, thank you for reproducing.

Now I think I know where is the problem: anaconda doesn't see your F10 installation as upgradable as /etc/redhat-release file doesn't contain string "Fedora release 10 (Cambridge)" or similar which would qualify as upgradable, but something like MythDora 10.21. You should be able to workaround it either by adding boot option "upgradeany" (in a same way as you added "updates=...) or by changing the /etc/redhat-release file.
Comment 74 Radek Vykydal 2009-07-22 13:01:36 EDT
(In reply to comment #73)
. You should be able to workaround it either
> by adding boot option "upgradeany" (in a same way as you added "updates=...) or
> by changing the /etc/redhat-release file.  

Is seems you will have to use /etc/redhat-release modification as a bug about anyupgrade option not working was just reported (bug #513227)
Comment 75 Bob Cunningham 2009-07-22 13:36:34 EDT
Created attachment 354752 [details]
Attached traceback automatically from anaconda.
Comment 76 Bob Cunningham 2009-07-22 19:11:16 EDT
Comment on attachment 354752 [details]
Attached traceback automatically from anaconda.

preupgrade with above "updates" and "upgradeany" boot options added.
Comment 77 Bob Cunningham 2009-07-23 02:13:16 EDT
(In reply to comment #73)
> (In reply to comment #72)
> 
> Bob, thank you for reproducing.
> 
> Now I think I know where is the problem: anaconda doesn't see your F10
> installation as upgradable as /etc/redhat-release file doesn't contain string
> "Fedora release 10 (Cambridge)" or similar which would qualify as upgradable,
> but something like MythDora 10.21. You should be able to workaround it either
> by adding boot option "upgradeany" (in a same way as you added "updates=...) or
> by changing the /etc/redhat-release file.  

THANKS! Preupgrade from F10 to F11 succeeded after I edited the above file.

1. The "first order" bug in this case was actually due to preupgrade failing to check for simple items that could cause anaconda to fail.  At least one of these items is the content of the /etc/redhat-release file.  Should a bug against preupgrade be opened for this?  How many other things does preupgrade miss?

2. Anaconda error handling/reporting truly sucks, at least for this error.  Fundamental (yet simple) errors are either not reported to the user (such as during a DVD upgrade), or are misreported ("Upgrade Root Not Found").  It boggles the mind that a hacked version of anaconda was required to obtain a traceback with enough detail to detect that a one-line text file was in error!  How many separate bugs should be opened to handle such items?  Or is this how anaconda is intended to perform?

3. This bug is way too generic: How many individual anaconda problems caused by preupgrade or a DVD upgrade are lumped into this single bug?  I recommend splitting at least this issue into a separate bug, then move all associated comments to that new bug.  I believe it CERTAINLY was a mistake to close bug 511929 before any investigation was performed!  I'd recommend closer supervision of the person who did that.


I will drop a note to the MythDora folks about this.  I had used the MythDora system configurator to quickly get MythTV installed and running on my F10 system.  I had no idea it had made my F10 system "not-Fedora"!


Thanks again for nailing the workaround for this specific issue!
Comment 78 Thomas Hallgren 2009-07-23 03:16:39 EDT
Bob's problem is apparently not the same as mine. I have the exact text "Fedora release 10 (Cambridge)" in my /etc/redhat-release file and I still get the "Upgrade Root Not Found" error.

I look forward to an improved preupgrade and better error handling in Anaconda.
Comment 79 Bob Cunningham 2009-07-23 03:38:54 EDT
(In reply to comment #78)
> Bob's problem is apparently not the same as mine. I have the exact text "Fedora
> release 10 (Cambridge)" in my /etc/redhat-release file and I still get the
> "Upgrade Root Not Found" error.
> 
> I look forward to an improved preupgrade and better error handling in Anaconda.  

Did you do what I did?

Repeat your upgrade after adding the above "updates=" boot option to /boot/grub/grub.conf, then capture the traceback and post it to this bug.

Otherwise, the anaconda developers can't help you!
Comment 80 Thomas Hallgren 2009-07-23 03:47:19 EDT
No, I'm sorry. I'm not that fluent with the boot process. I have no idea how to obtain a traceback etc. I would certainly try, given an elaborate step by step instruction.
Comment 81 Radek Vykydal 2009-07-23 10:51:10 EDT
Thomas, when you boot F10 (after doing preupgrade), hit Esc to get to grub menu, in the menu go to Upgrade choice, hit 'a' and append updates=http://rvykydal.fedorapeople.org/updates.upgf11w.img to the line. Then hit Enter to boot. When you will see the "Upgrade root not found" error message, click Back which will result in traceback with exception dialog that will offer to save traceback to bugzilla.
Comment 82 Greg Morgan 2009-07-24 00:38:13 EDT
Created attachment 354967 [details]
Attached traceback automatically from anaconda.
Comment 83 Greg Morgan 2009-07-24 01:21:58 EDT
Comment #82 is for a dual booted laptop.  The other os is Win XP.  I tried the updates line found in comment #81.  I received another traceback. I did not save this one thinking that it was the same as Comment #82.  In all cases, I saw a small "Finding storage devices" dialog.  Then I saw the "Upgrade root not found" dialog.  The last sentence said, "You can exit installation or back track to choose installation instead of upgrade."  The moment I push the "Back" button, then the error report is generated.

HTH.  Please let me know if I can provide any other information.
Comment 84 Greg Morgan 2009-07-24 01:35:38 EDT
Fedora 9 has this in /etc/redhat-release 
redhat-4

Attempting upgradeany any as per comment #73 for comment #82 system.
Comment 85 Greg Morgan 2009-07-24 01:40:06 EDT
Created attachment 354977 [details]
Attached traceback automatically from anaconda.
Comment 86 Thomas Hallgren 2009-07-24 02:30:45 EDT
Created attachment 354978 [details]
Attached traceback automatically from anaconda.
Comment 87 Thomas Hallgren 2009-07-24 02:38:53 EDT
My traceback following the instructions in comment #81.
Comment 88 Radek Vykydal 2009-07-24 04:57:28 EDT
(In reply to comment #85)
> Created an attachment (id=354977) [details]
> Attached traceback automatically from anaconda.  

Greg, upgradeany boot option is broken in F11, your can work around it by changing content of /etc/redhat-release to
"Fedora release 9 (Sulphur)"
or
"Fedora release 10 (Cambridge)".
Comment 89 Radek Vykydal 2009-07-24 07:12:29 EDT
(In reply to comment #87)
> My traceback following the instructions in comment #81.  

Thomas, anaconda can't access your /etc/fstab (/mnt/sysimage/etc/fstab in anaconda environment). Could you please get me one more traceback, I updated the updates image to have yet more information in log files.

If you want to poke around the anaconda environment in the moment just before the failing access, add also "debug" to boot parameters (in addition to "updates=..."), boot, go to python debugger in virtual terminal 1 (Ctrl-Alt-F1), enter 'c' two times, an then you can go to shell (Ctrl-Alt-F2) to examine why the /mnt/sysimage/etc/fstab is not accessible. To continue the upgrade enter 'c' in debugger (Ctrl-Alt-F1) one or few more times.
Comment 90 Thomas Hallgren 2009-07-24 08:23:43 EDT
Created attachment 355009 [details]
Attached traceback automatically from anaconda.
Comment 91 Greg Morgan 2009-07-24 09:24:04 EDT
Radek, Thank you for your support on this bug.  Comment #82, Comment #83, Comment #84 and Comment #85 may or may not be helpful to you.  I had install Oracle 10g forms on Fedora 9.  I forgot that I changed /etc/redhat-release to redhat-4 as "a work around" to only installing Oracle products on Enterprise versions of Red Hat Linunx. (Yes Uncle Larry Elisson, I know that I'd be unsupported, if there's a problem. Thanks for reminding me.  By the way, please don't screw up mysql or Java now that you own Sun. Sun already screwed up Solaris.)

I successfully upgraded to 11 from 9. I did two things.  One, I forgot that I had not performed a "yum upgrade" before the preupgrade of the system.  I don't know if that matters.  Two, I had already changed the /etc/redhat-release to "Fedora release 10 (Cambridge)" and went to bed while waiting for the install to finish, when you posted your instructions in Comment #88.  The update line from comment #71 and earlier was still in place.

The results: Booting into the "Other OS" (MS Windows XP) worked OK. I had to clean out all Fedora 9 entries in /etc/grub.conf.  However, I doubt that the programs involved could have done this for fear of wiping out other installed systems.
Comment 92 Radek Vykydal 2009-07-24 09:58:02 EDT
(In reply to comment #90)
> Created an attachment (id=355009) [details]
> Attached traceback automatically from anaconda.  

I am running out of ideas. It seems like your logical volume with root (LogVol00 in volume group VolGroup01) is empty - neither /etc/fstab, nor /etc/redhat-release is found despite the logical volume being active and mounted. Desperate question: is there any chance it is actually empty? Is your installation you want to upgrade still ok?
Comment 93 Greg Morgan 2009-07-24 13:31:05 EDT
One more follow-up to comment #91. I saw fc9 packages with the install of quantum gis via
yum install 'qgis*'
That too may have been a brain fart on my part because the packages were already installed.

I think the yum clean all was the more important fix.
yum erase 'qgis*'
yum clean all
yum install 'qgis*'

Would cleaning up the installation step be helpful some where after a successful install?  Perhaps a forced step in firstboot?  Although many folks clobber firstboot.

HTH
Greg
Comment 94 Thomas Hallgren 2009-07-24 16:42:18 EDT
Created attachment 355097 [details]
My /etc/fstab

The machine I want to upgrade is OK as far as I can see. I'm using it for my daily work, it reboots without problems, and it has all the latest updates installed.
Comment 95 Thomas Hallgren 2009-07-25 02:37:32 EDT
I tried using 'debug'. Anaconda mounts /dev/VolGroup01/LogVol00 on /mnt/sysimage incorrectly assuming that that's my root. My root is on /dev/VolGroup00/LogVol00.
Comment 96 Thomas Hallgren 2009-07-25 02:45:49 EDT
Not sure if this is relevant but looking at my /boot/grub/grub.conf I find this:

# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
#          initrd /initrd-version.img

and all kernel entries except the "Upgrade to Fedora 11" one has a "root=/dev/VolGroup00/LogVol00" parameter.
Comment 97 Nitin Thakur 2009-07-26 05:54:32 EDT
In my case it was simple matter of correcting the /etc/redhat-release which I had modified to be able to install Veritas Cluster server software. After that the upgrade went fine.
Comment 98 Radek Vykydal 2009-07-27 04:32:54 EDT
(In reply to comment #95)
> I tried using 'debug'. Anaconda mounts /dev/VolGroup01/LogVol00 on
> /mnt/sysimage incorrectly assuming that that's my root. My root is on
> /dev/VolGroup00/LogVol00.  

It is correct that anaconda tries to mount all LVs it sees as root, so it tries LogVol00 and sees is not root (I was mis-assuming that it is root in fact) The problem is that it is not seeing your VolGroup00 volume group (containing root and swap logical volumes) at all. Can you post outputs of

parted -l
cat /proc/partitions

commands in your existing system?

It can support my hypothese that your VolGroup00 is not seen due to BIOS RAID working in F11 and not working in F10. If so, turning the RAID off in BIOS (as I proposed in comment #71 1)) could help.
Comment 99 Thomas Hallgren 2009-07-27 05:01:25 EDT
[root@tada ~]# parted -l
Model: ATA WDC WD5000KS-00M (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End    Size   Type     File system  Flags
 1      32.3kB  206MB  206MB  primary  ext3         boot 
 2      206MB   500GB  500GB  primary                    


Model: ATA WDC WD5000KS-00M (scsi)
Disk /dev/sdb: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End    Size   Type     File system  Flags
 1      32.3kB  206MB  206MB  primary  ext3         boot 
 2      206MB   500GB  500GB  primary               lvm  


Model: Linux device-mapper (dm)
Disk /dev/mapper/VolGroup01-LogVol00: 495GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End    Size   File system  Flags
 1      0.00B  495GB  495GB  ext3              


Model: Linux device-mapper (dm)
Disk /dev/mapper/VolGroup01-LogVol01: 5268MB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  5268MB  5268MB  linux-swap        


Model: Linux device-mapper (dm)
Disk /dev/mapper/VolGroup00-LogVol01: 5268MB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  5268MB  5268MB  linux-swap        


Model: Linux device-mapper (dm)
Disk /dev/mapper/VolGroup00-LogVol00: 495GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End    Size   File system  Flags
 1      0.00B  495GB  495GB  ext3              


Warning: Unable to open /dev/fd0 read-write (Read-only file system).  /dev/fd0 has been opened read-only.
Error: /dev/fd0: unrecognised disk label                                  

[root@tada ~]# cat /proc/partitions
major minor  #blocks  name

   8     0  488386584 sda
   8     1     200781 sda1
   8     2  488183220 sda2
   8    16  488386584 sdb
   8    17     200781 sdb1
   8    18  488183220 sdb2
 253     0  483000320 dm-0
 253     1    5144576 dm-1
 253     2    5144576 dm-2
 253     3  483000320 dm-3
Comment 100 Ask Bjørn Hansen 2009-07-27 05:09:58 EDT
My traceback is #54. My system doesn't use "bios-RAID" (it has a 3ware card for raid).

parted -l and /proc/partitions output below (/dev/sdb is a big-ish LVM volume with the data file systems (mythtv, backups etc); /, /usr etc are on the /dev/sda2 lvm).

[root@zaphod ~]# parted -l

Model: AMCC 9650SE-12M DISK (scsi)
Disk /dev/sda: 26.8GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      32.3kB  115MB   115MB   primary  ext3              
 2      115MB   26.8GB  26.7GB  primary                    


Error: /dev/sdb: unrecognised disk label                                  

Model: Linux device-mapper (dm)
Disk /dev/mapper/vg1-backup: 1348GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  1348GB  1348GB  ext3              


Model: Linux device-mapper (dm)
Disk /dev/mapper/vg1-movies: 1556GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  1556GB  1556GB  ext3              


Model: Linux device-mapper (dm)
Disk /dev/mapper/vg1-squid: 34.4GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  34.4GB  34.4GB  ext3              


Model: Linux device-mapper (dm)
Disk /dev/mapper/vg1-mirrors: 1292MB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  1292MB  1292MB  ext3              


Model: Linux device-mapper (dm)
Disk /dev/mapper/vg1-swap: 3221MB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  3221MB  3221MB  linux-swap        


Model: Linux device-mapper (dm)
Disk /dev/mapper/vg1-home: 451GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End    Size   File system  Flags
 1      0.00B  451GB  451GB  ext3              


Model: Linux device-mapper (dm)
Disk /dev/mapper/vg0-lvvar: 4933MB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  4933MB  4933MB  ext3              


Model: Linux device-mapper (dm)
Disk /dev/mapper/vg0-lvusr: 4865MB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  4865MB  4865MB  ext3              


Model: Linux device-mapper (dm)
Disk /dev/mapper/vg0-lvroot: 1644MB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  1644MB  1644MB  ext3              


Warning: Unable to open /dev/fd0 read-write (Read-only file system).  /dev/fd0 has been
opened read-only.
Error: /dev/fd0: unrecognised disk label 

[root@zaphod ~]# cat /proc/partitions 
major minor  #blocks  name

   8     0   26214399 sda
   8     1     112423 sda1
   8     2   26097592 sda2
   8    16 3391681536 sdb
 253     0    1605632 dm-0
 253     1    4751360 dm-1
 253     2    4816896 dm-2
 253     3  440401920 dm-3
 253     4    3145728 dm-4
 253     5    1261568 dm-5
 253     6   33554432 dm-6
 253     7 1519386624 dm-7
 253     8 1315962880 dm-8
Comment 101 Radek Vykydal 2009-07-27 06:03:21 EDT
(In reply to comment #99)

Thomas, it really seems like BIOS RAID issue I was talking about in comment #98.

(In reply to comment #100)

Bjorn, did you check your /etc/redhat-release file? (see comments #71 2), #73, #74) If it is not your case, could you try to generate traceback with updates file? (See comments #81 and #89 - second paragraph).
Comment 102 Thomas Hallgren 2009-07-27 06:36:18 EDT
(In reply to comment #101)
> Thomas, it really seems like BIOS RAID issue I was talking about in comment
> #98.

I double checked. All RAID settings are disabled in my BIOS. So that is not the cause.
Comment 103 Radek Vykydal 2009-07-27 09:35:23 EDT
(In reply to comment #102)
> (In reply to comment #101)
> > Thomas, it really seems like BIOS RAID issue I was talking about in comment
> > #98.
> 
> I double checked. All RAID settings are disabled in my BIOS. So that is not the
> cause.  

I think there must be some bios-raid metadata left on the disks (from previous uses) because anaconda/dmraid sees the disks as dmraid disks. To get over it, you can try to pass nodmraid option in boot command line, though I doubt it will work.
If it doesn't, another possible soulution is to remove the metadata in f11 rescue mode (or in shell when installing or doing preupgrade - Ctrl-Alt-F2) with

dmraid -E -r /dev/sda
dmraid -E -r /dev/sdb

but here beware, you are writing to your disks, so I am not sure if there is not any risk of losing your data as I am not an dmraid expert. It worked for me in this scenario:

With BIOS RAID on, I installed F10 which didn't recognize it so I installed on the 2 member disks as normal disks. Then I tried to upgrade to F11 - anaconda was seeing raid array, and therefore not the complete installation on 2 disks. Still in installation process, I went to shell (Ctrl-Alt-F2), executed the 2 dmraid commands above, rebooted and tried to install F11 again. Now the root partition of F10 installation was found and I was offered upgrade which went successfully.

I'd also suggest to ask Hans de Goede from anaconda team who is available on 
#anaconda FreeNode IRC channel as hansg and knows more about dmraid.
Comment 104 Peter R. Thorsen Jr. 2009-07-29 13:52:54 EDT
Created attachment 355590 [details]
Attached traceback automatically from anaconda.
Comment 105 Peter R. Thorsen Jr. 2009-07-29 14:30:15 EDT
(In reply to comment #104)
> Created an attachment (id=355590) [details]
> Attached traceback automatically from anaconda.  

The Server is a Dell Power Edge 2850 with a PERC4E/DC Raid Controller

Initially we tried install Fedora Core 11 and the installer kernel crashes immediately as it is "waiting for devices to initialize".  So we fell back and installed Fedora Core 10 and this worked with no problems.  Then we tried to upgrade to Fedora Core 11 from the previously installed Fedora Core 10 installation and this failed also at the same point as the initial Fedora Core 11 install.  The first thing we got after the kernel crash was that there were no storage devices found.  It looks to us that both crashes are related to being unable to access this particular Raid controller.
Comment 106 Svilen Krustev 2009-08-09 08:12:20 EDT
Created attachment 356804 [details]
Attached traceback automatically from anaconda.
Comment 107 Aran Cox 2009-08-10 11:35:00 EDT
Using dmraid -r I was able to determine that I had some fakeraid metadata for a sil device on /dev/sdb.  I then used:

dmraid -E -r /dev/sdb

to remove it and now my preupgrade is proceeding!  I previously tried a network upgrade, DVD upgrade, and preupgrade and couldn't get anaconda to find my root device.

Thank you, Radek Vykydal!
Comment 108 Jim Gribbin 2009-08-16 15:42:31 EDT
Created attachment 357585 [details]
Attached traceback automatically from anaconda.
Comment 109 Oliver Ruebenacker 2009-08-20 09:03:48 EDT
Created attachment 358083 [details]
Attached traceback automatically from anaconda.
Comment 110 Jim Constantine 2009-09-05 02:47:27 EDT
Created attachment 359860 [details]
Attached traceback automatically from anaconda.
Comment 111 Oliver Ruebenacker 2009-09-17 08:52:25 EDT
Created attachment 361492 [details]
Attached traceback automatically from anaconda.
Comment 112 Matthew 2009-09-28 22:00:35 EDT
Created attachment 362953 [details]
Attached traceback automatically from anaconda.
Comment 113 Jim Gribbin 2009-09-28 23:26:51 EDT
(In reply to comment #108)
> Created an attachment (id=357585) [details]
> Attached traceback automatically from anaconda.  

Something I should have posted earlier.

This is a desktop system not running raid. dmraid does not show any raid configurations ether, so I guess nothing was set up in that regard that I was unaware of.

In some of the the suggestion posted above it was recommended pointing the upgrade to other images. I believe I have tried all the images suggested and they at least get me past the error message and it finds the image, the problem there is that all the images referenced that do work, one wasn't found, seem to want to do a FULL install beginning with partitioning and formatting the disk. Not particularly useful when I only want to do an upgrade.

Jim G
Comment 114 Oliver Ruebenacker 2009-10-08 09:56:14 EDT
Created attachment 364117 [details]
Attached traceback automatically from anaconda.
Comment 115 Jim Gribbin 2009-10-09 01:31:43 EDT
Somewhere along the way, probably due to an upgrade of Anaconda, my problem seems to have been fixed. I believe the last time I made a significant attempt was about the time I posted #108, or about 2 months ago.

My desktop seems to be running f11 now and my laptop seems to be upgrading as I type without complaint.
Comment 116 Oliver Ruebenacker 2009-10-15 10:22:25 EDT
Created attachment 364918 [details]
Attached traceback automatically from anaconda.
Comment 117 Oliver Ruebenacker 2009-10-22 11:40:50 EDT
Created attachment 365746 [details]
Attached traceback automatically from anaconda.
Comment 118 systemssoftware 2009-10-28 21:07:11 EDT
Created attachment 366525 [details]
Attached traceback automatically from anaconda.
Comment 119 Oliver Ruebenacker 2009-10-29 12:51:52 EDT
Created attachment 366663 [details]
Attached traceback automatically from anaconda.
Comment 120 Oliver Ruebenacker 2009-11-05 15:42:17 EST
Created attachment 367701 [details]
Attached traceback automatically from anaconda.
Comment 121 alauschke 2009-11-06 15:56:04 EST
What I can glean from this is the typical problem in software development: poor documentation and "un"helpful error messages -- this has been mentioned before by other posters. Is there anything I can check beforehand to see if this bug will affect me? I am on the email list for this bug for a reason. Most of what I read above is "necessary conditions" (aka: "you need this ... for it to work"). Are there "sufficient conditions" (aka: "if this ... works, then you won't be affected")?

I have a F10 server version on a dual 64 bit AMD Opteron server, and I can't wait until I can install F11. F12 is coming out soon, and I still run F10. And yes, my two drives are in a virtual RAID, and I want to keep it that way. What check can I perform to determine if 499321 will still affect me? I am NOT a Linux expert, I'd rate myself as "average", not more.

Thanks.
Comment 122 Chris Lumens 2009-11-09 08:22:03 EST
*** Bug 533748 has been marked as a duplicate of this bug. ***
Comment 123 Robert Weir 2009-11-12 14:30:03 EST
Created attachment 369301 [details]
Attached traceback automatically from anaconda.
Comment 124 Bug Zapper 2009-11-16 04:58:08 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 125 Chris Lumens 2009-11-23 09:22:34 EST
*** Bug 540085 has been marked as a duplicate of this bug. ***
Comment 126 Chris Lumens 2009-11-25 15:18:58 EST
This is a tricky bug, but I have fixed it once again.  The bug reported in 540085 that I duped to this one turned out to not quite be a dup, but it'll be fixed in the next build of anaconda.  The original many reports on this bug *should not* be happening any more either.

If you are continuing to see a problem along these lines, please do open a new bug report as this one's getting confused and unwieldy.  Thanks.
Comment 127 bob mckay 2009-12-08 23:40:53 EST
For information only - if you are seeing messages about not finding root on preupgrade on a system using lvm on ATA disks (maybe other conditions are also required to trigger this), you might want to check out Bug 54417. Actually, it's not an anaconda bug, seems to be a problem with lvm activation over (some kinds of?) ATA disks, but there is a fix there that might help to get you to F12, where the problem seems to be reduced.
Comment 128 Alex 2010-03-01 05:14:43 EST
For information only, this bug is also present with preupgrade/anaconda F11 + all latest patches. For some reason (in earlier attempts running out of /etc space?) I guess preupgrade wrote /etc/redhat-release with the F12 string but anaconda was still expecting the F11 string. Editing /etc/redhat-release with the correct string fixed the problem.
Comment 129 Peter 2011-03-16 08:13:08 EDT
Created attachment 485716 [details]
Attached traceback automatically from anaconda.
Comment 130 Peter 2011-03-16 08:17:01 EDT
Created attachment 485717 [details]
Attached traceback automatically from anaconda.

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