Description of problem:
The old "Error informing the kernel about modifications to partition" bug is
still with us.
I have no invalid partitioning, but I did in at least some cases partition using
parted at the shell (virtual console 2) during the install. I have encountered
this error even after rebooting and making no further changes to partitioning.
It does seem to be a bit flaky - if I try again enough times it will work, but
sometimes that's quite a few times.
Version-Release number of selected component (if applicable):
whatever is in the Fedora 7 release.
easier to reproduce than to avoid. :-(
Steps to Reproduce:
1. start installation
2. once able, Ctrl-Alt-F2.
3. run parted
4. create partitions
5. optionally reboot
6. optionally verify with fdisk (including expert mode) that all is kosher,
aside from partitions ending not on cylinder boundaries (not that there's
anything wrong with that).
7. proceed with installation.
8. experience frustration (akin to that of dealing with Microsoft) when after
the 6th time of carefully tweaking package selections, the silly thing dies due
to this bug.
installer begins installing rpms
installer complains because an ADD_PARTITION ioctl in the parted library got EBUSY
See also bugs 160693 and 238100 (and lots of their friends).
In my particular case, I encountered this error on various Core 2 Duo systems
(QX6700, X6300), with 160GB and 500GB drives, installing x86 and x86_64 Fedora 7
(from the official release ISO's, sha1sum checked and media checked).
oops, swap the actual & expected results.
Workaround: a co-worker discovered that clicking the Cancel option (in the
dialog that anaconda pops up) consistently allows the install to continue and
everything works fine. We have several machines now deployed on which he did
this and they are fine.
But please still fix the bug. At a glance, it looked to me like the kernel side
of the ioctl is not expecting to get an ADD_PARTITION for a partition it already
knows about (or one that appears to overlap). So, if so, that would mean the
bug is in either the parted library or anaconda - not clear to me where without
a more detailed analysis of the code on both sides.
Can you give me more details about your disk layout? libparted does not like
overlapping partitions, but if you used parted to create the disk layout, it
would prevent this. Anaconda also prevents this since it uses parted as well.
But I need more details on _what_ partitioning scheme you created on the disk.
Any existing partitions? What partitions? Boundaries? Etc, etc, etc.
Created attachment 161676 [details]
Kickstart file used to repro the problem
Created attachment 161677 [details]
Dump of resulting partition info (via fdisk & parted)
I've attached the kickstart file I used (edited only to remove the encrypted
root password), and a dump of the resulting partition table (via both fdisk and
parted). I can supply other info if it would be helpful - just tell me what you
I need to know what partition layout is on the disk prior to installation. I
see you've modified the kickstart file to not use anaconda's partitioning
system, but instead are execing parted directly from the pre environment. I
need a little more explanation as to what you're trying to accomplish so I can
try to reproduce it here locally.
We've used that kickstart file for a bunch of Dells we've gotten in recently.
They come with two partitions: one small (maybe FAT32) diagnostic partition, and
the rest of the 500GB as one big NTFS partition with Windows on it. (I can
provide details when the next one shows up - should be in the next couple of
days. Let me know if you want the details.)
However, we observed this problem even when we partitioned the disk and then
rebooted and did the install with NO partition changes at all, and various other
cases with different partitioning schemes in place at the start of the install.
I would expect you could repro it simply by using that kickstart file on any
disk that doesn't have an sda8. Has it not worked for you?
As to why I'm using parted for the partitioning rather than anaconda: my
experience with anaconda and partitioning has consistently (since RH7) been that
when I try to create my partitions with a particular layout, I get 3 or 4
partitions in and it starts rearranging them to suit its idea of how things
should be. I want to control the exact order in which the partitions appear,
and I have found that impossible to do interactively in anaconda. So when I
wrote the kickstart file, I assumed I would have the same problem with
non-interactive anaconda partitioning, and I went straight to scripting parted
(which turned out to be a pain because it refuses to accept more than one
command at a time, despite refusing to produce any sort of error message - arrrrgh).
It would be really great if anaconda grew an option (checkbox in the gui and
--option for kickstart) to allocate the disk space exactly as told to and never,
EVER rearrange the order of the partitions. But in the meantime, I have my
little parted script.
However, none of that should really matter. If the machine has just been booted
up, and an install is started, and the partitioning is not changed, it doesn't
(shouldn't) matter whether the partitions were created by parted, or fdisk, or a
previous run of anaconda. Why is anaconda doing something to cause the error in
question when I haven't even asked it to touch the partition table at all, and
in fact the partition table hasn't changed since booting?
(In reply to comment #8)
> We've used that kickstart file for a bunch of Dells we've gotten in recently.
> They come with two partitions: one small (maybe FAT32) diagnostic partition, and
> the rest of the 500GB as one big NTFS partition with Windows on it. (I can
> provide details when the next one shows up - should be in the next couple of
> days. Let me know if you want the details.)
Yes, the starting and ending points of the default Dell-provided partitions as
well as the types (the type code as indicated in fdisk).
> However, we observed this problem even when we partitioned the disk and then
> rebooted and did the install with NO partition changes at all, and various other
> cases with different partitioning schemes in place at the start of the install.
Which makes sense to me. If you still have the factory partitioning layout, I
think that's the source of the problem here.
> I would expect you could repro it simply by using that kickstart file on any
> disk that doesn't have an sda8. Has it not worked for you?
No, because I don't have the existing partitioning layout as provided by Dell.
Whatever they are using to partition is aligning things differently. This is
very likely a bug in parted -or- a bug in their provisioning tool. I run in to
issues like this all the time. I am also the upstream GNU parted maintainer as
well as the package maintainer for Fedora.
> As to why I'm using parted for the partitioning rather than anaconda: my
> experience with anaconda and partitioning has consistently (since RH7) been that
> when I try to create my partitions with a particular layout, I get 3 or 4
> partitions in and it starts rearranging them to suit its idea of how things
> should be. I want to control the exact order in which the partitions appear,
> and I have found that impossible to do interactively in anaconda. So when I
> wrote the kickstart file, I assumed I would have the same problem with
> non-interactive anaconda partitioning, and I went straight to scripting parted
> (which turned out to be a pain because it refuses to accept more than one
> command at a time, despite refusing to produce any sort of error message -
Understandable. I only brought it up because sometimes people are using parted
(or worse, sfdisk) to create a disk layout, but are doing it incorrectly and
refuse to adjust their commands. Your case makes sense. What we [the anaconda
team] want to do is make the anaconda partitioning commands be flexible enough
so you don't need to bypass them and use your own tool.
The main reason anaconda partitions the way it does is to make disk label
differences transparent to users. If someone wants 5 partitions, we don't want
to present them with complexities of needing an extended partition and logical
drives...but only on msdos labeled disks. We try to hide that from users as
much as possible.
> It would be really great if anaconda grew an option (checkbox in the gui and
> --option for kickstart) to allocate the disk space exactly as told to and never,
> EVER rearrange the order of the partitions. But in the meantime, I have my
> little parted script.
Chris Lumens is the kickstart guy (wrote pykickstart) and is always looking for
ideas to improve it or expand it. I can point you at the documentation:
But if you find a failing, file an RFE and he'll probably get it in. File it
against pykickstart rather than anaconda.
> However, none of that should really matter. If the machine has just been booted
> up, and an install is started, and the partitioning is not changed, it doesn't
> (shouldn't) matter whether the partitions were created by parted, or fdisk, or a
> previous run of anaconda. Why is anaconda doing something to cause the error in
> question when I haven't even asked it to touch the partition table at all, and
> in fact the partition table hasn't changed since booting?
anaconda really isn't at fault here, it's libparted. Anaconda uses parted for
partitioning and if it has problems reading the label, anaconda will. I want to
get to the bottom of it, but I need to know what the disks look like from the
Sorry for the delay - had to wait for a fresh one to be delivered. I'll keep it
pristine until you have enough info (within the next few days, I hope).
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 7 56196 de Dell Utility
/dev/sda2 8 60800 488319772+ 7 HPFS/NTFS
Disk /dev/sda: 255 heads, 63 sectors, 60801 cylinders
Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID
1 80 1 1 0 254 63 6 63 112392 de
2 00 0 1 7 254 63 1023 112455 976639545 07
3 00 0 0 0 0 0 0 0 0 00
4 00 0 0 0 0 0 0 0 0 00
0x000: 33 C0 8E D0 BC 00 7C FB 50 07 50 1F FC BE 1B 7C
0x010: BF 1B 06 50 57 B9 E5 01 F3 A4 CB BD BE 07 B1 04
0x020: 38 6E 00 7C 09 75 13 83 C5 10 E2 F4 CD 18 8B F5
0x030: 83 C6 10 49 74 19 38 2C 74 F6 A0 B5 07 B4 07 8B
0x040: F0 AC 3C 00 74 FC BB 07 00 B4 0E CD 10 EB F2 88
0x050: 4E 10 E8 46 00 73 2A FE 46 10 80 7E 04 0B 74 0B
0x060: 80 7E 04 0C 74 05 A0 B6 07 75 D2 80 46 02 06 83
0x070: 46 08 06 83 56 0A 00 E8 21 00 73 05 A0 B6 07 EB
0x080: BC 81 3E FE 7D 55 AA 74 0B 80 7E 10 00 74 C8 A0
0x090: B7 07 EB A9 8B FC 1E 57 8B F5 CB BF 05 00 8A 56
0x0A0: 00 B4 08 CD 13 72 23 8A C1 24 3F 98 8A DE 8A FC
0x0B0: 43 F7 E3 8B D1 86 D6 B1 06 D2 EE 42 F7 E2 39 56
0x0C0: 0A 77 23 72 05 39 46 08 73 1C B8 01 02 BB 00 7C
0x0D0: 8B 4E 02 8B 56 00 CD 13 73 51 4F 74 4E 32 E4 8A
0x0E0: 56 00 CD 13 EB E4 8A 56 00 60 BB AA 55 B4 41 CD
0x0F0: 13 72 36 81 FB 55 AA 75 30 F6 C1 01 74 2B 61 60
0x100: 6A 00 6A 00 FF 76 0A FF 76 08 6A 00 68 00 7C 6A
0x110: 01 6A 10 B4 42 8B F4 CD 13 61 61 73 0E 4F 74 0B
0x120: 32 E4 8A 56 00 CD 13 EB D6 61 F9 C3 49 6E 76 61
0x130: 6C 69 64 20 70 61 72 74 69 74 69 6F 6E 20 74 61
0x140: 62 6C 65 00 45 72 72 6F 72 20 6C 6F 61 64 69 6E
0x150: 67 20 6F 70 65 72 61 74 69 6E 67 20 73 79 73 74
0x160: 65 6D 00 4D 69 73 73 69 6E 67 20 6F 70 65 72 61
0x170: 74 69 6E 67 20 73 79 73 74 65 6D 00 00 00 00 00
0x180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1B0: 00 00 00 00 00 2C 44 63 16 23 AB 41 00 00 80 01
0x1C0: 01 00 DE FE 3F 06 3F 00 00 00 08 B7 01 00 00 00
0x1D0: 01 07 07 FE FF FF 47 B7 01 00 39 56 36 3A 00 00
0x1E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
Model: ATA ST3500630AS (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32.3kB 57.6MB 57.5MB primary fat16 boot
2 57.6MB 500GB 500GB primary ntfs
It would be helpful if you could confirm whether or not you need (or might need)
additional info on this disk - I've been postponing configuring the box in case
you need me to gather more info, but I would like to be able to actually USE the
Also, this problem has been observed (using a similar but not identical
kickstart) on a machine previously partitioned and running FC5.
Created attachment 212961 [details]
Complete contents of the dell partition, sda1 (pops up the license screen when you boot), compressed
Created attachment 212971 [details]
The boot block of the drive (first 512 bytes of /dev/sda)
Created attachment 212981 [details]
The first 2 MB of /dev/sda
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.
Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I tried to use the files that were posted with no consistent results:
[root@dhcp-lab-115 Misc]# parted first512 print
Error: Can't have a partition outside the disk!
[root@dhcp-lab-115 Misc]# fdisk first512 -l
[root@dhcp-lab-115 Misc]# sfdisk first512 -l
Disk first512: cannot get geometry
Disk first512: 0 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System
first512p1 * 0+ 6 7- 56196 de Dell Utility
first512p2 7 60799 60793 488319772+ 7 HPFS/NTFS
first512p3 0 - 0 0 0 Empty
first512p4 0 - 0 0 0 Empty
[root@dhcp-lab-115 Misc]# parted first2048 print
Error: Unable to open /home/joel/Misc/first2048 - unrecognised disk label.
[root@dhcp-lab-115 Misc]# fdisk first2048 -l
Disk first2048: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xbd996bef
Disk first2048 doesn't contain a valid partition table
[root@dhcp-lab-115 Misc]# sfdisk first2048 -l
Disk first2048: cannot get geometry
Disk first2048: 0 cylinders, 255 heads, 63 sectors/track
sfdisk: ERROR: sector 0 does not have an msdos signature
first2048: unrecognized partition table type
No partitions found
Additionally I took 512 bytes from the (id=212981) file and compared it to the
(id=212971) file, surprisingly they were different. what command did you use to
generate these files? did you use dd?
I'm going to try to modify parted so it can show me what its seeing (have some
debugging code), If that does not work, I have already arranged for the lab
manager to tell me when new dell machines arrive so I can test on the "virging"
disks. It would really help if you can specify the dell machine.
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008.
Fedora 7 is no longer maintained, which means that it will not
receive any further security or bug fix updates. As a result we
are closing this bug.
If you can reproduce this bug against a currently maintained version
of Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.