Bug 238100
| Summary: | FC7T4: Error informing the kernel about modifications to partition | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jason Farrell <farrellj> | ||||||
| Component: | parted | Assignee: | David Cantrell <dcantrell> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Brock Organ <borgan> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | rawhide | CC: | thomas.canniot, tuan88 | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2007-09-26 22:55:48 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
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 post-install. 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. |
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? How reproducible: Both on my hardware, and in VMWare, with a particular partition layout it doesn't like. 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 attachment) # 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 Actual results: Install aborts with above-mentioned error Expected results: Installation to ignore the error and continue Additional info: 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