Bug 617337

Summary: anaconda backtraces because pyblock does not create a device node for the ext. partition
Product: [Fedora] Fedora Reporter: Maurice Pijpers <mauricepijpers>
Component: python-pyblockAssignee: Hans de Goede <hdegoede>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: anaconda-maint-list, hdegoede, joel.granados, jonathan, mkolman, pjones, vanmeeuwen+fedora
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: anaconda_trace_hash:2d98a8b7f93a63c3baacc1287fc97c4eeaa5954a3c7c7c0f3bb45122e4995191
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 617593 618641 (view as bug list) Environment:
Last Closed: 2010-07-27 12:53:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 618641    
Attachments:
Description Flags
Attached traceback automatically from anaconda.
none
Anaconda.log
none
storage.log
none
anaconda-tb-P3aqqZ none

Description Maurice Pijpers 2010-07-22 19:21:29 UTC
The following was filed automatically by anaconda:
anaconda 13.42 exception report
Traceback (most recent call first):
  File "/usr/lib/anaconda/storage/__init__.py", line 787, in destroyDevice
    if device.format.exists and device.format.type:
  File "/usr/lib/anaconda/storage/partitioning.py", line 390, in removeEmptyExtendedPartitions
    storage.destroyDevice(extended)
  File "/usr/lib/anaconda/storage/partitioning.py", line 378, in clearPartitions
    removeEmptyExtendedPartitions(storage)
  File "/usr/lib/anaconda/storage/partitioning.py", line 183, in doAutoPartition
    clearPartitions(anaconda.storage)
  File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 126, in gotoNext
    self.moveStep()
  File "/usr/lib/anaconda/gui.py", line 1313, in nextClicked
    self.anaconda.dispatch.gotoNext()
AttributeError: 'NoneType' object has no attribute 'format'

Comment 1 Maurice Pijpers 2010-07-22 19:21:34 UTC
Created attachment 433792 [details]
Attached traceback automatically from anaconda.

Comment 2 Maurice Pijpers 2010-07-22 19:31:54 UTC
System uses 1 ATA/IDE disk which contains grub and a Windows partition and 2 SATA disk in an nvidia_raid that contains a Fedora 11 installation. Whenever the nvidia raid is selected for installation the installer stop with the attached messages.

Comment 3 Hans de Goede 2010-07-23 13:53:55 UTC
Hi,

Thanks for the bug report!

Note to self here is what happening:

1) Due to the fix for bug 583484:
http://git.fedorahosted.org/git/?p=pyblock.git;a=commitdiff;h=030c578f061509022e4db5136149be173b16139d
pyblock no longer creates a mapping, and thus a device node for the extended partition itself
2) This means the extended partition does not get added to the device tree
3) This causes this backtrace when auto-partitioning tries to remove the extended partition (as after clearing partitions it is empty).

Solution:

Make pyblock create a mapping for extended partitions again, but this time one which is compatible with kpartx's mapping to avoid bug 583484.

I hope that your nvidia raid is still in the condition which triggers this fault, I'll provide you with an updates.img with a proposed fix to test this.

Regards,

Hans

Comment 4 Hans de Goede 2010-07-25 09:57:26 UTC
Maurice,

This should be fixed in python-pyblock-0.49-1.fc14, as you cannot simply replace a package inside the installer image, I've created an updates.img file for you:
http://people.fedoraproject.org/~jwrdegoede/updates-617337-x86_64.img

To use this add:
updates=http://people.fedoraproject.org/~jwrdegoede/updates-617337-x86_64.img

To the syslinux / isolinux cmdline when starting the installer. Note that updates.img files do not work with livecd installs!

Thanks & Regards,

Hans

Comment 5 Maurice Pijpers 2010-07-25 12:31:09 UTC
Hans,

I tried the updates.img file but now it ends with another error (during the creation of filesystem and logical volumes):
An error occurred mounting device /dev/mapper/via_cecccejhajp1 as /boot: device /dev/mapper/via_cecccejhajp1 does not exist. This is a fatal error and the install cannot continue. storage.log and anaconda.log are attached.

Comment 6 Maurice Pijpers 2010-07-25 12:31:59 UTC
Created attachment 434233 [details]
Anaconda.log

Comment 7 Maurice Pijpers 2010-07-25 12:32:28 UTC
Created attachment 434234 [details]
storage.log

Comment 8 Hans de Goede 2010-07-25 18:24:30 UTC
Hi,

Thanks for testing!

Hmm,

This is weird the error happens after creating the filesystem, so
mke2fs /dev/mapper/via_cecccejhajp1
Has succeeded, but then when we are done creating filesystems and try to mount
/dev/mapper/via_cecccejhajp1 we fail ?

That is really, well weird. Can you try again, at the fatal error dialog, you should see a save button or some such, choice that, and then you should get a traceback, save that to bugzilla, or attach the generated /tmp/anaconda-tb-* file here.

If you do not get a save button, then switch to tty2 (ctrl + alt + F2), and press arrow up there a few times, you should fine something like "killall -SIGUSRx anaconda" in the history there, execute it and then you should get a /tmp/anaconda-tb-* file, which you can then attach here.

Thanks,

Hans

Comment 9 Maurice Pijpers 2010-07-26 16:19:27 UTC
Created attachment 434456 [details]
anaconda-tb-P3aqqZ

Comment 10 Maurice Pijpers 2010-07-26 16:23:20 UTC
Hans, 

The traceback is attached, please note that when I tried to reproduce this again the first time, the error didn't occur (I'm guessing because the old lv's and vg's were removed. So after installing it again and then retrying, the error occurs again. So it seems that this only occurs when it has to remove the old vg's and lv's (with filesystems).

Hope this helps,

Maurice

Comment 11 Hans de Goede 2010-07-27 12:53:33 UTC
Maurice,

Thanks for the logs, I've filed a new bug 618641 for tracking the new issue you are seeing, and I'm closing this one, as the original problem is fixed.

Regards,

Hans