The following was filed automatically by anaconda:
anaconda 13.21.50 exception report
Traceback (most recent call first):
File "/usr/lib/anaconda/storage/devices.py", line 161, in deviceNameToDiskByPath
File "/usr/lib/anaconda/iw/cleardisks_gui.py", line 169, in getScreen
ident = deviceNameToDiskByPath(d.name)
File "/usr/lib/anaconda/gui.py", line 1415, in setScreen
new_screen = self.currentWindow.getScreen(anaconda)
File "/usr/lib/anaconda/gui.py", line 1336, in nextClicked
File "/usr/lib/anaconda/gui.py", line 1473, in keyRelease
Created attachment 421848 [details]
Attached traceback automatically from anaconda.
This is with 2 disks on KVM domU.
One local disk - 1G and one iSCSI disk - 8G.
I've selected "Use all space" & "Review partitioning" then hit traceback.
The local disk is new disk image which I selected to Re-initialize. The iSCSI disk is image which was previously used for other VMs to test encrypted LVM.
Steps to reproduce:
1) Boot the installer with the local disk
2) By mistake I've selected basic storage configuration
3) Anaconda did disk scanning and asked me to re-initialize vda. I did.
4) Then went back to select specialized storage and add an iSCSI target
5) Went forward to select "Use all space". I was asked to re-initialize vda once again. I did.
Easier steps to reproduce:
1) Create 2 images to use for the virtual machine (using dd)
2) Boot the KVM guest with one of the images as local disk
3) Select specialized storage and add the other image as iSCSI disk
4) When asked select to Re-initialize all devices
5) Select Use all space and continue
Udev is not creating disk/by-path symlinks for virtual disks (eg: vda).
is this related to Bug 591970?
*** Bug 601593 has been marked as a duplicate of this bug. ***
*** Bug 595522 has been marked as a duplicate of this bug. ***
With RHEL6.0-20100615.0/Server/x86_64, udev-147-2.18.el6.x86_64.rpm ,
anaconda-13.21.50-6.el6.x86_64.rpm this is NOT fixed.
Steps to reproduce:
see comment #3. After 5) I've selected "Review partitioning layout" and got the same traceback hitting next.
In /dev/disk/by-path I don't have an entry which points to /dev/vda. There are only entries for sda.
bug #604776 has been opened for the anaconda part of this and QE has been asked if this one can go back to ON_QA. How do we know that the udev part was fixed?
See my previous comment about missing link for vda in /dev/disk/by-path. Isn't this what udev was supposed to fix or not?
(In reply to comment #10)
> bug #604776 has been opened for the anaconda part of this and QE has been asked
> if this one can go back to ON_QA. How do we know that the udev part was fixed?
> See my previous comment about missing link for vda in /dev/disk/by-path. Isn't
> this what udev was supposed to fix or not?
yes, it really should... unless the image in the installer has an old udev.
$ grep path_id /lib/udev/rules.d/60-persistent-storage.rules |grep -q virtual || echo "correct udev version"
the output from the command in comment #12 on both already installed system (0615.0 tree) and in stage2 anaconda is the same -> "correct udev version".
Does this mean that udev part is fixed?
How about bug #591970, is it related?
That would be the problem, it seems. We have been removing the *persistent*
udev rules files from initrd.img during image building. It's been that way
We have a patch on master to address this, so anaconda-13.21.50-8 should fix
Cloning for anaconda, moving this back to MODIFIED.
I am not sure, but we might need additional udev patches according to:
With the fix in anaconda now (see bug #605262) could you please retest this?
Also, are the symlinks there after the first reboot?
Thanks & regards, Phil
Tested with the 0630.n.0 nightly which has udev-147-2.20.el6 and anaconda-13.21.55-1.el6 with the steps to reproduce from comment #0.
In stage2 in anaconda under /dev/disk/by-path there is an entry for the vda disk:
virtio-pci-virtio1 -> ../../vda
as well as for the iSCSI disk.
Installation completed successfully and system was able to boot. Moving to VERIFIED.
*** Bug 607661 has been marked as a duplicate of this bug. ***
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.