Red Hat Bugzilla – Bug 503094
Exception when partition was LVM earlier
Last modified: 2011-03-18 05:45:54 EDT
Install Fedora 10 with default partitioning, i.e.
/dev/sda2 Linux LVM
Run fdisk, delete 2nd partition and create a smaller swap one, so that it is now:
/dev/sda2 Linux swap
It does not matter if I run mkswap /dev/sda2 or not.
Boot F-11 netinstall CD, and exception occurs at "Finding storage devices":
anaconda 18.104.22.168 exception report
File "/usr/lib/anaconda/storage/devicelibs/lvm.py", line 397, in lvactivate raise LVMError("lvactivate failed for %s" %lv_name)
File "/usr/lib/anaconda/storage/devices.py", line 1996, in setup lvm.lvactivate(self.vg.name, self._name)
File "/usr/lib/anaconda/storage/devicetree.py", line 1271, in handleUdevLVMPVFormat lv_device.setup()
File "/usr/lib/anaconda/storage/devicetree.py", line 1497, in handleUdevDeviceFormat self.handleUdevLVMPVFormat(info, device)
File "/usr/lib/anaconda/storage/devicetree.py", line 1167, in addUdevDevice self.handleUdevDeviceFormat(info, device)
File "/usr/lib/anaconda/storage/devicetree.py", line 1627, in populate self.addUdevDevice(dev)
File "/usr/lib/anaconda/storage/__init__.py", line 288, in reset self.devicetree.populate()
File "/usr/lib/anaconda/storage/__init__.py", line 101, in storageInitialize storage.reset()
LVMError: lvactivate failed for LogVol00
Local variables in innermost frame:
args: ['lvchange', '-a', 'y', 'VolGroup00/LogVol00']
This build of anaconda was done quite a while ago. Can you please test again with F11 RC when it is made available and let us know if this is still a problem for you? If so, please attach the complete /tmp/anacdump.txt file to this bug report. Thanks.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
Created attachment 347097 [details]
When booting Fedora-11-i386-netinst.iso
*** This bug has been marked as a duplicate of bug 493699 ***
Still happens with Fedora-14-Beta-i386-netinst.iso.
Created attachment 452623 [details]
traceback with Fedora-14-Beta-i386-netinst.iso
That's a completely different traceback, though, so it's not the same bug. This latest one seems to be caused by this:
01:53:46,775 WARNING kernel:device-mapper: table: 253:0: sda2 too small for target: start=384, len=13631488, dev_size=2120580
blkid is reporting that sda2 is an lvm pv. If this is not the case the bug is blkid's.
Reporter: for future reference, use wipefs before destroying old partitions to ensure their metadata does not cause issues like this.
I guess that the old mkswap from F10 does not zap the first block on the device. Please, re-create the swap area be less old mkswap version or use wipefs(8) to delete the obsolete signature.
if the problem persist than I'd like to see debug output from blkid:
Of course I can use wipefs and I will not have this problem. But I reported this problem because I think anaconda should not crash in such cases. If partition is swap, why does it try to detect lvm pv in it? Shouldn't it try to detect only in LVM partitions?
(In reply to comment #10)
> If partition is swap, why does it try to detect lvm pv in it? Shouldn't it try to detect only in LVM partitions?
Partition ID is not important here, important is what blkid detects on that partition.
The bug in mkswap was that it did not properly wiped previous signature and blkid later reports wrong old signature / device type here.
Well, anaconda should probably not crash anyway:-)
(In reply to comment #11)
> Partition ID is not important here, important is what blkid detects on that
Is it a design decision? I thought if I set the partition as swap, it should be swap, and not what it was before.
(In reply to comment #12)
> (In reply to comment #11)
> > Partition ID is not important here, important is what blkid detects on that
> > partition.
> Is it a design decision? I thought if I set the partition as swap, it should be
> swap, and not what it was before.
Linux kernel does not care about partition type, you can use regular files, unpartitioned devices or whatever for swap, lvm pv, etc.
The swap is enabled by swapon(2) syscall on arbitrary block device (or regular file) where is swap area header. The special swap partition type is unnecessary.
OK then, don't look at swap. The bug I reported is because I wanted to go from LVM to non LVM setup, but I didn't want to fill large partition with zeros because it will take a lot of time. So if I delete /dev/sda2 and create it in anaconda I will not get a crash? Just tested - yes, if I delete 2nd partition, anaconda does not crash. As for me, I'm happy as I know a workaround, but the bug (crash) probably should be solved anyway?
The best way how remove unwanted signatures(s) from block device is the wipefs(8) command. It's really better than fill large partition with zeros :-)
Closing... if you are able to (re)produce any anaconda crash, then open a new bug against anaconda. Thanks.