Re: [arch-general] {external, general}ized hooks in key packages [kernel26, ???] (WAS: Re: Reboot - Versioned Kernel Installs)
On Monday 13 June 2011 20:53:19 David Campbell wrote: > Excerpts from Timothy L.'s message of 2011-06-13 15:10:16 -0400: > > ... > > I'm a novice when it comes to this kind of stuff, but adding > > simple hooks doesn't seem to needlessly complicate a user's > > system. It's something a user would never notice unless they > > actually needed to use the functionality it provided. > > Just to clarify, when people talk about keeping it simple and the > Arch way, they are not talking about having a simple, clean > interface for the user, they are talking about keeping the system > itself simple, as to reduce the likelihood of bugs, to make > maintenance simpler, to make extending the system easier, etc.. Also, the Wiki article on "The Arch Way" states the following: "Arch Linux targets and accommodates competent GNU/Linux users by giving them complete control and responsibility over the system. " In my opinion, overwriting a working kernel with a version that has not yet been tested on the system, without performing a backup, makes the user's job of responsibility difficult. Providing hooks and the option to perform a backup empowers the user and enables him/her to be cautious if that's his desire. Paul
Re: [arch-general] {external, general}ized hooks in key packages [kernel26, ???] (WAS: Re: Reboot - Versioned Kernel Installs)
On Mon, Jun 13, 2011 at 3:53 PM, David Campbell wrote: > Excerpts from Timothy L.'s message of 2011-06-13 15:10:16 -0400: > > ... > > I'm a novice when it comes to this kind of stuff, but adding > > simple hooks doesn't seem to needlessly complicate a user's > > system. It's something a user would never notice unless they > > actually needed to use the functionality it provided. > > Just to clarify, when people talk about keeping it simple and the > Arch way, they are not talking about having a simple, clean > interface for the user, they are talking about keeping the system > itself simple, as to reduce the likelihood of bugs, to make > maintenance simpler, to make extending the system easier, etc.. > -- > David Campbell > Thanks for the clarification but I understood already. Anthony's post was more of a open-ended proposal (or I perceived it to be), it was not "This is my idea--let's do this." And it was directed more towards core packages like the kernel and pacman rather than all packages. I just felt the OP's post was undeservedly ended before a discussion could even start.
Re: [arch-general] {external, general}ized hooks in key packages [kernel26, ???] (WAS: Re: Reboot - Versioned Kernel Installs)
Excerpts from Timothy L.'s message of 2011-06-13 15:10:16 -0400: > ... > I'm a novice when it comes to this kind of stuff, but adding > simple hooks doesn't seem to needlessly complicate a user's > system. It's something a user would never notice unless they > actually needed to use the functionality it provided. Just to clarify, when people talk about keeping it simple and the Arch way, they are not talking about having a simple, clean interface for the user, they are talking about keeping the system itself simple, as to reduce the likelihood of bugs, to make maintenance simpler, to make extending the system easier, etc.. -- David Campbell
Re: [arch-general] {external, general}ized hooks in key packages [kernel26, ???] (WAS: Re: Reboot - Versioned Kernel Installs)
On Sat, Jun 11, 2011 at 12:50 AM, Yaro Kasear wrote: > On Friday, June 10, 2011 23:36:18 C Anthony Risinger wrote: > > On Fri, Jun 10, 2011 at 2:44 PM, Mauro Santos > > > > 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 > > 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 > > 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 > wrote: > > > Am Fri, 10 Jun 2011 21:21:17 -0400 > > > > > > schrieb "Joe(theWordy)Philbrook" : > > >> 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 rein
Re: [arch-general] {external, general}ized hooks in key packages [kernel26, ???] (WAS: Re: Reboot - Versioned Kernel Installs)
On Friday, June 10, 2011 23:36:18 C Anthony Risinger wrote: > On Fri, Jun 10, 2011 at 2:44 PM, Mauro Santos > > 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 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 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 wrote: > > Am Fri, 10 Jun 2011 21:21:17 -0400 > > > > schrieb "Joe(theWordy)Philbrook" : > >> 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 k
[arch-general] {external, general}ized hooks in key packages [kernel26, ???] (WAS: Re: Reboot - Versioned Kernel Installs)
On Fri, Jun 10, 2011 at 2:44 PM, Mauro Santos 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 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 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 wrote: > Am Fri, 10 Jun 2011 21:21:17 -0400 > schrieb "Joe(theWordy)Philbrook" : > >> 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
