Bug 35802

Summary:	[RFE] Lilo should read per-image configs from /etc/lilo.d
Product:	[Retired] Red Hat Linux	Reporter:	Matthew Miller <mattdm>
Component:	lilo	Assignee:	Doug Ledford <dledford>
Status:	CLOSED WONTFIX	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.1	CC:	eddie.kuns, pekkas
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-04-15 07:23: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:
Bug Depends On:
Bug Blocks:	35803

Description Matthew Miller 2001-04-12 13:11:22 UTC

This is probably a request for RHL 8, but maybe even for 7.2.

The problem is that automatically parsing, editing, and reconstructing
/etc/lilo.conf is a risky proposition, which means that utilities which
wish to provide fully automatic kernel updates have to perform various
sorts of black magic, and even then are prone to failure.

I suggest that there should exist /etc/lilo.d, from which per-image lilo
stanzas would get read. /etc/lilo.conf would continue to exist for global
options, and for backwards compatibility.

Then, each kernel package would contain a /etc/lilo.d/kernelver.lilo file.

This would suggest that the linux root (and read-only) be specified in the
global config; individual per-image stanzas could override this if need be.
That way, the configs in the kernel packages don't need to contain any
system-specific information: just an image location, a label, and an initrd
location.

Kernel packages should perhaps also update a /etc/lilo.d/redhatdefault.lilo
symlink, which would be marked as default in the global config. (This file
shouldn't be named default.lilo, to avoid implying that it has magic
properties in itself.)

Then, lilo could be run either by the kernel post install script, or by the
utility (up2date, or whatever other meta-package-manger) which installs the
kernel.

This would mirror the general trend towards this style of configuration --
pam.d, logrotate.d, xinet.d, and so on.

Alternately, lilo itself could be left alone, and a new liloconfgen script
could be read. In this case, /etc/lilo.conf would be strictly a generated
file, and global options would be read from something like
/etc/lilo.conf.in or /etc/lilo.conf.top. Modifying lilo seems like a more
elegant approach, since full backwards compatibility can be achieved and
since that wouldn't require installers to deal with yet another script.

Comment 1 Edward Kuns 2001-04-12 16:19:36 UTC

One way to do this is to have each file in /etc/lilo.d be named by its
stanza name.  If there is a /etc/lilo.d/default, it should probably
override a "default" setting -- in some well explained way -- in
/etc/lilo.conf.  This would work with the principle of least surprise
if Red Hat kernel packages and installs never created such a file.
In this way, a user could override Red Hat settings if they read the
documentation to find this option.

Files in this directory should be marked in RPM files as config files!

Another nice feature would be a way to keep files in /etc/lilo.d/ that
aren't included when you run lilo ... perhaps by adding a ".ignore"
extension.

And yes, have "/etc/lilo.d/linux" be a symbolic link to whatever latest
Red Hat kernel RPM was installed, with "linux" the default default :)
stanza in /etc/lilo.conf.  So if the user installs a "/etc/lilo.d/default"
symbolic link in that directory, the user's choice becomes the default,
not the "linux" stanza.

Comment 2 Jeremy Katz 2002-06-04 05:29:01 UTC

We're switching to grub as our default bootloader and have grubby to add things
to grub.conf