Created attachment 337421 [details] Anaconda logs for the "path" issue with or without the "updates" option Description of problem: After selecting "Create custom layout" and clicking "Next" anaconda throws a Python exception. Version-Release number of selected component (if applicable): anaconda 11.5.0.38 Both x86 and x86_64 versions have this problem, I used boot.iso from http://download.fedora.redhat.com/pub/fedora/linux/development/ (dated 31st March 2009) How reproducible: Always Steps to Reproduce: 1.Insert a flash drive containing an anaconda update image,for example http://jgranado.fedorapeople.org/storage/testing/30-03-2009-1024-i586.img (this is for the x86 version but it does not matter) 2.Steh through anaconda configuration until you reach to the screen where you can choose "Create custom layout" 3. Click "Next" Actual results: It throws an exception in the python code. It complains about the line 931 in partition_gui.py : devname = "%s" % device.path . The error is "AttributeError: "NoneType" object has no attribute "path"" . This seems to indicate that "device" is not properly initialized. I have to say that this error is the same even if I don't use the "updates" parameter in GRUB, so it's not the fault of the i586 img file. Also the same error appears using the x86_64 boot.iso . Expected results: Should not crash. Additional info: I'll attach the logs for the x64 and x86 versions with the "path" issue.
Hi, Regarding the "path" issue I think I have found in what conditions it can be reproduced. First of all , it does not matter if you use the "updates" parameter in GRUB. The error is apparent only if you have a flash drive connected to the computer with an INVALID partition table, like the one in 30-03-2009-1024-i586.img (which is an image of a partition but it does not have an MBR). So if you happen to have the flash drive connected and you hit "Next" after choosing "Create custom layout" an exception is thrown . I have written an empty partition table to the flash drive with fdisk. After reboot, I went through the same steps in the installer and this time there was no problem, the exception did not happen. Of course there is no problem if the flash drive is not connected at all. So what do you do if you want to use an "updates" image on a flash drive and you don't want to have this error ? You can unplug the flash drive after anaconda enters graphical mode (at the first installation screen). I have verified this and indeed I was able to see all RAID sets and not have an error after I choose "Create custom layout" and hit "Next". I hope this helps in solving the problem. Thank you.
For my future reference: anaconda 11.5.0.38 exception report Traceback (most recent call first): File "/tmp/updates/partition_gui.py", line 931, in populate devname = "%s" % device.path File "/tmp/updates/partition_gui.py", line 1353, in getScreen self.populate(initial = 1) File "/tmp/updates/gui.py", line 1401, in setScreen new_screen = self.currentWindow.getScreen(anaconda) File "/tmp/updates/gui.py", line 1318, in nextClicked self.setScreen () AttributeError: 'NoneType' object has no attribute 'path'
*** Bug 493350 has been marked as a duplicate of this bug. ***
any workarround ?
filesystem error detected cannot continue :-(
*** Bug 493569 has been marked as a duplicate of this bug. ***
Created attachment 338203 [details] Anaconda dump Seeing the same - w/o a USB device. (HP DL585G5 in this case.) Crash log attached.
Traceback (most recent call first): File "/usr/lib/anaconda/iw/partition_ui_helpers_gui.py", line 334, in createPreExistFSOptionSection if not formatcb.get_active() and not origfs.migrate: File "/usr/lib/anaconda/iw/lvm_dialog_gui.py", line 491, in editLogicalVolume (row, self.fsoptionsDict) = createPreExistFSOptionSection(reallv, maintable, row, mountCombo, self.storage, ignorefs = ["mdmember", "lvmpv", "vfat"], luksdev=templuks) File "/usr/lib/anaconda/iw/lvm_dialog_gui.py", line 716, in editCurrentLogicalVolume self.editLogicalVolume(lv) File "/usr/lib/anaconda/iw/lvm_dialog_gui.py", line 747, in editLogicalVolumeCB self.editCurrentLogicalVolume() AttributeError: 'NoneType' object has no attribute 'get_active' similar log from bug 495288 which might thus be a duplicate of the present one, but then, the summary should be changed, because no USB stick or other external device is connected to the system. Note that this bug occurs on F11-Snap1-Live-i686 (!). Not being able to reuse an existing LVM disk layout is a serious show stopper. Shouldn't this bug be added to the F11 blocker bug then?
> a serious show stopper. Shouldn't this bug be added to the F11 blocker bug > then? yes
Joachim - the traceback you are seeing is completely different from the initial bug report here and has nothing to do with this bug. We already have a bug repot for that and it should be fixed in rawhide. For the initial bug report, yes it should probably be a blocker.
General note: AttributeError: 'foo' object has no attribute 'bar' is a generic Python error message which you'll see in any Python app, caused by all sorts of different problems. Unless 'foo' and 'bar' are the same, and the rest of the traceback looks the same or similar, just the existence of an error message in that form does *not* mean two bugs are the same. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Able to reproduce this by doing a virt install and mixing disks from previous installations. I think the reproducer for me is: 1) Install F-10 with lvm (using vda, vdb, vdc, vdd) 2) Install F-10 with only ext3 partitions (using vda) 3) Attempt to install rawhide (using vda, vdb, vdc, vdd) anacdump.txt uploaded as attachment#339554 [details]
I am unable to reproduce the original bug described here under the latest rawhide. If I have an invalid USB storage device attached when anaconda begins, I am prompted to write a disk label to it. If I attach it later, nothing happens.
For a potentially important bug like this it would really be better to set the bug to NEEDINFO than simply close it, David. There could be some small wrinkle that prevents you from reproducing it but doesn't make in invalid or unimportant... Alexandru, can you test with latest Rawhide and see if you can still reproduce? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
how to test ? anyone can try to install using kvm ? for me crashes!
Hi, I have tested again with the latest boot.iso from : http://download.fedora.redhat.com/pub/fedora/linux/development/x86_64/os/images/ The sha1 sum of the file is: 6d7bf7cd7b6ad9bb7cb031ee72ee2f0023b363c9 Unfortunately the bug seems to be still present. To reproduce it is very easy: 1. Get an ext3 partition image like 10-04-2009-1118-x86_64.img (I shall attach it ). 2. Write it to a flash drive with: dd if=10-04-2009-1118-x86_64.img of=/dev/sdc (I assume that sdc is the device for the flash drive, check dmesg | tail -n 10 after you plug it in) 3.Step through anaconda configuration until you reach the screen where you can choose "Create custom layout" (and choose this option) 4. Click "Next" Then the crash happens. I shall attach the logs from the /tmp folder. Thanks. PS: The boot.iso is dated 15th of April 2009 and the anaconda version is 11.5.0.44
Created attachment 339763 [details] Anaconda logs in /tmp after the crash
Created attachment 339764 [details] Archive containing an image of an ext3 partition Please unzip it first and write it to a flash drive with dd.
Joel, Looks like the problem here is libparted wanting to force a PedFileSystem on to a PedPartition. The device here contains the filesystem, there is no partition involved. Libparted needs a way to recognize and allow filesystems on PedDisk objects as well as PedPartitions. In the struct _PedDisk definition in disk.h, perhaps a union could work. We can't have a filesystem on a disk and have partitions, so maybe: union _contents { PedPartition *part_list; PedFileSystemType fs_type; } disk_contents; A PedFileSystem is already defined to belong to a Geometry, so this is really just an expansion of the disk and partition abstractions. Whatever changes are made in libparted, keep me in the loop because this will affect pyparted's API.
This bug or something similar is still hit in anaconda-11.5.0.47 (ppc64 build of 22-Apr-2009 12:45). Using graphical install, select 'custom partition layout', and soon after the exception is hit. -Geoff
David: I just saw this. I'll get on it tmrrow. Question: If the filesystem is on the device, doesn't it mean that the partition table is not needed? Isn't this just a case of having partition metadata and filesystem metadata mixed in the same device?
Same here on a HP DL585G5 using F11/x86_64/Preview using a bootpxe image. Custom partition table selected (Existing F9 installation; F10's Anaconda failed to install on this machine) -> Exception. (The report bug attached the exception log to https://bugzilla.redhat.com/attachment.cgi?id=343278) P.S. No idea why 493350 is marked as duplicate of this bug. (Unless USB/flash has nothing to do with this bug - in which case, can any please modifiy the title?) - Gilboa
Can someone that saw the failure post whatever 'parted DEVICE print free' spits out. The device is where the usb is in a running system. The output can be from an f10 installation.
As I read in the code (and all my tests point to this). The loop label is used to represent a special kind of device state. A loop label will be "created" when a device has no label but has a detectable filesystem inside. This is the case with the ext3 filesystem in the usbkey device. A loop label does not get "created" when there is no fs inside the device. What I propose is to ignore the loop labels in anaconda. Since anaconda does not handle filesystems without a partition table. We could ignore it in storate/__init__.py:323 or we can ignore it when we are creating the devicetree. David: With respect to comment #19. IMO, this should not be handled by parted. If there are no partitions involved, then its the job of some other utility to handle the issue. I know that parted has some filesystem code, but upstream is trying to get rid of it and it would be unwise to depend on it.
I did some testing with today's rawhide build (11-May-2009 08:52) and found that this bug seems to be hit when a USB device is formatted with a filesystem on the raw USB device, and there is some data in the first sector of the device. It seems that devices formatted from fedora with mkdosfs (mkfs.vfat) works OK, at least I didn't get any exceptions with my testing: 1) mkdosfs -I /dev/sdc 2) run installer 3) success I found that devices formatted as FAT32 from Windows XP will hit the bug: 1) using Windows XP: format F: /FS:FAT32 2) run installer 3) fails I noticed parted doesn't seem to show this device doesn't have a partition table: Model: LEXAR JUMPDRIVE (scsi) Disk /dev/sdc: 129MB Sector size (logical/physical): 512B/512B Partition Table: loop Number Start End Size File system Flags 1 0.00B 129MB 129MB fat32 Fdisk doesn't like it though: Disk /dev/sdc: 128 MB, 128974848 bytes 4 heads, 62 sectors/track, 1015 cylinders Units = cylinders of 248 * 512 = 126976 bytes Disk identifier: 0x6f20736b This doesn't look like a partition table Probably you selected the wrong device. Device Boot Start End Blocks Id System /dev/sdc1 ? 3137645 7740507 570754815+ 72 Unknown Partition 1 has different physical/logical beginnings (non-Linux?): phys=(357, 116, 40) logical=(3137644, 3, 11) Partition 1 has different physical/logical endings: phys=(357, 32, 45) logical=(7740506, 0, 51) Partition 1 does not end on cylinder boundary. /dev/sdc2 ? 680200 8486766 968014120 65 Novell Netware 386 Partition 2 has different physical/logical beginnings (non-Linux?): phys=(288, 115, 43) logical=(680199, 2, 47) Partition 2 has different physical/logical endings: phys=(367, 114, 50) logical=(8486765, 0, 42) Partition 2 does not end on cylinder boundary. /dev/sdc3 ? 7539845 15346410 968014096 79 Unknown Partition 3 has different physical/logical beginnings (non-Linux?): phys=(366, 32, 33) logical=(7539844, 2, 30) Partition 3 has different physical/logical endings: phys=(357, 32, 43) logical=(15346409, 3, 39) Partition 3 does not end on cylinder boundary. /dev/sdc4 ? 11635812 11636035 27749+ d Unknown Partition 4 has different physical/logical beginnings (non-Linux?): phys=(372, 97, 50) logical=(11635811, 0, 25) Partition 4 has different physical/logical endings: phys=(0, 10, 0) logical=(11636034, 3, 33) Partition 4 does not end on cylinder boundary. Partition table entries are not in disk order -Geoff
[root@white ~]# parted /dev/sdc print free Model: LEXAR JUMPDRIVE (scsi) Disk /dev/sdc: 129MB Sector size (logical/physical): 512B/512B Partition Table: loop Number Start End Size File system Flags 1 0.00B 129MB 129MB fat32
(In reply to comment #25) Thx for testing.... > I did some testing with today's rawhide build (11-May-2009 08:52) and found > that this bug seems to be hit when a USB device is formatted with a filesystem > on the raw USB device, and there is some data in the first sector of the > device. > > It seems that devices formatted from fedora with mkdosfs (mkfs.vfat) works OK, > at least I didn't get any exceptions with my testing: > > 1) mkdosfs -I /dev/sdc > 2) run installer > 3) success This is because mkfs.vfat creates a empty partition table on the device. Which is kindof illogical to me as it creates it with no partitions. This in turn could cause confusion when editing the partition table. It could lead to the deletion of the file system. Given that the USB has a partition table, anaconda has no problem with it. > > I found that devices formatted as FAT32 from Windows XP will hit the bug: > > 1) using Windows XP: format F: /FS:FAT32 > 2) run installer > 3) fails > Most probably because it does not have a partition table. > I noticed parted doesn't seem to show this device doesn't have a partition > table: > > Model: LEXAR JUMPDRIVE (scsi) > Disk /dev/sdc: 129MB > Sector size (logical/physical): 512B/512B > Partition Table: loop > > Number Start End Size File system Flags > 1 0.00B 129MB 129MB fat32 > Actually the "loop" label is for devices with no partition table but with a FS inside. This is used for device-mapper devices in parted internals. Not that it can't be used in other places. but its not doing what its meant to do in this case. > > Fdisk doesn't like it though: > > Disk /dev/sdc: 128 MB, 128974848 bytes > 4 heads, 62 sectors/track, 1015 cylinders > Units = cylinders of 248 * 512 = 126976 bytes > Disk identifier: 0x6f20736b > > This doesn't look like a partition table > Probably you selected the wrong device. Yep, No partition table ^^^^.
I found a USB device setup with these Linux commands will hit the bug, so a Windows XP machine is not needed for testing: dd if=/dev/zero of=/dev/sdc bs=512 count=1 mkdosfs -I /dev/sdc syslinux -s /dev/sdc Tested on PS3 game console with today's rawhide build (13-May-2009 12:06). -Geoff
(In reply to comment #28) > I found a USB device setup with these Linux commands will hit the bug, so a > Windows XP machine is not needed for testing: > > dd if=/dev/zero of=/dev/sdc bs=512 count=1 > mkdosfs -I /dev/sdc > syslinux -s /dev/sdc > Yep this is consistent. None of these commands actually create a partition table. The fact that it has or not a functioning MBR is not related to the bug.
I am seeing something simillar. Correct me if I am wrong. If I create a usb stick from a live cd iso(rawhide/f11 - 20080515). Boot from the usb stick, try to install using "liveinst. Partitioning never completes after clicking on Next. Eventually if I do click next i.e. 20 minutes later a error dialog appears. Asks me to format "/" Then I get an Exception Occured Dialog. Error attached to ticket. Note The same image booted from iso installs correctly. This method worked previously with Fedora 10.
Created attachment 344139 [details] InstallError.txt from usb install.
If I manually format the partition from the console and only assign a mount point in anaconda, it installs correctly.
Joel, what is the status here? What is modified, how can we re-test it?
Traxtopel: The failure you've noted in comment#30 (and comment#31) I believe is reported as bug#491927. This issue has been fixed and tested. Please feel free to add your findings to that bug.
Sorry if I posted to the wrong bug, I thought the issue I am seeing is related to this one. I am on anaconda-11.5.0.52 and I still see the same problem.
traxtopel: my apologies, I gave an incorrect bug# in comment#34. The traceback you've uploaded in comment#31 is a new issue that I cannot find a bug reported for. Can you please record your issue as a new bug report?
Hi, Sorry for not updating this bug report for so long but I bricked my motherboard with a bad bios flash. I have checked the latest boot.iso from: http://download.fedora.redhat.com/pub/fedora/linux/development/x86_64/os/images/ (dated 18th May 2009). Thes usb flash was written with the ext3 image that I have previously uploaded. Unfortunately the crash still happens. I shall attach the anaconda logs after the crash. Thank you.
Created attachment 344605 [details] Anaconda logs after the crash
I've tried to reproduce this bug with May 20 Rawhide (anaconda-11.5.0.54) on i386. I tested with a USB stick prepared using the image from comment #18 and one made with the script in comment #28. In both cases, while "Finding storage devices" (e.g. after choosing the keyboard layout) anaconda popped a warning message about sdb needing to be reinitialized. If I choose to ignore it, everything proceeds normally after that. Custom partitioning works fine, although /dev/sdb is not present (obviously - I told anaconda to ignore it, after all.) If I reinitialize it, everything proceeds normally, and it shows up as expected in Custom Partitioning. It seems like this bug is fixed. Can the reporters please retry with a new boot.iso?
Hi, I have tested with May 20 Rawhide on x86_64 and now it does not crash anymore, it behaves the way Will Woods wrote in the previous post. If anyone else having problems could test the latest version it would be great. Thanks for your hard work!
I tested this on a PS3 game console and an i386 PC with today's rawhide build (21-May-2009), and this bug is fixed. -Geoff
In bug#493350 (see attachment#347210 [details]) this traceback still appears in anaconda-11.5.0.59. Reopening this bug. Perhaps the traceback is the same but the use case is different? If that is the case, we can track this in a new bug?
jlaska: Can I assume that you installed with a USB key that had no partition table but had a FS on the whole device?
Joel: Unclear, the reproducer was logged by another tester (see https://bugzilla.redhat.com/show_bug.cgi?id=493350#c15). I wanted to let you know since the failure is against anaconda-11.5.0.59 and I believe the fixes were intended to surpress any tracebacks regardless of the USB key partition contents? Could there be another use case lurking that is still exposed to the traceback seen in attachment#347210 [details]?
Created attachment 357461 [details] updates image. Testing with anaconda 12.15 and the attached updates image I get no traceback. I do get the device in the list. which is probably wrong, but thats an issue for another bug. I am using a 2Gb usb formatted as vfat with not partition table. and no MBR.
I tested this on PS3 game console with today's rawhide build (14-Aug-2009 07:16) and this problem seems to be fixed. -Geoff
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
As indicated in comment #47 and #48, this has been fixed (in anaconda, as it was an anaconda bug). Closing.