Description of problem: Attempt to install to two disks having duplicate volume group names by first removing all partitions and then using automatic configuration. The following was filed automatically by anaconda: anaconda 18.37.3 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/formats/__init__.py", line 322, in destroy raise FormatDestroyError(msg) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/formats/lvmpv.py", line 134, in destroy DeviceFormat.destroy(self, *args, **kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/deviceaction.py", line 493, in execute self.format.destroy() File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 323, in processActions action.execute() File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 323, in doIt self.devicetree.processActions() File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 174, in turnOnFilesystems storage.doIt() File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 114, in doInstall turnOnFilesystems(storage) File "/usr/lib64/python2.7/threading.py", line 504, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 91, in run threading.Thread.run(self, *args, **kwargs) FormatDestroyError: error wiping old signatures from /dev/sdb2: 1 Additional info: cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8 cmdline_file: initrd=initrd0.img root=live:CDLABEL=Fedora-18-TC2-x86_64-Live-Deskto rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=vmlinuz0 executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.6.10-4.fc18.x86_64 other involved packages: python-libs-2.7.3-13.fc18.x86_64 package: anaconda-18.37.3-1.fc18.x86_64 packaging.log: product: Fedora release: Fedora release 18 (Spherical Cow) type: libreport version: 18
Created attachment 664214 [details] File: anaconda.log
Created attachment 664215 [details] File: environ
Created attachment 664216 [details] File: ifcfg.log
Created attachment 664217 [details] File: messages
Created attachment 664218 [details] File: program.log
Created attachment 664219 [details] File: storage.log
Created attachment 664220 [details] File: anaconda-tb
Created attachment 664296 [details] anaconda-tb-B5fTrJ corresponding to reproducer Reproducer: Create two empty disk images: $ qemu-img create f18-test-1.img 11G $ qemu-img create f18-test-2.img 12G Complete two minimal installs with automatic storage configuration using the DVD: $ qemu-kvm -m 2048 -hda f18-test-1.img -cdrom ~/xfr/fedora/F18/F18-Final/TC2/Fedora-18-TC2-x86_64-DVD.iso -usb -vga qxl -boot menu=on -usbdevice mouse $ qemu-kvm -m 2048 -hda f18-test-2.img -cdrom ~/xfr/fedora/F18/F18-Final/TC2/Fedora-18-TC2-x86_64-DVD.iso -usb -vga qxl -boot menu=on -usbdevice mouse Start the Live CD with both disk images and update the installer: $ qemu-kvm -m 2048 -hda f18-test-1.img -hdb f18-test-2.img -cdrom ~/xfr/fedora/F18/F18-Final/TC2/Fedora-18-TC2-x86_64-Live-Desktop.iso -usb -vga qxl -boot menu=on -usbdevice mouse Select both disks in Installation Destination. Click Continue. Check "I don't need help ..." Click Reclaim space. Click "+" to expand Unknown list. Click "-" to delete. Check "Delete all ..." Click Delete it. Click to automatically create default storage configuration. Click Finish Partitioning. Click Begin Installation. Exception occurs at Preparing to install: FormatDestroyError: error wiping old signatures from /dev/sdb2: 1
Proposing as a blocker per F18 Alpha release criterion:[1] 9. The installer must be able to complete an installation using the text, graphical and VNC installation interfaces This could also apply: 12. The installer must be able to complete an installation using automatic partitioning to any sufficiently large target disk, whether unformatted, empty, or containing any kind of existing data The use case is moving a disk having a previously installed Fedora release to another system having a previously installed Fedora release and then reinstalling to use both disks. [1] https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
Created attachment 664324 [details] screenshot showing Manual Partitioning dialog with Unknown installations
Attempting to reproduce Bug 887539. Selected sda, but not sdb, for volume group "fedora" containing "/" and "swap". Package: anaconda-18.37.3-1.fc18.x86_64 OS Release: Fedora release 18
Created attachment 664325 [details] anaconda-tb-E0vu9v corresponding to Comment 11 For this log, both disks were selected, all partitions were deleted in Manual Partitioning, and the Modify dialog was used to select sda, but not sdb, for the volume group "fedora" containing "/" and "swap". Tested with: $ qemu-kvm -m 2048 -hda f18-test-1.img -hdb f18-test-2.img -cdrom ~/xfr/fedora/F18/F18-Final/TC2/Fedora-18-TC2-x86_64-Live-Desktop.iso -usb -vga qxl -boot menu=on -usbdevice mouse
steve: can you check what version of lvm2 you had in your test environment? We believe this may be a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=876789 . anaconda folks, can you comment if it's that bug, or a more detailed wrinkle? Discussed at 2012-12-17 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-17/f18final-blocker-review-5.2012-12-17-16.40.log.txt . We need more info (see above) to decide the status of this bug.
(In reply to comment #8) ... > $ qemu-kvm -m 2048 -hda f18-test-1.img -hdb f18-test-2.img -cdrom > ~/xfr/fedora/F18/F18-Final/TC2/Fedora-18-TC2-x86_64-Live-Desktop.iso -usb > -vga qxl -boot menu=on -usbdevice mouse ... $ cat lvm2-version-1.txt [liveuser@localhost ~]$ rpm -qa 'lvm*' | sort lvm2-2.02.98-4.fc18.x86_64 lvm2-libs-2.02.98-4.fc18.x86_64
Discussed at 2012-12-21 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-21/f18final-blocker-review-7.2012-12-21-18.33.log.txt . anaconda team was able to diagnose this: it's caused by having two identically-named VGs (which in turn was caused by installing over two existing F18 installs). Given that this is a pretty odd corner case, this is rejected as a blocker. It's also rejected as NTH as anaconda team considers it too weird to fix this late, so there's no point accepting it as NTH. Note that Final will have the hostname-setting stuff, so even if for some reason you really need to reproduce this scenario, you can just set different hostnames for the two initial installs and their VG names will be different. or directly set different VG names.
How is the use case described in Comment 9 "odd" or "weird"? "The use case is moving a disk having a previously installed Fedora release to another system having a previously installed Fedora release and then reinstalling to use both disks." A problem I am seeing with some of the blocker rationales is that they are ad hoc instead of persuasive. Anyway, I look forward to reading the workarounds in "Common Bugs" ... 1. Start a terminal. 2. Read the parted man page. 3. Memorize the partition device names. 4. Blah, blah, blah. Or maybe it starts with: 1. Remove one of the disk drives you just installed into your system. 2. ... BTW, cloned disks will have the same hostname by definition.
steve: just because two disks both have Fedora on them doesn't mean they will have identically named VGs. It's in fact the least likely case. In releases prior to F18, you set a hostname before storage config, and the VG name was based on the selected hostname - so two disks will only have identically named VGs if the Fedora installs had identical hostnames (first part at least). I think you could edit the VG name in custom partitioning too. In F18 you definitely can, and the VG name will still be based on hostname if you set one in the Network spoke.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19