Bug 18709

Firstly, this bug is not entirely the fault of RH, but more of how linux 
copes with slices. However, RH may be able to provide a work around or may 
wish to place appropriate comments in installation docs.

HDA is partitioned thus:
hda1 System Utilities
hda2 SysV (Contains unixware 7)
hda3 NTFS
hda4 extended
hda5 linux
hda6 linux swap
hda7 win95 fat 32

Redhat installer correctly identifies the hda5 partition as suitable for 
installation and completes a normal install. In /etc/lilo.conf, install 
puts the root fs as /dev/hda5 which, again, would seem quite normal.

On reboot however, linux panics as it cannot mount the root FS.

The reason for this is that the running kernel has identified that there 
are slices in hda2 and so renumbers the partitions accordingly:

hda: hda1 hda2 <unixware: hda5 hda6 hda7 hda8 hda9> hda3 hda4 <hda10 hda11 
hda12>

As a result, the partition specified as the root is now actually a 
unixware partition. 

The resolution to this is to boot again and specify the correct partition 
on the command line (i.e. CTRL+X   linux root=/dev/hda11) then to 
modify /etc/lilo.conf and rerun lilo.

At this stage, I have three suggestions for RedHat. 
1. Removal of unixware support from their default kernel (it is, after 
all, a relatively niche requirement)
2. Use the appropriate tool (prtvtoc?) at install time to probe SysV 
partitions and guess what the correct partition number to use will be.
3. Document it. Obviously if the linux partitions are earlier than the 
unixware ones, this problem should not occur, but it may be of use to 
people to see this situation documented in the install-guide.

As an aside, I think this method of assigning partition numbers to slices 
is inappropriate; there should be a seperate virtual device for these as 
the current system means that this kind of error will be commonplace.