Red Hat Bugzilla – Bug 161086
Crashes, because of partition sda16 not correct
Last modified: 2008-02-16 19:47:16 EST
From Bugzilla Helper:
User-Agent: Opera/8.0 (X11; Linux i686; U; de)
Description of problem:
Installing target was hda no partition on sda was affected.
Instead of this the installation crashed with a error message referring sda16.
anacdump.txt was created.
After deleting sda16 the installation succeeds.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Created attachment 115690 [details]
Does it work if you immediately try reinstalling?
(In reply to comment #2)
> Does it work if you immediately try reinstalling?
I tried it 4 times only changing packet choice. The installation stops every
time in the same manner.
Then I have deleted the partition sda16 and the installation succeeds.
The kernel only supports up to 15 partitions on SCSI disks.
But it is not very friendly (;-) to stop the installation.
Remember: the disk sda is not used!
I think this is a bug.
Created attachment 119054 [details]
anaconda crash dump complaining of SATA sda17 partition
I ran into the same bug on x86_64 (AMD64). I was trying to install on a SATA
drive with sda2 as swap and sda5 as /. Anaconda does not need to touch any
other parition, but at the point of commiting to the install, it complained
about sda17, crashed and rebooted the system.
In the next install attempt, I noticed that the FC4 installer didn't have
device nodes /dev/sda16 and /dev/sda17, so I created those in a virtual
terminal, but it didn't help. (Maybe device node /dev/sda15 was also missing
and this attempt failed because I didn't create it?)
Next, I deleted partitions /dev/sda15 (probably not necessary), /dev/sda16 and
/dev/sda17, since the FC4 installer didn't create the corresponding device
nodes in my previous attempt. The install completed successfully this time.
Rather than crashing and rebooting, anaconda should ignore partitions it will
not touch as part of the installation.
The kernel should support 63 SATA partitions just as it supports 63 (P)ATA
Another bug I noticed was FC4 fdisk ignores partitions 16 and above on a SATA
drive, but the x86 Knoppix 3.9 fdisk has no problem displaying and creating
partitions above 15.
Just because Linux may have an upper limit of 15 partitions on a SATA drive does
not mean that FC4 anaconda should enforce this limit on other operating systems
(Non-Linux) that may handle more than 15 partitions per SATA drive.
Even assuming no operating system can access a filesystem on a SATA drive
partition 16 or greater, these partitions can still be used for non-FS data and
the backup of filesystems.
Thus both the Linux kernel and anaconda must at a _minimum_ ignore SATA
partitions greater than 15. (Based on this bug report [specifically comment #6
thereof], it is clear that anaconda does not ignore SATA partitions greater than
The Linux kernel and anaconda should both properly handle 63 SATA partitions,
just as they properly handle 63 (P)ATA partitions.
Created attachment 120345 [details]
Ungraceful, unnecessary crash
Both FC3 & FC4 Installation terminate with:
"Error informing the kernel about modifications to partition /dev/sda16 -
Invalid argument. This means that Linux won't know about any changes you made
to /dev/sda16 until you reboot, so you shouldn't mount it or use it in any way
Clicking 'Cancel' or 'Ignore' results in an ungracious exit! SDA16 is a
Windows partition and should be ignored by Linux installation.
This on a 'HW' RAID 1 drive (120G) using Silicon Image driver for the SIL3112
chipset. Current drive partition layout
1 = fat32, Win XP - SDA1, primary
2 = fat32, Spare
3 = ext2, Linux /boot - SDA6
4 = ext2, Linux / - SDA7
5 = Linux swap - SDA8
6 = fat32, XP - SDA9
7 = fat32, Win 2000 - SDA10
8 = fat32, Win 2000 - SDA11
9 = fat32, Data - SDA12
10 = fat32, Spare - SDA13
11 = fat32, Win98 - SDA14
12 = fat32, Spare - SDA15
13 = fat32, Spare - SDA16
14 = Unallocated space
This report targets the FC3 or FC4 products, which have now been EOL'd.
Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?
Fedora Core 4 is no longer maintained.
Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release, please reopen this bug and assign it to the
corresponding Fedora version.