Bug 17608 - During installation lilo.conf incorrect when / is software raid1, leaving system unbootable
Summary: During installation lilo.conf incorrect when / is software raid1, leaving sys...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 7.0
Hardware: i386
OS: Linux
high
medium
Target Milestone: ---
Assignee: Erik Troan
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-09-18 16:38 UTC by Christopher Johnson
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-10-03 20:49:48 UTC
Embargoed:


Attachments (Terms of Use)

Description Christopher Johnson 2000-09-18 16:38:42 UTC
NOTE: This bug existed in RH 6.x install scripts.

If / filesystem is /dev/md0 and md0 is raid 1 backed by /dev/sda1 and
/dev/sdb1 then boot parameter at top of lilo.conf is incorrectly set to:
  boot=/dev/sda
instead of raid partition.  The resulting system is unbootable.

This can be corrected during installation just before exiting to reboot by
changing to the second console and performing the following:
  pico /mnt/sysimage/etc/lilo.conf  (changing boot to: boot=/dev/md0)
  /mnt/sysimage/sbin/lilo -r /mnt/sysimage

Of course it would be much better if the installation scripts got it right
in the first place ;)

-- Chris

Comment 1 Erik Troan 2000-09-29 16:33:17 UTC
This seems to work in 7.0. Please reopen if it doesn't.

Comment 2 Christopher Johnson 2000-10-03 20:49:46 UTC
7.0 does indeed boot under those conditions (guess the bootloader was improved).
But lilo.conf still incorrectly references boot=/dev/sda instead of
boot=/dev/md0

As installed if sda fails there will be no bootloader on sdb and in spite of the
raid configuration it will not boot without a boot floppy.

By using boot=/dev/md0 lilo writes the boot record on sda and sdb to it can boot
with either drive.


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