[arch-general] {external, general}ized hooks in key packages [kernel26, ???] (WAS: Re: Reboot - Versioned Kernel Installs)

[Yaro Kasear]

On Friday, June 10, 2011 23:36:18 C Anthony Risinger wrote:
> On Fri, Jun 10, 2011 at 2:44 PM, Mauro Santos
> 
> <registo.mailling at gmail.com> wrote:
> > Arch users have lived without the last good known kernel so far and
> > without an -lts kernel until recently.
> 
> this applies to technology in general -- we don't need any of it, but
> forward we move nonetheless.
> 
> > IMHO it is a lot more advisable
> > to have an install cd/usb, or even better, a custom install in some
> > external media that can be used to boot the system in case something
> > goes wrong or in case of emergency. Then you can just chroot into the
> > broken install and fix the problem or tell pacman where the root and
> > cache are located and fix things.
> 
> why is that simpler/advisable?  now you need to mount everything
> properly by hand else things like autodetection fail in mkinitcpio,
> etc.  i don't think it's hard to recover, and i would never have any
> of these issues, but i think a *real* recovery shell is not a bad idea
> ... why add more work for me the human when the machine could get me
> 95% the way there?  and offer some options even?
> 
> On Fri, Jun 10, 2011 at 7:45 PM, Joe(theWordy)Philbrook <jtwdyp at ttlc.net> 
wrote:
> > The only reason to even consider keeping an old kernel around with Arch
> > was just in case the new kernel is effectively borked... (possibly due
> > to a hardware incompatibility...) And if I remember right, you said
> > something about this not working if the new kernel can't boot...
> 
> you wouldn't want to boot it past the final step, ie. you don't want
> to actually switch_root into your / device and continue the boot
> process ... however, at that moment, you have:
> 
> ) booted a good kernel
> ) have all autodetected modules available (possibly not loaded tho)
> ) ... and (IIRC) -fallback version has the full module tree if needed
> ) loaded your last configuration of initcpio hooks/etc
> ) ... which means your / is probably mounted properly, even with
> encryption and other exotics
> ) other filesystems like /dev /sys are mounted, --move'd, and ready to
> go on the new_root
> ) the whole system is poised for regular boot
> 
> ... so initcpio script *could*, if aware of your dilemma:
> 
> ) drop to shell immediately with some helpful info
> ) chroot for you into /new_root (your real system)
> ) ... maybe bind mount the module hierarchy into new_root to prevent
> accidental loading of wrong mods (if that's even possible, not sure)
> 
> ... basically just bring you 95% the way there, then let you fix it
> and reboot ... done.
> 
> On Fri, Jun 10, 2011 at 8:06 PM, Joe(theWordy)Philbrook <jtwdyp at ttlc.net> 
wrote:
> > It would appear that on Jun 10, Robert Howard did say:
> >> Why not just copy the old kernel image, modules and initrd image
> >> somewhere by hand before you upgrade kernels.
> > 
> > That wouldn't be such a bad idea. And in fact I already do that with the
> > kernel and initrd image.
> 
> and that option will always be available ... but any trivially
> repetitive procedure requiring consistent user interaction is a poor
> solution IMO, if even worthy of being called a solution.  definitely
> an exaggeration, but why even have timed scripts a la cron, or a
> packaging system at all, when we could just remember to do stuff?  why
> not boot the system by hand :-)?  probably because these automata
> improve consistency and reduce the likelihood of errors ... we suck at
> being computers :-)
> 
> http://panko.shidler.hawaii.edu/HumanErr/ProgNorm.htm
> 
> > * CRS : "Can't Remember Sh^Htuff"
> 
> ha nice ... i've never heard anyone else say/use this (CRS acronym)
> ... my grandmother has been telling me that since i was a kid -- i
> always thought she made it up :-) -- one of those independently
> discoverable things i suppose.
> 
> On Fri, Jun 10, 2011 at 8:33 PM, Heiko Baums <lists at baums-on-web.de> wrote:
> > Am Fri, 10 Jun 2011 21:21:17 -0400
> > 
> > schrieb "Joe(theWordy)Philbrook" <jtwdyp at ttlc.net>:
> >> Now that, Heiko, is a good idea. And one that I could actually do.
> >> I'd just have to decide which of my other Linux distributions to
> >> sacrifice to make room for it... Keeping in mind that as you say:
> >> "those cases in which an updated kernel is unbootable are very, very
> >> rare." I think I'd rather learn how to use the "pacman -U" method...
> > 
> > Would at least be less work.
> 
> how is installing another distro that you may never use easier?  you'd
> still have to go thru the whole manual recovery process.  LiveCD beats
> this any day for me -- i rarely install anything these days because my
> distro-hopping abruptly ended with Arch :-) (though i do check them
> out from time to time, or for work related things)
> 
> --------------------------------------------------
> 
> and the end of the day people just want to reinstate a useable system
> as rapidly as possible.  we can yammer on and argue that the user
> "should not be using testing then", "should be making full backups",
> "should have/know an alternate recovery plan", "should be manually
> backing up kernel related stuff", "should be awesomely l33t with linux
> by now", "prob shouldnt use Arch then" or limitless other assertions,
> none of which will help anyone learn anything.
> 
> i can recover my system.  i can recover it pretty much no matter how
> fubificated it is in only a couple minutes because my life is centered
> around these systems -- to others, if not most, the system is merely a
> conduit to their own needs/interests, not the focal point.  this is
> important to remember.  i think some basic recovery options are a fair
> request, and one i've seen often enough in various places.  if their
> needs can be made possible by a simple externalized mechanism, and
> then implemented + maintained by the community, then who is losing?
> if you don't want it you can simply not use it and your system is no
> better or worse.  in fact, it's not even affected to any degree save
> some extra checks failing here and there ... you may even find your
> own use for the triggers.
> 
> such a mechanism could be used to save packages, save module tree,
> save images, or anything else one wanted it to do at that critical
> point.  in my own case, i need a way to save the kernel and initramfs
> before they are replaced -- automatically -- so i can stuff them into
> a btrfs subvolume for system rollbacks ... i would never ask the user
> to perform this manually for a million good reasons.  the only other
> option AFAICS is aliasing over the top of pacman.
> 
> so, while i personally don't care about the threads specific request
> -- as it will never apply to me -- IMO the motivation is sound, and
> could be generalized.  i propose this threads energy move away from
> the endlessly debatable focus on "versioning the kernel" to "providing
> a means to perform custom actions during kernel package transactions,
> and potentially any package" ... something that maybe everyone can
> agree on, and something that may prove to enable many new/interesting
> ideas.
> 
> so, what sayeth anyone that can make the magic come to life, or anyone
> else?
> 
> /etc/pacman/hooks.d/kernel26/<hookname>
> /etc/pacman/hooks.d/hook.kernel26.<hookname>
> /etc/kernel26.hook
> /etc/pacman.linux.hook
> <whatever>
> 
> ill be looking into the pacman hooks proposal, but since i cant do C
> [yet :-] no patches will be from this guy ... external hooks to the
> .install file is probably pretty simple to implemented even in pacman
> (then any package could be hooked), but could easily be done in the
> .install file itself for certain packages, eg. kernel26.
> 
> C Anthony

This all sounds wonderful and handy and completely incompatible with the Arch 
Way.