Red Hat Bugzilla – Bug 10518
install and upgrade 6.1 -> 6.2 crash with signal 11
Last modified: 2008-05-01 11:37:55 EDT
I tried to perform an upgrade from 6.1 to 6.2 using a downloaded 6.2 copy
on partition /dev/hda8. The root partition is /dev/hda6. First I ran into
bug #10401 and worked around it by removing /dev/hda8 from /etc/fstab.
After the message 'finding packages to upgrade' the installer exits with
AMD Athlon with 128 MB RAM and a Maxtor 91366U4 13GB disk, partition like
Device Boot Start End Blocks Id System
/dev/hda1 * 1 267 2144646 b Win95 FAT32
/dev/hda2 268 1661 11197305 5 Extended
/dev/hda6 272 1055 6297448+ 83 Linux
/dev/hda7 1056 1088 265041 82 Linux swap
/dev/hda8 1089 1661 4602591 83 Linux
I tried an upgrade the same box via HTTP (after copying the files to a different
machine) and that failed too, at the the same point. However an HTTP upgrade of
6.1 to 6.2 of a Linux only VMWare 'machine' with a 2GB virtual disk went
Same crash with CDROM based upgrade, both text and GUI. In the latter case the
system simply hangs, no message.
BTW the goodby message is 'recieved signal 11'. I'm not a native English
speaker, but shouldn't that be 'received'?
I have a similar situation with my system - installer dies while copying the
packages or formatting the partitions:
Athlon 650 on Biostar M7MKA
128Mb PC100 SDRAM
IDE 20Gb IBM harddrive
The partition layout is similar: 2GB for Windoze (partition Id = c).
Also, I noticed that fdisk complains about overlapping partitions while the GUI
partitioner (druid?) accepts them.
Specifically, I have 2459 cylinders, and fdisk doesn't like partitions crossing
over the cylinders 1023-1024 and 2047-2048.
Could you include the partition table information as given by "fdisk -l"?
Here's the latest version of the partition table for my system:
Disk /tmp/hda : 255 heads, 63 sectors, 2495 cylinders
Units = cylinders of 1065 * 512 bytes
Device Boot Start End Blocks Id System
/tmp/hda1 * 1 255 2048256 c Win95 FAT32 (LBA)
/tmp/hda2 256 260 40162+ 83 Linux native
/tmp/hda3 261 293 265072+ 82 Linux swap
/tmp/hda4 294 2495 17687565 5 Extended
/tmp/hda5 294 326 265641 83 Linux native
/tmp/hda6 327 588 2104483+ 83 Linux native
/tmp/hda7 589 850 2104483+ 83 Linux native
/tmp/hda8 851 1023 1389591 83 Linux native
/tmp/hda9 1024 2047 8225248+ 83 Linux native
/tmp/hda10 2049 2495 3590527+ 83 Linux native
Right now I am running memtest-82 ver 2.2a on my PC, and there're no
memory errors so far after 20 minutes.
Could this be a problem because of my UDMA/66 7200rpm hard drive?
I am receiving the signal 11 when trying to install rh 6.2 from a cheapbytes
iso-image-based disc. It appears in the text mode right after saying Yes to
saving partition table changes. If I use graphical mode install, it just locks
up without showing any messages when I push the Next button after specifying the
I am also installing on a 7200rpm UDMA/66 hard disk, a 30gb Maxtor, 12gb of
which I've setting aside for the boot, root, and swap partition.
Tonight I cleaned hda8 and tried to do a fresh install on it. The graphical
install simply hung on hitting 'next' in Druid after having set hda8 root
partition. The text install crashed with signal 11 at the same point.
I really suspect the 1024 cylinder boundary here. Anyone got succesful
installs/upgrades with a root above cylinder 1024?
I can definitely believe that anyone installing to a UDMA/66 might see problems
during the installation, as UDMA/66 support in not built into the kernel and
therefore not built into the installation. Try connecting the drive to a DMA/33
interface for the purposes of the installation, then after the installation is
finished, you can recompile the kernel, adding support for the UDMA/66
controller and then return the drive to the UDMA/66 controller and all will be
Still trying to replicate the other problems reported in the lab.
Hmm, isn't UDMA66 supposed to be backward compatible with DMA33 and lower?
My drive and MB are UDMA66, but the installer/upgrader does read from drive
succesfully, else disk druid would not show my partition table nor would I have
run into bug #10401.
Jturner, is there is parameter that we can feed the installer to use the disk
in some older mode. I remember someone mentioning the linear
parameter with reference to larger scsi disks. I used to have scsi disks but
have abandoned them as they've died off in favor of the cheaper IDE disks.
What occurred with us might be related to this, so here we go..
We tried a blank install of RH62 on a system the partition table of which looked
hda1 2000 MB FAT (WinNT installed)
(hda2) 3600 MB empty space
hda5 3000 MB FAT
hda6 3000 MB FAT
... more partitions
(hda8) 3000 MB empty space
If I choose fdisk, the installer crashes with sig11 as told above.
Disk Druid didn't crash.
This is probably caused by one of the following:
1) empty HDD space between FAT partitions. The installer has been known to be
tricky about this in the past.
2) When Windows NT was first installed and partitions were created, the
installer used wrong mode in Bios (not LBA) and now lilo etc. all seem to think
that this partition is located too high sector-wise to be used. Ie. a glitch
so that BIOS thinks the partition is >1023 for root partition might cause
pekkas: random question, but what language are you performing the installation
in? This crash in fdisk but not in Disk Druid stuck in my mind and I am
wondering if the translations have anything to do with the crash you are seeing.
Last night I tried an install on the first partition (after backing up the
windows partition) in order to see whether a 1024 cylinder boundary was the
problem. The same symptoms occured: signal 11 with text install and a hang in
Has anyone at RedHat been able to reproduce this problem yet? Else, what can I
do to help resolve it?
*** Bug 11215 has been marked as a duplicate of this bug. ***bastiaan: Sorry about that. I have been working on this bug for about a week
and a half and know exactly what is wrong. Unfortunately I was not copying you
on the work that I was doing. Here is the problem. That "missing" logical
partition (hda5) is causing the problem. Partition Magic apparently has a bug
in some versions which leaves a null partition when the user deletes a logical
partition. As far as anyone at Red Hat can tell, this is not to standard and
therefore we never knew to look for this corner case. Either way, Red Hat is
currently trying to work with the Partition Magic folks and come up with a
workaround for this problem. More details to follow. I have indeed replicated
this behavior in the lab however.
jturner, thanks for your reply! I've succeeded in upgrading to 6.2 now! As a
workaround with fdisk I deleted all logical partitions and recreated them
starting with the missing hda5. Simply adding a logical partition containg the
free cylinders (268-271) did not work, because it resulted in the creation of
hda9 rather than hda5.
However is disagree that this is a Partition Magic bug: I do not use Parition
Magic at all, only fdisk and disk druid. I guess it is not that uncommon to see
a partition table with a hole in it. Anyway, a well behaving program should not
crash, but instead inform the user about the problem.
Ironically I created the 'hole' in order to get the upgrade working, I thought
that hda5 being the first linux partition but not the root partition might
confuse the installer.
jturner: we're using English installs only. However, when I said Disk Druid
worked, more precisely it didn't crash immediately after it was run. Because of
partitioning problems, I was unable to create a valid boot partition anyway, so
I don't know if it would have crashed in the end.
On empty partition problem: This AFAIK is not only problem with Partition
Magic. I fear Windows NT's fdisk can do some serious damage too; at least that
led into problems with us. Perhaps you should check if NT leaves some remnants
to the partition tables also.
Also consider the following (I hope I recall this correctly):
User creates partitions with Windows NT's fdisk:
hda1 xxx MB
hda2 yyy MB
(Alternative scenario: hda1, hda2, and hda3 are created and hda2 is deleted.
The installer seems to break)
User goes to Windows fdisk, deletes hda2, and reboots to install RH Linux.
User creates a new primary partition. IIRC the installer assigns this
hda2 but it really goes to hda3; NT leaves some dredges to partition table.
Everything works fine until after reboot. Then partition is detected as hda3.
Funnies will happen because of mismatching entries in /etc/fstab.
I hope I remembered the case correctly; it has been a long time. This was a
problem at least in RH60.
A partition table that triggers the bug can be created with Linux fdisk by
creating hda1, hda5, hda6, etc. and then changing the partition type to 0
(empty). fdisk issues a big fat warning that most other OS'es treat type 0 as
empty but that Linux does not (treat it as empty). Ironically, fdisk does not
allow you to change the partition type back again, complaining that the
partition does not exist yet....
As stated before, to reenable the partition that's marked zero, delete all
partitions after it and recreate them in low to high order.
PS. can the bug status be promoted to VERIFIED or ASSIGNED?
I had the same lockup with the GUI installer while performing a clean 6.2 install to device hdc when there were "holes" on hda.
Used Partition Magic to resize the non-empty partitions to fill in the holes on hda. After doing this, the install worked fine.
Bugs me that to install 6.2 on a blank hard disk, I had to fiddle with partitions on my primary disk.
Can anyone on this bug report comment on if this issue exists with RH 6.2 or
7.0? We probably should have an exception if the partition table has an invalid
state as described, but this is the only report we've received with this failure
Sorry, I don't have a box I can test this on right now. When I have one, I'll
let you know the results as soon as I have them. It might take a while though.
Please reopen this report if you have any new information to add.