Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 238100 - FC7T4: Error informing the kernel about modifications to partition
FC7T4: Error informing the kernel about modifications to partition
Product: Fedora
Classification: Fedora
Component: parted (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: David Cantrell
Brock Organ
: 235629 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2007-04-27 01:51 EDT by Jason Farrell
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-26 18:55:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
sfdisk partition layout (820 bytes, text/plain)
2007-04-27 01:53 EDT, Jason Farrell
no flags Details
pre-partitioned vmware image (8.41 KB, application/x-bzip)
2007-04-27 01:57 EDT, Jason Farrell
no flags Details

  None (edit)
Description Jason Farrell 2007-04-27 01:51:53 EDT
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
    # 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
Comment 1 Jason Farrell 2007-04-27 01:53:57 EDT
Created attachment 153579 [details]
sfdisk partition layout

sfdisk --force /dev/sda < suspect-partitions.sfdisk
Comment 2 Jason Farrell 2007-04-27 01:57:24 EDT
Created attachment 153580 [details]
pre-partitioned vmware image

pre-partitioned VMWare image to expedite testing.
(8.5KB tar.bz expands to 42M imagedir)
Comment 3 David Cantrell 2007-04-27 10:46:12 EDT
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.
Comment 4 David Cantrell 2007-05-04 15:21:36 EDT
*** Bug 235629 has been marked as a duplicate of this bug. ***
Comment 5 Jason Farrell 2007-05-26 02:47:21 EDT
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.
Comment 6 Jason Farrell 2007-05-31 16:47:31 EDT
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.
Comment 7 Thomas Canniot 2007-05-31 17:16:41 EDT
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.
Comment 8 Jason Farrell 2007-05-31 17:25:06 EDT
Clicking 'ignore' didn't help here. A reboot was unavoidable.
Comment 9 David Cantrell 2007-09-26 18:55:48 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.