Re: [PULL REQUEST] Automatic kernel management

On Tue, 2012-08-14 at 00:29 +0200, Giovanni Campagna wrote:
> Unless ostree is used as the one and only system (which it can't,
> currently), 

Right.  Now eventually we want to be building kernels, but the current
design is fairly practical I think.

> To help alleviate this, I made some handy scripts that
> work in my environment, but should be general purpose (at least for
> rpm based distros) enough to be included upstream.
> Essentially they are invoked by rpm %post and propagate the kernel
> changes to ostree. GRUB 2 is kind of assumed, although I kept existing
> code for GRUB 1
> You can find them at, the branch is master.
Shouldn't the kernel updates being enabled default to true only if:

1) You're building with sysconfdir = /etc
2) You're on Fedora (does anything else
   implement /etc/kernel/postinst.d?)
-  { "no-initramfs", 0, 0, G_OPTION_ARG_NONE, &opt_no_initramfs, "Don't generate initramfs", NULL },
-  { "no-bootloader", 0, 0, G_OPTION_ARG_NONE, &opt_no_bootloader, "Don't update bootloader", NULL },
+  { "no-kernel", 0, 0, G_OPTION_ARG_NONE, &opt_no_kernel, "Don't update kernel related config (initramfs, bootloader)", NULL },

This bit will break ostbuild privhelper-deploy-qemu
Not that that script is beautiful or anything, but I am using it now.

As far as splitting off certainly makes the code
changes "noisier".  It's slightly unfortunate to re-exec ostadmin; we
could split off update_kernel as an internal API.  But up to you.

I think a similar change was made in the src/ostree code which the
ostadmin bits got copied from.  So this looks OK.

Thanks for looking at this!

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]