Hide Forgot
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 signal 11. My configuration: AMD Athlon with 128 MB RAM and a Maxtor 91366U4 13GB disk, partition like this: 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 Bastiaan
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 flawlessly. Bastiaan
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 partitions. 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 well. 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 like: 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 problems.
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 graphical install. 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. HTH
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 mode.
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.