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.
I'm changing this to an enhancement request - the bug poster has some good suggestions for how to handle this.
Agreed - apologies for not selecting the correct definition in the first place. If there's any further I can do to help, please let me know.
Changing to a kernel request.
Closing. Instead we switched to using volume labels which solves bigger problems too