Description of problem:
Installation aborts when a disk with a pre-existing "bad" partition layout is
present, even if it's not an install target. The error occurs on the final step
before package installation: "Error informing the kernel about modifications to
partition /dev/sda5 - peripheral busy. This means Linux won't know about changes
you made to /dev/sda5 until you reboot - so you shouldn't mount it or use it in
any way before rebooting."
Version-Release number of selected component (if applicable):
F7T1 to present; FC6 and prior never complained about these old partition
tables. What's to blame? anaconda? parted? new libata?
Both on my hardware, and in VMWare, with a particular partition layout it
Steps to Reproduce:
1. Create a new VM in VMWare or other
2. Create a 125GB (sparse) virtual disk
3. Boot with a LiveCD containing the "sfdisk" util
4. partition the disk with the attached sfdisk layout (see next comment for
# sfdisk --force /dev/sda < suspect-partitions.sfdisk && sync
5. Reboot with the F7T4 installation media
6. Choose "Custom Layout" during installation and put "/" on sda2, and swap on sda5.
7. Continue default installation steps and notice it bombs after the dep check
Install aborts with above-mentioned error
Installation to ignore the error and continue
I temporarily zero'd out the MBR of the first drive that exhibited this bug only
to discover that I had a second drive with the same problem: a "bad" partition
layout which nothing complained about in the past.
A big clue is that sfdisk won't restore the partitions without the --force flag
because of complaints about partitions not starting at a *cylinder boundary*.
It's been a while, so I can't be certain WHAT utils I used to partition both
disks with; might have been a mix of fdisk, sfdisk, and parted. In any case, a
badly partitioned drive should not abort an installation - especially a drive
not being installed to.
I doubt this bug will be fixed in time for the F7 release next month, so maybe
F8 - in the meantime I'll have to resort to temporarily hiding the MBRs of both
drives before installation.
Related bug (CLOSED): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227343
Created attachment 153579 [details]
sfdisk partition layout
sfdisk --force /dev/sda < suspect-partitions.sfdisk
Created attachment 153580 [details]
pre-partitioned vmware image
pre-partitioned VMWare image to expedite testing.
(8.5KB tar.bz expands to 42M imagedir)
It's possible this is related to the the libata change, but I don't know. I'll
have to work on recreating this problem closely. Parted hasn't changed
significantly since FC6...just bug fixes. Anaconda is the same way. The only
major block device change has been libata.
The information you've provided is very useful. I'll get on this today and see
what I can find out. I really want this fixed in time for F7 because it's been
a problem that I hear about off and on, but I have never been able to recreate it.
*** Bug 235629 has been marked as a duplicate of this bug. ***
FWIW, I was not able to reproduce this bug (under VMware) using the most recent
rawhide F-7-i386-rescuecd.iso (5/26). Bodes well for F7 final.
Unfortunately this bug still prevented F7 installation on my actual hardware
(not sure why I can no longer reproduce it in VMware, though). The workaround to
get F7 installed was to backup then zero out the MBR's on both my old PATA
drives, before I could install to SATA s/w RAID:
dd if=/dev/hda of=/backup/hda-120G.mbr bs=512 count=1
dd if=/dev/hdd of=/backup/hdd-80G.mbr bs=512 count=1
No problems with the drives (now sdf & sdg) after the MBRs were restored
Hope this is an isolated case. Major headache.
On my laptop, I got the error message as useful, but clicking on "ignore" really
ignored the error and the installation went on. FC7 is then installed.
Clicking 'ignore' didn't help here. A reboot was unavoidable.
Just tried the provided sfdisk troublesome layout on rawhide and it's working
fine here. I don't get any error dialogs with Ignore as an option. It detects
the partition table and presents all of them in the custom partitioning UI.