Bug 238100 - FC7T4: Error informing the kernel about modifications to partition
Summary: FC7T4: Error informing the kernel about modifications to partition
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: parted (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
high
Target Milestone: ---
Assignee: David Cantrell
QA Contact: Brock Organ
URL:
Whiteboard:
Keywords:
: 235629 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-04-27 05:51 UTC by Jason Farrell
Modified: 2007-11-30 22:12 UTC (History)
2 users (show)

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: ---


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

Description Jason Farrell 2007-04-27 05:51:53 UTC
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

Comment 1 Jason Farrell 2007-04-27 05:53:57 UTC
Created attachment 153579 [details]
sfdisk partition layout

sfdisk --force /dev/sda < suspect-partitions.sfdisk

Comment 2 Jason Farrell 2007-04-27 05:57:24 UTC
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 14:46:12 UTC
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 19:21:36 UTC
*** Bug 235629 has been marked as a duplicate of this bug. ***

Comment 5 Jason Farrell 2007-05-26 06:47:21 UTC
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 20:47:31 UTC
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.

Comment 7 Thomas Canniot 2007-05-31 21:16:41 UTC
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 21:25:06 UTC
Clicking 'ignore' didn't help here. A reboot was unavoidable.

Comment 9 David Cantrell 2007-09-26 22:55:48 UTC
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.