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

[C Anthony Risinger]

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