Bug 20131 - Upgrade installation fails (Signal 11?)
Summary: Upgrade installation fails (Signal 11?)
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: installer
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Brock Organ
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2000-11-01 04:39 UTC by kthorn01
Modified: 2005-10-31 22:00 UTC (History)
0 users

Clone Of:
Last Closed: 2000-11-06 21:47:56 UTC

Attachments (Terms of Use)

Description kthorn01 2000-11-01 04:39:12 UTC
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

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.

Comment 1 Michael Fulbright 2000-11-03 20:14:29 UTC
Passed to QA to reproduce.

Comment 2 Brock Organ 2000-11-06 21:45:20 UTC
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

% 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!

Comment 3 Brock Organ 2000-11-06 21:47:53 UTC
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!

Note You need to log in before you can comment on or make changes to this bug.