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
kernel bug
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.