Bug 35802 - [RFE] Lilo should read per-image configs from /etc/lilo.d
[RFE] Lilo should read per-image configs from /etc/lilo.d
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: lilo (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Doug Ledford
Brock Organ
: FutureFeature
Depends On:
Blocks: 35803
  Show dependency treegraph
 
Reported: 2001-04-12 09:11 EDT by Matthew Miller
Modified: 2007-04-18 12:32 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-15 03:23:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Miller 2001-04-12 09:11:22 EDT
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 12:19:36 EDT
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 01:29:01 EDT
We're switching to grub as our default bootloader and have grubby to add things
to grub.conf

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