On Fri, Jun 10, 2011 at 5:42 AM, Martti Kühne <mysatyre@xxxxxxxxx> wrote: > On Fri, Jun 10, 2011 at 12:36 AM, C Anthony Risinger <anthony@xxxxxxx> 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
