| Summary: | DeviceError: ('device has not been created', 'vda4') | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Alexander Todorov <atodorov> | ||||
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||
| Status: | CLOSED WORKSFORME | QA Contact: | Release Test Team <release-test-team> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 6.2 | ||||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | abrt_hash:2732c3f98b61eabecc8148853872cef3249f16d1b55729756a72a4228122f17d | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-10-10 13:48:14 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Bug Depends On: | |||||||
| Bug Blocks: | 691780 | ||||||
| Attachments: |
|
||||||
Created attachment 522928 [details]
File: anaconda-tb-I9X_v4
What I did: /boot - ext4 - force as primary swap - force as primary sw raid - force as primary sw raid - force as primary md0 - RAID0, PV - encrypt lv_root - ext4 - no encryption, use all space proceed with installation and get this traceback. vda4 should be the last sw raid member which I forced as primary. I just performed an installation of RHEL 6.2 Beta in a KVM guest on a RHEL 6.1 host using the guide you posted in comment #2. I don't get a traceback and the partitions are set up as you describe. However, vda4 is not the last swraid member, it is the swap partition. The partitioning code sorts the swap partition down to the end of the disk. But the partitions are still created as you describe: /boot is an ext4 primary partition at vda1 swap is a primary partition at vda4 vda2 and vda3 are primary partitions md0 is created as a RAID 0 array of vda2 and vda3, encrypted, and LVM PV type a volume group is created on the new LVM PV on md0 a single logical volume is created on the volume group called lv_root, on / I don't get a traceback and the only difference is that the swap partition ends up getting sorted down to vda4, but I don't think that's a problem. All of the partitions are primary, as requested. I hit this bug again today with latest 6.4. I was creating and removing partitions. I will try to reproduce more reliably. On a KVM guest with 3 disks: vda - 2GB vdb - 10GB vdc - 10GB * Start with: vda1 - ext4, vda2 - swap vdb1 - physical volume vdc1 - physical volume VG containing vdb1 and vdc1 * Delete the VG and vdb1 * On vdb create 4 ext4 partitions, DO NOT force as primary. Use mount points like /1, /2, /3, /4 * vdb4 is created as extended partition, holding vd5. * delete vdb3, at this point previous vd4/vd5 becomes vd3 (distinguishable by its mount point /4 * Edit vdb3 - force as primary - moves to the top of partitions list in UI (shown as vdb1, /4) * Edit - vdb2, /1 and then vdb3, /2 and force as primary * Now order is vdb1 /1, vdb2 /2, vdb3 /4 * Create new partition, mount it under /3, force as primary - It becomes vdb3 /3 and then we have vd4, /4. * On vdb attempt to create 5th primary partition - anaconda tells you this is not possible. * Return to the disk layout screen, select vdb and delete all partitions by pressing Alt+D * On vdb create RAID partition * Edit vdc1 and format as software raid * Create md0 - RAID0 array mounted under /boot * Delete md0 * Edit vdb1 and vdc1 and change the partitioning type from software raid to physical volume. * Create a VG and a LV for /boot, press F12 (Next) * Anaconda tells you bootable partitions can't be on LVM * Delete /boot * Create new LV for / * Edit vda1 and vda2 and reformat for /boot and swap * Proceed with installation I have the feeling that the creation/edit of primary partitions on vbd causes this bug but I wasn't able to reproduce. I tried several combinations of the steps above, starting with clean disk, not clean disks, etc. but failed to reproduce reliably. |
abrt version: 2.0.5 executable: /mnt/runtime/usr/bin/python hashmarkername: anaconda kernel: 2.6.32-195.el6.x86_64 product: Red Hat Enterprise Linux reason: DeviceError: ('device has not been created', 'vda4') time: Tue Sep 13 09:17:05 2011 version: 6.2 anaconda-tb-I9X_v4: Binary file, 611892 bytes description: :The following was filed automatically by anaconda: :anaconda 13.21.138 exception report :Traceback (most recent call first): : File "/usr/lib/anaconda/storage/devices.py", line 1398, in destroy : raise DeviceError("device has not been created", self.name) : File "/usr/lib/anaconda/storage/deviceaction.py", line 219, in execute : self.device.destroy() : File "/usr/lib/anaconda/storage/devicetree.py", line 713, in processActions : action.execute(intf=self.intf) : File "/usr/lib/anaconda/storage/__init__.py", line 344, in doIt : self.devicetree.processActions() : File "/usr/lib/anaconda/packages.py", line 110, in turnOnFilesystems : anaconda.id.storage.doIt() : File "/usr/lib/anaconda/dispatch.py", line 208, 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 1390, in nextClicked : self.anaconda.dispatch.gotoNext() : File "/usr/lib/anaconda/gui.py", line 1528, in keyRelease : self.nextClicked() :DeviceError: ('device has not been created', 'vda4')