I've got a room of machines here this week that I'm working with. All at one time had Windows installed on them. When I kickstart them using a ks.cfg file with the following partitioning info: zerombr yes clearpart --all part swap --size 512 part /boot --size 75 part / --size 3072 --grow --maxsize 10000 the install cannot be done non-interactively. anaconda insists on displaying the following warning: The partition table on /dev/hda is inconsistent. There are many reasons why this might be the case. Often, the reason is that Linux detected the BIOS geometry i ncorrectly. However, this does not appear to be the case here. It is safe to ign ore, but ignoring may cause (fixable) problems with some boot loaders, and may c ause problems with FAT file systems. Using LBA is recommended. I would expect the clearpart --all to shut this up, but it doesn't.... The partition table as seen from VC 2 of anaconda is: Disk /tmp/hda: 20.5 GB, 20547841536 bytes 255 heads, 63 sectors/track, 2498 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /tmp/hda1 * 1 511 4104576 7 HPFS/NTFS /tmp/hda2 512 2498 15960577+ f Win95 Ext'd (LBA) /tmp/hda5 512 2498 15960546 7 HPFS/NTFS After install, I've got Disk /dev/hda: 20.5 GB, 20547841536 bytes 255 heads, 63 sectors/track, 2498 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 10 80293+ 83 Linux /dev/hda2 11 1284 10233405 83 Linux /dev/hda3 1285 1349 522112+ 82 Linux swap the geometry's the same in both cases, so the warning looks bogus and it keeps me from doing unattended upgrades needlessly....
The warning is caused by the parted library. You can just dd if=/dev/zero of=/dev/hda bs=512 count=1 in your %pre if you want to just clear the partition table.
Right, and dd'ing 447 - 512 on the disc in the %pre does eliminate the message, but I shouldn't have to do that b/c I have clearpart. AFAICT, the clearpart statement does nothing. Or else am I misunderstanding what clearpart does?
clearpart won't change the geometry detected by the kernel and having this mismatch can be problematic. Of course, the whole problem turns into something wildly different (see bug 115825) in 2.6.