[arch-general] Reboot - Versioned Kernel Installs

[C Anthony Risinger]

On Fri, Jun 10, 2011 at 5:42 AM, Martti Kühne <mysatyre at gmail.com> wrote:
> On Fri, Jun 10, 2011 at 12:36 AM, C Anthony Risinger <anthony at xtfx.me> wrote:
> <snip>
>> what if we (optionally) stored the original images _inside_ the new
>> one?  the new/bad kernel would boot, and via some bootloader entry eg.
>> kernel param the new initcpio script would kexec the old kernel, with
>> another (different) kernel param ... when the old kernel booted it
>> would load the exact same initramfs image, except it would use an
>> alternate tree, ie. instead of /init it would chroot to /previous and
>> run /previous/init ...
>>
>
> eh, for the priority of known sources of error: an UPDATE image could
> contain the NEW kernel in an alternate tree /new/init, because the OLD
> kernel is KNOWN to boot that far...

yeah but when i update then kernel, i expect it to be updated ... not
boot the old one next time i restart.  i'm pretty sure you'd get all
sorts of confusion over that.

... and the machine probably wouldn't work anyway because the module
tree would be incorrect, though the ones in the initramfs would still
be ok.

since it's not really practical to actually boot the previous kernel
(unless your using some kind of _system_ recovery mechanism like
*cough* btrfs rollback), we're really just talking about a small
recovery environment.  lts kernel kind of works for this, but the last
known good kernel is better ...

i still think the best solution is to just drop some externalized
hooks into the .install file for kernel package and let to community
run with it.  this eliminated developer burden/responsibility and
allows flexibility for different implementations and different needs.
maybe if we like some they can be added to standard repos in time.
for example, a couple months back i was working on trying to get
kernel rollbacks working with the mkinicpio-btrfs hook ... i needed a
two-stage boot via kexec because the real kernel was inside a btrfs
subvolume -- which bootloaders cannot yet access -- and it needed to
be rebuilt with the real kernel.  a simple drop in hook for this would
have made things much much easier.

so i say forget about versioned kernels and all that jazz because
that's just one possible use.  create something like:

/etc/pacman/hooks.d/kernel26/<hookname>

... where kernel26 matches the package name.  i haven't looked at the
proposition for pacman hooks but this seems like it could serve as a
small pilot to a more generic mechanism.  ultimately this thread is
not about "versioned kernels" but rather providing a way to link into
the system management procedures performed by pacman, and do custom
stuff.

C Anthony