Bug 43324 - Please update to latest LILO, RH7.1 version doesn't handle many IDE controllers properly
Summary: Please update to latest LILO, RH7.1 version doesn't handle many IDE controlle...
Keywords:
Status: CLOSED DUPLICATE of bug 39365
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: lilo
Version: 7.1
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-06-03 07:11 UTC by Dax Kelson
Modified: 2007-04-18 16:33 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-10-04 19:12:07 UTC
Embargoed:


Attachments (Terms of Use)

Description Dax Kelson 2001-06-03 07:11:44 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9+)
Gecko/20010531

Description of problem:
I have a Soyo IV 440BX motherboard.  It has onboard HighPoint 366 Ultra66
controler.  I have also added a Promise Ultra100 PCI controller. The
version of LILO included with RH7.1 doesn't work with my hard drives
plugged into the Promise controller.  I upgraded to the latest official
LILO 21.7.5 and everything works fine.

This is what the kernel sees as far as IDE controller hardware (notes on
the side are mine).  Everything is correct:

/dev/hda  - Standard 440BX Ultra33 controller (master)
/dev/hdb  - ... (slave)
/dev/hdc  - Standard 440BX Ultra33 controller (master)
/dev/hdd  - ... (slave)
/dev/hde  - HighPoint 366 Ultra66 controller (master)
/dev/hdf  - ... (slave)
/dev/hdg  - HighPoint 366 Ultra66 conroller (master)
/dev/hdh  - ... (slave)
/dev/hdi  - Promise Ultra100 controller (master)
/dev/hdj  - ... (slave)
/dev/hdk  - Promise Ultra100 conroller (master)
/dev/hdl  - ... (slave)

Even though I have all that IDE controller hardware, I only have 3
ATAPI/ATA devices:

hdc: TOSHIBA DVD-ROM SD-M1502, ATAPI CD/DVD-ROM drive
hdi: IBM-DTLA-307030, ATA DISK drive
hdk: IC35L040AVER07-0, ATA DISK drive
...

hdi: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(100)
hdk: 80418240 sectors (41174 MB) w/1916KiB Cache, CHS=79780/16/63, UDMA(100)

I have Windows 2000 installed on "hdi" and Red Hat 7.1 installed on "hdk".

/dev/hdk3 on / type ext2 (rw)
/dev/hdk1 on /boot type ext2 (rw)

My /etc/lilo.conf:

======================
boot=/dev/hdi
map=/boot/map
install=/boot/boot.b
prompt
timeout=150
message=/boot/message
menu-title=" Choose an OS "
lba32
default=linux
disk=/dev/hdi
        bios=0x80
 
disk=/dev/hdk
        bios=0x81
 
image=/boot/vmlinuz-2.4.2-2
        append="hdc=ide-scsi"
        label=linux
        read-only
        root=/dev/hdk3
 
other=/dev/hdi1
        label=w2k
===================

Note: The "disk=" lines are required with both the RH7.1 version of lilo
and the latest lilo, 21.7.5.  Their view of drives is swapped, and I get
"LI" on boot.

With the LILO that comes with Red Hat 7.1, when I run "lilo -v -v -v" I get
an error:

"Sorry, don't know how to handle device XXXX", where XXXX is the
major/minor number for /dev/hdi1.

I upgraded to the latest version of lilo, 21.7.5, the error message went
away (still using exact same lilo.conf), and everything works as expected.

How reproducible:
Always

Steps to Reproduce:
1. Create computer with same controller and drive layout as what I have.
	

Additional info:

Comment 1 Philip Pokorny 2001-10-04 19:10:32 UTC
Please upgrade the urgency of this bug.

In addition to the situation this user described, this bites us when we attempt
to create IDE RAID configurations where the /boot partition is mirrored across
multiple drives which include /dev/hdi.   LILO correctly detects that /boot is
mirrored and attempts to update the boot blocks on all drives in the mirror. 
When it gets to /dev/hdi you get the message:

Sorry, don't know how to handle device 0x3801.

If you have re-arranged the drives and you have the unfortunate situation of hdi
being the FIRST device in the mirror (slot 0 in the raid superblock), then LILO
won't update *any* of the superblocks.

Comment 2 Jeremy Katz 2002-06-04 06:31:09 UTC

*** This bug has been marked as a duplicate of 39365 ***


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