Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Tue, 29 Jun 2010 16:35:40 -0400 (EDT), maximilian attems wrote:
> On Tue, Jun 29, 2010 at 04:24:48PM -0400, Stephen Powell wrote:
>>
>> Sorry I didn't think of this the first time, but there are up to
>> four steps to preparing a kernel for booting:
>>
>> (1) Installation of the kernel itself
>> (2) Creation of an initial RAM file system
>> (3) Updating symbolic links
>> ...
>
> they are deprecated and shouldn't be necessary.
> there are even more evil incarnations like reverse symlinks or whatever.
> which we no longer support since longer..
> it be better to just get rid of them.
Hmm. Well, I don't mind if you drop support for direct symlink
maintenance from the kernel maintainer scripts, but the symlinks
serve a very useful function: they make it possible for the boot loader
configuration file, /etc/lilo.conf, /etc/zipl.conf, etc. to remain a
relatively static file. That is how these historic boot loaders,
such as lilo and zipl, are used to operating. And remember, on
the s390 platform, zipl is the *only* supported boot loader.
Since symlinks are not associated with any package in particular,
and since they seem to have been designed for the convenience of
historic boot loaders such as lilo and zipl, perhaps the best way
to handle this is for the boot loader hook script, zz-whatever, to
maintain the symlinks, if desired.
As a matter of fact, I already
have a hook script on hand that does this very thing, and with minor
modifications will do nicely, I think. Right now, it unconditionally
maintains the symlinks. To generalize it more, it could determine
if symlinks already exist or not, and if so where, then maintain
them where they are. If the symlinks don't exist, it won't create
them. It could also be changed to determine if lilo or zipl is
in use, based on the presence of the config file, and invoke the
appropriate boot loader. Then, all the maintainer of the s390-tools
package would have to do is to include it in the s390-tools package.
And the maintainer of lilo could do the same.
>> ...
>> [discussion of initramfs-tools script issues]
>> ...
>
> hate those indirections due to debconf magic, but why would
> the hook scripts need one. thanks for hints, been staying away
> from debconf for long..
>
> the unconditional is expected and there is a wishlist bug
> open for that it has not high priority as many things do
> not work if you don'T use an initramfs.
Understood.
Since you're obviously very busy, I will submit a version
of the initramfs-tools script which I believe will address
all these issues. Then you can take pot shots at it.
>> ps if you want the no cc thing set up your mua appropriately.
>> here in d-kernel we do cc.
I don't care either way, actually. But when in Rome, do as
the Romans do. I included you on the cc list, per the above.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Reply to: