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@xxxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxxxxxxxxx> wrote: > > Am Fri, 10 Jun 2011 21:21:17 -0400 > > > > schrieb "Joe(theWordy)Philbrook" <jtwdyp@xxxxxxxx>: > >> 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.
