Bug 35754

Summary:	Dual-boot machine lilo.conf messed up with QA0404 up2date.
Product:	[Retired] Red Hat Linux	Reporter:	Lamar Owen <lowen>
Component:	up2date	Assignee:	Adrian Likins <alikins>
Status:	CLOSED RAWHIDE	QA Contact:	Jay Turner <jturner>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.1	CC:	katzj, srevivo
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-04-12 21:03:49 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 Lamar Owen 2001-04-12 00:51:40 UTC

Did an up2date upgrade to Seawolf from QA0404.

Machine is dual boot with default boot target as the dos partition.

Up2date modification of lilo.conf resulted in a new boot target (linux.bak) that is the old kernel, which boots ok. The new kernel is given the boot 
target of 'linux' -- which won't boot because no 'root=' entry is provided.  BUT the linux boot-target is marked as the default, instead of the dos 
target used before.  My _new_ lilo.conf as given to me by the up2date system is:
---------------------------------------------
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
linear
default=linux

image=/boot/vmlinuz-2.4.2-0.1.49
	label=linux.bak
	read-only
	root=/dev/hda3

other=/dev/hda1
	label=dos

image=/boot/vmlinuz-2.4.2-2
	label=linux
	read-only

The old one was:
------------------------
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
linear
default=dos

image=/boot/vmlinuz-2.4.2-0.1.49
	label=linux
	read-only
	root=/dev/hda3

other=/dev/hda1
	label=dos
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Comment 1 Preston Brown 2001-04-12 21:03:34 UTC

I believe this was fixed in 0408.  Adrian, can you verify?

Comment 2 Jay Turner 2001-04-13 14:01:11 UTC

This is fixed in the latest up2date-2.5.3-1 which should be going out as soon as
it makes it way through QA.