Bug 18709 - RFE: Improve behavior when Unixware slices exist
RFE: Improve behavior when Unixware slices exist
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2000-10-09 09:37 EDT by Need Real Name
Modified: 2007-03-26 23:36 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-09 13:21:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2000-10-09 09:37:42 EDT
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 

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 10:43:55 EDT
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 11:12:26 EDT
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 12:00:09 EDT
Changing to a kernel request.
Comment 4 Alan Cox 2003-06-09 13:21:33 EDT
Closing. Instead we switched to using volume labels which solves bigger problems too

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