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)
5. Re-run lilo
6. Halt machine
7. Reinstall Promise UDMA100 card
8. Boot Roswell
Version-Release number of selected component (if applicable):
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.
The machine concerned is:
AMD Athlon 800
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/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
Changing component to anaconda, per Bill N's request.
We (Red Hat) should really try to fix this before next release.
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.