Dell Dimension XPS T450 (128MB RAM) running Red Hat Linux 6.0 in perfect health. I'm trying to *upgrade* it to 7.0. After boot disk or CD boot (I tried both), I can go through the menu to Fig A-2 (page 109 of the installation manual). There, I either choose to or not to customize packages. When I hit next, it searches for old installation, then the computer simply reboots. I also tried the text mode, and got similar results. I already use the anaconda patch. Graphic installer does not report any error, while text installer reports Signal 11 and halts. The messages on consoles that I could write down were: console 1 (F1): (normal message) SetMouse Settings Succeeded sending termination signals...done sending kill signals...done disabling swap... unmounting filesystems (etc... reboot) console 2 (F2): just have Sh-2.04 prompt. console 3 (F3): (last line only, no error): Anaconda floppy device is fd0 console 4 (F4) (last line only, no error): Raid 5 personality registered I bought the box set, so I contacted technical support, but they have been no help finding a work around and suggested I report it to bugzilla. They do believe that the way I set up the partition table is the problem and the only suggestions they made are to repartition the disk (which I cannot do right now) or abandon upgrade. Here are the partition table and file system information. Disk /dev/hda: 255 heads, 63 sectors, 2489 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 471 3783276 b Win95 FAT32 /dev/hda2 472 516 361462+ 83 Linux /dev/hda3 517 2489 15848122+ f Win95 Ext'd (LBA) /dev/hda5 517 1024 4080478+ 83 Linux /dev/hda6 1025 1041 136521 82 Linux swap /dev/hda7 1042 1297 2056288+ 83 Linux /dev/hda8 1298 1914 4956021 83 Linux /dev/hda9 1915 2489 4618656 83 Linux Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda2 349896 61176 270647 18% / /dev/hda8 4787830 2748295 1791734 61% /home /dev/hda7 1988924 1107776 778334 59% /usr /dev/hda5 3943252 2545928 1193301 68% /home1 /dev/hda9 4462427 13 4231482 0% /home2 Does the upgrade use a program which does not recognize an extended partition of type 0f to set mount point? If so, would the easiest work around be to try to install 7.0 using custom install so that I can keep /home, etc. where I don't want to lose data (that's possible, right)? Or does the installer (however method you use) lack the ability to recognize the extended partition of type 0f (which is what technical support tells me). Funny thing is that I had no problem with this when I installed 6.0 (that is, Disk Druid or whatever I was using to set mount points was able to see the partition just fine). The technical support person believes that the previous installation should not have worked. She didn't seem to have a problem with the fact that /usr was separated from / (and together, there should be enough space for 7.0, I think). If I must use type 05 extended partition, is there any way I can just convert 0f to 05 *non-distructively* if I shrink the current extended partition (~16GB) to under the limit for type 05 (8GB, as I understand)? Does this have anything in common with bug #19405 or #18024? Since upgrade is more automatic, I do not know what mount points are set. Any help you can provide is appreciated.
Passed to QA to reproduce.
Using generic test lab equipment (NOT a Dell Dimension as you have), I was unable to: 1) Install 6.0 with the extended partition of type 'f' 2) Reproduce your traceback upgrading to 7.0 so here is what I did ... I installed a minimal 6.0 to a partition table like yours using the regular extended type '5' ... and then post-install changed the extended type to 'f' using fdisk ... I was able to reboot into the install and list the partition contents: % df -h Filesystem Size Used Avail Use% Mounted on /dev/hda2 486M 46M 415M 10% / /dev/hda5 15M 13k 14M 1% /home /dev/hda8 15M 13k 14M 1% /home2 /dev/hda9 15M 13k 14M 1% /home3 /dev/hda7 972M 143M 778M 16% /usr % fdisk -l /dev/hda Disk /dev/hda: 255 heads, 63 sectors, 787 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/hda1 1 3 24066 b Win95 FAT32 /dev/hda2 4 67 514080 83 Linux /dev/hda3 68 787 5783400 f Win95 Ext'd (LBA) /dev/hda5 68 69 16033+ 83 Linux /dev/hda6 70 78 72261 82 Linux swap /dev/hda7 79 206 1028128+ 83 Linux /dev/hda8 207 208 16033+ 83 Linux /dev/hda9 209 210 16033+ 83 Linux Now, upgrading to 7.0 (I used text mode) went without any problems with /dev/hda3 being type 'f' ... was able to reboot and post-install w/out any issues ... > If I must use type 05 extended partition, is there any way I > can just convert 0f to 05 *non-distructively* You can change the partition type from 'f' to '5' using fdisk (after all important data has been backed up! :) ) ... thanks for your report!
This upgrade failure may occur for a reason other than the 'f' vs '5' extended partition type issue ... please reopen this if changing the partition type from 'f' to '5' still fails in the upgrade for a different reason!