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'
Created attachment 342596 [details] Attached traceback automatically from anaconda.
Created attachment 342621 [details] Attached traceback automatically from anaconda.
*** Bug 499407 has been marked as a duplicate of this bug. ***
This should be fixed in the next build of anaconda. Thanks for the bug report.
Created attachment 342992 [details] Attached traceback automatically from anaconda.
Created attachment 343058 [details] Attached traceback automatically from anaconda.
sadly, this seemed to be the latest version of anaconda.
Created attachment 343069 [details] Attached traceback automatically from anaconda.
Created attachment 343195 [details] Attached traceback automatically from anaconda.
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?
Created attachment 343201 [details] Attached traceback automatically from anaconda.
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().
Created attachment 343259 [details] Attached traceback automatically from anaconda.
Created attachment 343305 [details] Attached traceback automatically from anaconda.
Created attachment 343444 [details] Attached traceback automatically from anaconda.
Adding to F11Blocker, as this prevents preupgrade from working at all.
*** Bug 499966 has been marked as a duplicate of this bug. ***
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.
Fix confirmed using updates=http://clumens.fedorapeople.org/499321.img
likewise, I confirm the fix using updates=http://clumens.fedorapeople.org/499321.img
*** Bug 500533 has been marked as a duplicate of this bug. ***
Also fixed by using updates=http://clumens.fedorapeople.org/499321.img
Created attachment 344069 [details] Attached traceback automatically from anaconda.
Leaving this open until this is fixed in rawhide. -52 still doesn't preupgrade for me in kvm anyway.
I see 499321.img working with -52 too at least.
Created attachment 344085 [details] Attached traceback automatically from anaconda.
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.
Created attachment 344145 [details] Attached traceback automatically from anaconda.
Okay, pushed another fix for this issue. Next build of anaconda, etc.
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.
Created attachment 344262 [details] Attached traceback automatically from anaconda.
Created attachment 344340 [details] Attached traceback automatically from anaconda.
Created attachment 344404 [details] Attached traceback automatically from anaconda.
Created attachment 344415 [details] Attached traceback automatically from anaconda.
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)
*** Bug 501282 has been marked as a duplicate of this bug. ***
I confirm that adding updates=http://clumens.fedorapeople.org/499321.img to the grub.conf line fixes it. Thanks.
This appears to be fixed with anaconda-11.5.0.53, which is in today's Rawhide.
Yep also confirmed working with build 54.
Created attachment 345693 [details] Attached traceback automatically from anaconda.
Created attachment 346574 [details] Attached traceback automatically from anaconda.
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?
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.
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
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.
Created attachment 349191 [details] Attached traceback automatically from anaconda.
Created attachment 349199 [details] Attached traceback automatically from anaconda.
Created attachment 350107 [details] Attached traceback automatically from anaconda.
Created attachment 350139 [details] Attached traceback automatically from anaconda.
Created attachment 350432 [details] Attached traceback automatically from anaconda.
Created attachment 350709 [details] Attached traceback automatically from anaconda.
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.
Created attachment 350726 [details] Attached traceback automatically from anaconda.
Created attachment 351227 [details] Attached traceback automatically from anaconda.
Created attachment 351524 [details] Attached traceback automatically from anaconda.
*** Bug 511929 has been marked as a duplicate of this bug. ***
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?
Created attachment 353904 [details] Attached traceback automatically from anaconda.
(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.
Created attachment 354382 [details] Attached traceback automatically from anaconda.
(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.
Created attachment 354423 [details] Attached traceback automatically from anaconda.
(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.
I have the exact same problem as described in Bug 511929.
(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.
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.
(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?
Created attachment 354603 [details] Attached traceback automatically from anaconda.
(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 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.
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).
Created attachment 354723 [details] Attached traceback automatically from anaconda.
(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.
(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)
Created attachment 354752 [details] Attached traceback automatically from anaconda.
Comment on attachment 354752 [details] Attached traceback automatically from anaconda. preupgrade with above "updates" and "upgradeany" boot options added.
(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!
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.
(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!
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.
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.
Created attachment 354967 [details] Attached traceback automatically from anaconda.
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.
Fedora 9 has this in /etc/redhat-release redhat-4 Attempting upgradeany any as per comment #73 for comment #82 system.
Created attachment 354977 [details] Attached traceback automatically from anaconda.
Created attachment 354978 [details] Attached traceback automatically from anaconda.
My traceback following the instructions in comment #81.
(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)".
(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.
Created attachment 355009 [details] Attached traceback automatically from anaconda.
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.
(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?
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
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.
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.
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.
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.
(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.
[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
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
(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).
(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.
(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.
Created attachment 355590 [details] Attached traceback automatically from anaconda.
(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.
Created attachment 356804 [details] Attached traceback automatically from anaconda.
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!
Created attachment 357585 [details] Attached traceback automatically from anaconda.
Created attachment 358083 [details] Attached traceback automatically from anaconda.
Created attachment 359860 [details] Attached traceback automatically from anaconda.
Created attachment 361492 [details] Attached traceback automatically from anaconda.
Created attachment 362953 [details] Attached traceback automatically from anaconda.
(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
Created attachment 364117 [details] Attached traceback automatically from anaconda.
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.
Created attachment 364918 [details] Attached traceback automatically from anaconda.
Created attachment 365746 [details] Attached traceback automatically from anaconda.
Created attachment 366525 [details] Attached traceback automatically from anaconda.
Created attachment 366663 [details] Attached traceback automatically from anaconda.
Created attachment 367701 [details] Attached traceback automatically from anaconda.
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.
*** Bug 533748 has been marked as a duplicate of this bug. ***
Created attachment 369301 [details] Attached traceback automatically from anaconda.
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
*** Bug 540085 has been marked as a duplicate of this bug. ***
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.
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.
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.
Created attachment 485716 [details] Attached traceback automatically from anaconda.
Created attachment 485717 [details] Attached traceback automatically from anaconda.