Bug 18709

Summary: RFE: Improve behavior when Unixware slices exist
Product: [Retired] Red Hat Linux Reporter: Need Real Name <stu>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED CURRENTRELEASE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: low    
Version: 8.0Keywords: FutureFeature
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-06-09 17:21:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Need Real Name 2000-10-09 13:37:42 UTC
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.

Comment 1 Michael Fulbright 2000-10-09 14:43:55 UTC
I'm changing this to an enhancement request - the bug poster has some good
suggestions for how to handle this.

Comment 2 Need Real Name 2000-10-09 15:12:26 UTC
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.

Comment 3 Michael Fulbright 2001-09-18 16:00:09 UTC
Changing to a kernel request.

Comment 4 Alan Cox 2003-06-09 17:21:33 UTC
Closing. Instead we switched to using volume labels which solves bigger problems too