From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 Description of problem: Unlike fdisk, sfdisk, or and other disk partition manager I've seen, during the FC4 install process, when i select a manual install, if a disk appears to have an unknown partition table, disk druid immediately rewrites my partition table after asking if I want to do this. I realize this is somewhat of an edge case, but I've got windows installed on a silicon image sata raid controller. FC4 recognizes the individual disks, but not the raid volume. I added a new disk to install FC4, and from prior experience with FC2 thinking that my old disks weren't being recognized at all, click yes when asked about initializing the partition table on on /dev/sda. I immediately realized what I'd done when it asked about /dev/sdb, but the damage had been done. I REALLY don't think it's appropriate for disk druid or any partition manager to make ANY writes to the disk until the complete package has been confirmed. It goes against every other fdisk tool on the market and makes installing fc4 on anything but a pristine system a scary proposition even for a long time linux admin. In general, it is short sighted to assume that because you don't see a known partition table that the disk is new and can be written to. At the absolute minimum, the dialog should at LEAST say 'THIS WILL WRITE TO YOUR DISK IMMEDIATELY!' or something making it clear that unlike other fdisk operations there is no going back. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Click 'yes' to the 'are you sure you wish to initialize this disk' dialog in disk druid. Actual Results: My partition table was overwritten. Expected Results: I should have been sent to the disk druid screen where I could have quickly seen that indeed sda was NOT the disk i thought it was and clicked 'back' or rebooted the machine to avoid destroying my system. Additional info:
The dialog is pretty clear that it's going to blow everything away immediately. And we have to do it then as otherwise, we can't do accurate manipulations of the table that will be available.
1. I disagree it's clear. No other fdisk tool writes to the disk until you select a write option. 2. Without any physical disk information, being informed that /dev/sdxx is being blown away is useless information.