Bug 52073 - Serious device name confusion with Promise IDE card
Serious device name confusion with Promise IDE card
Status: CLOSED RAWHIDE
Product: Red Hat Public Beta
Classification: Retired
Component: anaconda (Show other bugs)
roswell
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jeremy Katz
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-20 06:30 EDT by Bevis King
Modified: 2007-04-18 12:36 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-08-22 13:59:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bevis King 2001-08-20 06:30:22 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (X11; U; Linux 2.4.2 i686)

Description of problem:
Installation of lilo completely fails to update MBR (grub also fails) when
run from anaconda on machine with Promise IDE card.

The kernel included with Roswell (2.4.6) for the first time includes
support for the Promise IDE UDMA100 controller card.  This card adds four
additional IDE devices to the conventional compilment of four on a standard
PC motherboard.  The core of the problem is that the promise controller's
four possible disc slots are allocated device names hda->hdd making the
first of the motherboard discs hde (with the rest hdf->hdh respectively). 
This means that the boot disc for the system, IDE0 Master device becomes
/dev/hde once the kernel has booted.  This invalidates the swap entry in
the /etc/fstab also, but fortunately not most of the other discs which do
work due to the recent convention of using filesystem labels rather than
actual device names.  The lilo install run by anaconda fails to write the
necessary entries to the correct IDE drive, and when the machine reboots it
finds whatever was previously on the IDE0 system disc.

The key issue here is that within lilo's view of the device tree, the IDE0
Master on the motherboard has to be /dev/hda1, but once the 2.4.6 kernel
has booted, the IDE0 Master drive becomes /dev/hde1.

This problem can be averted as follows:

	1.  Remove Promise UDMA 100 card
	2.  Install onto IDE0 Master system disc
	3.  Edit /etc/lilo.conf - leave entries for
	    /dev/hda and /dev/hda1 as they are - add an
            append="root=/dev/hde1" to the kernel options
	4.  Edit /etc/fstab to have /dev/hde3 (or whatever)
            as swap.
        5.  Re-run lilo
	6.  Halt machine
	7.  Reinstall Promise UDMA100 card
	8.  Boot Roswell


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
Attempt a normal installation onto a machine with IDE0 Master set at the
boot disc but which contains a Promise UDMA100 IDE controller card.	This is
probably a fairly normal PC hardware server configuration, certainly very
common on machines used for Digital Video editing.

Actual Results:  Machine booted with the previously installed kernel
(2.2.18 from 7.0) because lilo had failed to update the MBR.  This was a
re-install.  Would not have booted at all, or would have gone into whatever
previous OS had been installed.

Expected Results:  OK, that's a hard one.  Either the Linux Kernel needs to
be changed to not remap the Promise controller to hda->hdd, and thus
causing the motherboard IDE controller to be numbered (lettered) from hde
upwards, or lilo needs to be updated to understand that the devices will
get remapped by the kernel when it boots.  As detailed above, there is a
workaround involving removing the card but it isn't ideal and is certainly
not for beginners.  This is a tough problem.

Additional info:

The machine concerned is:

	AMD Athlon 800
	256MB RAM
	20GB IDE0 system disc
	40GB UDMA100 disc on Promise Controller (used for Digital Video)

Machine is dual boot Roswell/WinME.  Partition table (now) is:

/dev/hda1    40GB    40GB    VFAT     /video/one

/dev/hde1    20GB    100MB   ext2     /
/dev/hde2            3.2GB   VFAT     /WinME
/dev/hde3            2GB     swap     swap
/dev/hde4            Extended
/dev/hde5            2GB     ext2     /usr
/dev/hde6            300MB   ext2     /var
/dev/hde7            4GB     ext2     /opt
/dev/hde8            500MB   ext2     /tmp
/dev/hde9            6GB     ext3     /vol/yakut/video
Comment 1 Arjan van de Ven 2001-08-20 07:26:33 EDT
kernel bug
Comment 2 Glen Foster 2001-08-20 14:57:06 EDT
Changing component to anaconda, per Bill N's request.
Comment 3 Glen Foster 2001-08-20 15:22:54 EDT
We (Red Hat) should really try to fix this before next release.
Comment 4 Jeremy Katz 2001-08-23 15:26:47 EDT
Actually, kernel problem and Arjan says that it should be fixed in newer kernels
(2.4.7-2.7 or later) so that the drive ordering matches.  Thanks for the report.

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