Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 11722

Summary:	sda/sdb raid1 boot setup gives an error when updating lilo.
Product:	[Retired] Red Hat Linux	Reporter:	Pekka Savola <pekkas>
Component:	lilo	Assignee:	Michael K. Johnson <johnsonm>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.2
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-08-31 06:08:41 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Pekka Savola 2000-05-28 21:45:56 UTC

I have this kind of setup
/dev/sda 2 GB
  sda1 /     800 MB
  sda2 swap  128 MB
  sda3 ext   rest
  sda5 /home 500 MB
  sda6 /var  500 MB
  sda7 /tmp  100 MB
/dev/sdb 2 GB
  the same as above.  The disks aren't 100% identical, but the extra
  sectors on bigger disk are left unallocated.

Every partition except swap is RAID1'ed, creating md0-md3.  All of those
are type 'fd' (raid autodetect autodetect).

Now, if I set up /etc/lilo.conf so that boot=/dev/md0, root=/dev/md0
it says

Open /tmp/dev.0: No such device

after modifying both sda and sdb.

Booting works as long as I don't remove sda.  If I do that, I get a no rom
basic error.

It seems the latest lilo tarball from its home FTP site gives the same
message about dev.0.

[ btw, rawhide lilo is a bit outdated version ]

Comment 1 Pekka Savola 2000-06-05 08:16:31 UTC

I tried this on an old box that hadn't been installed using failed-disk
directives in /etc/raidtab (causing sda and sdb be ordered a bit differently),
and I got:

----
boot = /dev/sda, map = /boot/map.0801
Added linux *
boot = /dev/sdb, map = /boot/map.0811
Added linux *
----

No errors.  Note that /dev/sda is updated before sdb here, not the other way
around as before.  It might be the key here.

Comment 2 Need Real Name 2001-08-31 06:08:36 UTC

I've run into this same thing, and found that this is caused by a drive failure
on a mirrored filesystem. When I got this error, I checked /proc/mdstat, and
found that I had a mirror reporting itself as failed.

Perhaps lilo's error reporting should be _SIGNIFICANTLY_ improved in this case?

Comment 3 Jeremy Katz 2002-06-04 05:15:34 UTC

lilo's error reporting could probably be improved, but as we're migrating toward
using grub instead, we're not likely to expend any effort on doing this.