tcooper
commented
9 years ago Think I just ran across this on sdb of a vm-container appliance that I had been doing disk testing with (writing random data with dd and /dev/urandom). My node installation is stuck at (from /tmp/storage.log)...
19:24:15,523 DEBUG : scanning sdb (/devices/pci0000:00/0000:00:01.0/0000:05:00.0/host0/port-0:1/end_device-0:1/target0:0:1/0:0:1:0/block/sdb)...
19:24:15,523 DEBUG : looking for device 'sdb'...
19:24:15,523 DEBUG : found None
19:24:15,524 DEBUG : DeviceTree.addUdevDiskDevice: name: sdb ;
19:24:15,525 DEBUG : sdb is a disk
19:24:15,525 DEBUG : getFormat('None') returning DeviceFormat instance
19:24:15,527 DEBUG : DiskDevice._setFormat: sdb ; current: None ; type: None ;
19:24:15,527 DEBUG : added disk sdb (id 0) to device tree
19:24:15,527 DEBUG : looking up parted Device: /dev/sdb
19:24:15,528 DEBUG : DeviceTree.handleUdevDeviceFormat: name: sdb ;
19:24:15,529 DEBUG : DeviceTree.handleUdevDiskLabelFormat: device: sdb ;
19:24:15,529 DEBUG : getFormat('None') returning DeviceFormat instance
19:24:15,530 DEBUG : DiskDevice.setup: sdb ; status: True ; orig: False ;
19:24:15,546 DEBUG : required disklabel type for sdb (1) is None
19:24:15,546 DEBUG : default disklabel type for sdb is msdos
19:24:15,546 DEBUG : selecting msdos disklabel for sdb based on size
19:24:15,547 DEBUG : DiskLabel.__init__: device: /dev/sdb ; labelType: msdos ; exists: True ;After zeroing out the first few MB of the drive and rebooting the install continues past the above with...
name = sdb status = True parents = []
kids = 0
id = 0
uuid = None format = <storage.formats.disklabel.DiskLabel object at 0x7f5c8ab80c10> size = 286168.148438
major = 8 minor = 16 exists = True
sysfs path = /devices/pci0000:00/0000:00:01.0/0000:05:00.0/host0/port-0:1/end_device-0:1/target0:0:1/0:0:1:0/block/sdb partedDevice = <parted.device.Device object at 0x7f5c8ab80a10>
target size = 0 path = /dev/sdb
format args = [] originalFormat = DeviceFormat instance (0x7f5c7a30fd10) --
type = None name = Unknown status = False
device = /dev/sdb uuid = None exists = True
options = None supported = False formattable = False resizable = False
removable = False partedDevice = <parted.device.Device object at 0x7f5c8ab80a10>
20:35:40,269 DEBUG : got format: DiskLabel instance (0x7f5c8ab80c10) --
type = disklabel name = partition table (MSDOS) status = False
device = /dev/sdb uuid = None exists = True
options = None supported = False formattable = True resizable = False
type = msdos partition count = 0 sectorSize = 512
align_offset = 0 align_grain = 2048
partedDisk = <parted.disk.Disk object at 0x7f5c8ab93510>
origPartedDisk = <parted.disk.Disk object at 0x7f5c8ab93690>
partedDevice = <parted.device.Device object at 0x7f5c8ab93450>
Since centos 6.3 the clearpart --all --initlabel does not clean anymore all the partition table on the disk but it prompt for user input before proceeding.
This problem happen only when there is a corrupted partition on the disk which anaconda can't recognize, it does not happen if the disk has a standard dos partition. (It happened to me with a disk I took out of a old broken thumper)
For this reason we need to put a zerombr in the kickstart so anaconda will stop prompting users. I'm wondering what kind of repercussion this might have, and if it is worth to make this change. http://fedoraproject.org/wiki/Anaconda/Kickstart#zerombr
Luca
http://serverfault.com/questions/411023/centos-kickstart-on-kvm-doesnt-clear-partition-labels
@ppapadopoulos @tcooper