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. How reproducible: 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. Actual results: installer begins installing rpms Expected results: installer complains because an ADD_PARTITION ioctl in the parted library got EBUSY Additional info: 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 need.
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 - arrrrgh). 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: http://fedoraproject.org/wiki/AnacondaKickstart 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 factory. Thanks.
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). fdisk says: 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 Device: /dev/sda 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 parted says: 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 box... 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: http://docs.fedoraproject.org/release-notes/ 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]# [root@dhcp-lab-115 Misc]# fdisk first512 -l [root@dhcp-lab-115 Misc]# [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]# [root@dhcp-lab-115 Misc]# parted first2048 print Error: Unable to open /home/joel/Misc/first2048 - unrecognised disk label. [root@dhcp-lab-115 Misc]# [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]# [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 [root@dhcp-lab-115 Misc]# 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. thx
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.