Re: [rfc] replacing /boot/kernel.old with a unique directory name
On Sun, Aug 14, 2011 at 11:35 AM, Garrett Cooper wrote: > On Sun, Aug 14, 2011 at 10:56 AM, Freddie Cash wrote: > > On Sat, Aug 13, 2011 at 12:51 PM, Alexander Best >wrote: > > > >> hi there, > >> > >> i just had the following idea: how about instead of copying the current > >> kernel > >> to /boot/kernel.old and then installing the new one under /boot/kernel > as > >> the > >> results of target installkernel, we create a unique directory name for > the > >> old > >> kernel? > >> > >> something like /boot/kernel-r${revision}-${/dev/random}? > >> > >> that would let people not only boot the previous kernel, but all kernels > >> that > >> have been replaced by target installkernel. this would make tracking > >> issues, > >> which have been introduced by a certain commit much easier, imho. > >> > >> i don't think implementing this logic would be that difficult. the only > >> problem > >> i see is with ${/dev/random} in the case where people are running a > kernel > >> without /dev/{u}random support. > >> > > > > A better method may be to use KODIR to install the *new* kernel to a > unique > > directory via installkernel (make KERNCONF=SOMEKERNEL > > KODIR=/boot/SOMEKERNEL-rev-whatever installkernel) and then using > "nextboot > > -k SOMEKERNEL-rev-whatever" to set that kernel as bootable on the next > boot. > > > > You reboot, make sure everything works with SOMEKERNEL-rev-whatever, and > > then make that the default kernel (rm -rf /boot/kernel; cp -Rvp > > /boot/SOMEKERNEL-rev-whatever /boot/kernel; shutdown -r now). > > > > Sure, it's not automated yet, but the building blocks are there. > > > > This way, you never disturb the currently working kernel until you know > the > > new kernel works. And if things go south with the new kernel, a simple > > reboot is all that's needed to revert back to the working /boot/kernel. > > > > All that's needed is to automate things a bit (pick KODIR, set nextboot, > > create a post-install target of some kind to run after booting the new > > kernel). > > > > And, this leaves all of your kernels around if you want to play with > > different ones. > >Again, why build more complexity into the system when it does what > you want in a more generic manner? Just to illustrate what I do on a > weekly basis, here's my script and example invocation (I have other > instances where I have more KERNCONFs and things are more > complicated). You shouldn't have to do much more than what I did below > when dealing with your specific case of interest -- especially > because, as you and others have identified elsewhere it may not work, > it might fill up whatever partition /boot is on, etc. > Unless I'mmissing something, we're saying essentially the same thing (install new kernel to unique directory) , but you've done the work to actually automate it. :) -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On 8/14/11 3:27 AM, Eduardo Morras wrote: At 22:06 13/08/2011, Steven Hartland wrote: - Original Message - From: "Alexander Best" i just had the following idea: how about instead of copying the current kernel to /boot/kernel.old and then installing the new one under /boot/kernel as the results of target installkernel, we create a unique directory name for the old kernel? The default size of / is likely your biggest problem. Don't know how much compresable is /boot/kernel.old but tar with -z or -j may be a workaround. We can extract on demand and swap current /boot/kernel with new /boot/kernel. Other way of do it is link /boot/kernel to current kernel and update it, but i don't know (again) if it would work in single user mode. What would make more sense to me for thsi would be a kernel name that was recognised by teh final boot stages as being an exeprimental kernel and moved to the new location only on successful boot.. Once you have successfully booted it, then you delete the kernel[-1] and do the replacement that "make installkernel" now does. Regards Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
Freddie Cash writes: > On Sat, Aug 13, 2011 at 12:51 PM, Alexander Best wrote: > >> hi there, >> >> i just had the following idea: how about instead of copying the current >> kernel >> to /boot/kernel.old and then installing the new one under /boot/kernel as >> the >> results of target installkernel, we create a unique directory name for the >> old >> kernel? >> >> something like /boot/kernel-r${revision}-${/dev/random}? >> >> that would let people not only boot the previous kernel, but all kernels >> that >> have been replaced by target installkernel. this would make tracking >> issues, >> which have been introduced by a certain commit much easier, imho. >> >> i don't think implementing this logic would be that difficult. the only >> problem >> i see is with ${/dev/random} in the case where people are running a kernel >> without /dev/{u}random support. >> > > A better method may be to use KODIR to install the *new* kernel to a unique > directory via installkernel (make KERNCONF=SOMEKERNEL > KODIR=/boot/SOMEKERNEL-rev-whatever installkernel) and then using "nextboot > -k SOMEKERNEL-rev-whatever" to set that kernel as bootable on the next boot. > > You reboot, make sure everything works with SOMEKERNEL-rev-whatever, and > then make that the default kernel (rm -rf /boot/kernel; cp -Rvp > /boot/SOMEKERNEL-rev-whatever /boot/kernel; shutdown -r now). [...] nextboot needs write access in loader to reset kernel, which is only available for ufs. So, forget about zfs and every other fs from libstand(3), e.g. ext2fs, msdosfs, nfs. bootonce is also only supported in gptboot (ufs), not gptzfsboot. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On Sun, Aug 14, 2011 at 10:56 AM, Freddie Cash wrote: > On Sat, Aug 13, 2011 at 12:51 PM, Alexander Best wrote: > >> hi there, >> >> i just had the following idea: how about instead of copying the current >> kernel >> to /boot/kernel.old and then installing the new one under /boot/kernel as >> the >> results of target installkernel, we create a unique directory name for the >> old >> kernel? >> >> something like /boot/kernel-r${revision}-${/dev/random}? >> >> that would let people not only boot the previous kernel, but all kernels >> that >> have been replaced by target installkernel. this would make tracking >> issues, >> which have been introduced by a certain commit much easier, imho. >> >> i don't think implementing this logic would be that difficult. the only >> problem >> i see is with ${/dev/random} in the case where people are running a kernel >> without /dev/{u}random support. >> > > A better method may be to use KODIR to install the *new* kernel to a unique > directory via installkernel (make KERNCONF=SOMEKERNEL > KODIR=/boot/SOMEKERNEL-rev-whatever installkernel) and then using "nextboot > -k SOMEKERNEL-rev-whatever" to set that kernel as bootable on the next boot. > > You reboot, make sure everything works with SOMEKERNEL-rev-whatever, and > then make that the default kernel (rm -rf /boot/kernel; cp -Rvp > /boot/SOMEKERNEL-rev-whatever /boot/kernel; shutdown -r now). > > Sure, it's not automated yet, but the building blocks are there. > > This way, you never disturb the currently working kernel until you know the > new kernel works. And if things go south with the new kernel, a simple > reboot is all that's needed to revert back to the working /boot/kernel. > > All that's needed is to automate things a bit (pick KODIR, set nextboot, > create a post-install target of some kind to run after booting the new > kernel). > > And, this leaves all of your kernels around if you want to play with > different ones. Again, why build more complexity into the system when it does what you want in a more generic manner? Just to illustrate what I do on a weekly basis, here's my script and example invocation (I have other instances where I have more KERNCONFs and things are more complicated). You shouldn't have to do much more than what I did below when dealing with your specific case of interest -- especially because, as you and others have identified elsewhere it may not work, it might fill up whatever partition /boot is on, etc. Thanks, -Garrett $ cat ~root/bin/installkernel #!/bin/sh SRCCONF=${SRCCONF:=/etc/src.conf} set -e for i in $(make -f "$SRCCONF" -V KERNCONF); do # Using svn info is bad because that captures the sourcebase revision, # which may or may not match the actual kernel being installed's revision. # Something like `strings kernel | awk '/^FreeBSD [0-9]+/' ' would be # better. sudo make installkernel \ KERNCONF=$i \ INSTKERNNAME=$i.r$(svn info | awk '/^Revision/ {print $2}')${SUFFIX:+.$SUFFIX} \ $* done Example: $ make -VKERNCONF -f /etc/src.conf BAYONETTA $ cd /usr/src && ~root/bin/installkernel && ln -sfh BAYONETTA /boot/kernel && reboot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On Sat, Aug 13, 2011 at 12:51 PM, Alexander Best wrote: > hi there, > > i just had the following idea: how about instead of copying the current > kernel > to /boot/kernel.old and then installing the new one under /boot/kernel as > the > results of target installkernel, we create a unique directory name for the > old > kernel? > > something like /boot/kernel-r${revision}-${/dev/random}? > > that would let people not only boot the previous kernel, but all kernels > that > have been replaced by target installkernel. this would make tracking > issues, > which have been introduced by a certain commit much easier, imho. > > i don't think implementing this logic would be that difficult. the only > problem > i see is with ${/dev/random} in the case where people are running a kernel > without /dev/{u}random support. > A better method may be to use KODIR to install the *new* kernel to a unique directory via installkernel (make KERNCONF=SOMEKERNEL KODIR=/boot/SOMEKERNEL-rev-whatever installkernel) and then using "nextboot -k SOMEKERNEL-rev-whatever" to set that kernel as bootable on the next boot. You reboot, make sure everything works with SOMEKERNEL-rev-whatever, and then make that the default kernel (rm -rf /boot/kernel; cp -Rvp /boot/SOMEKERNEL-rev-whatever /boot/kernel; shutdown -r now). Sure, it's not automated yet, but the building blocks are there. This way, you never disturb the currently working kernel until you know the new kernel works. And if things go south with the new kernel, a simple reboot is all that's needed to revert back to the working /boot/kernel. All that's needed is to automate things a bit (pick KODIR, set nextboot, create a post-install target of some kind to run after booting the new kernel). And, this leaves all of your kernels around if you want to play with different ones. > cheers. > alex > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On Sun Aug 14 11, Test Rat wrote: > Test Rat writes: > > > Eduardo Morras writes: > > > >> At 22:06 13/08/2011, Steven Hartland wrote: > i just had the following idea: how about instead of copying the > current kernel > to /boot/kernel.old and then installing the new one under /boot/kernel as > the > results of target installkernel, we create a unique directory name > for the old > kernel? > >>> > >>>The default size of / is likely your biggest problem. > >> > >> Don't know how much compresable is /boot/kernel.old but tar with -z > >> or -j may be a workaround. We can extract on demand and swap current > >> /boot/kernel with new /boot/kernel. Other way of do it is link > >> /boot/kernel to current kernel and update it, but i don't know > >> (again) if it would work in single user mode. > > > > There is kgzldr that lets you boot compressed kernels. Try > > > > $ gzip /boot/kernel/* > > $ reboot the above works for me. just booted a compressed kernel. > > Nevermind, I've confused it with gzip support in loader, it also > has bzip2 support which for some reason doesn't work for me > > bzf_read: BZ2_bzDecompress returned -3 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
Test Rat writes: > Eduardo Morras writes: > >> At 22:06 13/08/2011, Steven Hartland wrote: i just had the following idea: how about instead of copying the current kernel to /boot/kernel.old and then installing the new one under /boot/kernel as the results of target installkernel, we create a unique directory name for the old kernel? >>> >>>The default size of / is likely your biggest problem. >> >> Don't know how much compresable is /boot/kernel.old but tar with -z >> or -j may be a workaround. We can extract on demand and swap current >> /boot/kernel with new /boot/kernel. Other way of do it is link >> /boot/kernel to current kernel and update it, but i don't know >> (again) if it would work in single user mode. > > There is kgzldr that lets you boot compressed kernels. Try > > $ gzip /boot/kernel/* > $ reboot Nevermind, I've confused it with gzip support in loader, it also has bzip2 support which for some reason doesn't work for me bzf_read: BZ2_bzDecompress returned -3 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
Eduardo Morras writes: > At 22:06 13/08/2011, Steven Hartland wrote: >>> i just had the following idea: how about instead of copying the >>> current kernel >>>to /boot/kernel.old and then installing the new one under /boot/kernel as the >>> results of target installkernel, we create a unique directory name >>> for the old >>>kernel? >> >>The default size of / is likely your biggest problem. > > Don't know how much compresable is /boot/kernel.old but tar with -z > or -j may be a workaround. We can extract on demand and swap current > /boot/kernel with new /boot/kernel. Other way of do it is link > /boot/kernel to current kernel and update it, but i don't know > (again) if it would work in single user mode. There is kgzldr that lets you boot compressed kernels. Try $ gzip /boot/kernel/* $ reboot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
At 22:06 13/08/2011, Steven Hartland wrote: - Original Message - From: "Alexander Best" i just had the following idea: how about instead of copying the current kernel to /boot/kernel.old and then installing the new one under /boot/kernel as the results of target installkernel, we create a unique directory name for the old kernel? The default size of / is likely your biggest problem. Don't know how much compresable is /boot/kernel.old but tar with -z or -j may be a workaround. We can extract on demand and swap current /boot/kernel with new /boot/kernel. Other way of do it is link /boot/kernel to current kernel and update it, but i don't know (again) if it would work in single user mode. Regards Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On Aug 13, 2011, at 1:15 PM, Alexander Best wrote: > On Sat Aug 13 11, Garrett Cooper wrote: >> On Aug 13, 2011, at 12:51 PM, Alexander Best wrote: >> >>> hi there, >>> >>> i just had the following idea: how about instead of copying the current >>> kernel >>> to /boot/kernel.old and then installing the new one under /boot/kernel as >>> the >>> results of target installkernel, we create a unique directory name for the >>> old >>> kernel? >>> >>> something like /boot/kernel-r${revision}-${/dev/random}? >>> >>> that would let people not only boot the previous kernel, but all kernels >>> that >>> have been replaced by target installkernel. this would make tracking issues, >>> which have been introduced by a certain commit much easier, imho. >>> >>> i don't think implementing this logic would be that difficult. the only >>> problem >>> i see is with ${/dev/random} in the case where people are running a kernel >>> without /dev/{u}random support. >> >> Why not just use INSTKERNNAME? > > hmm...won't setting INSTKERNNAME set the path to where the new kernel will be > installed and not where the current kernel will be backup'ed? It moves the old kernel to $INSTKERNNAME.old . That's usually good enough when working with svn and multiple KERNCONFs. -Garrett___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
- Original Message - From: "Alexander Best" i just had the following idea: how about instead of copying the current kernel to /boot/kernel.old and then installing the new one under /boot/kernel as the results of target installkernel, we create a unique directory name for the old kernel? The default size of / is likely your biggest problem. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On Sat Aug 13 11, Garrett Cooper wrote: > On Aug 13, 2011, at 12:51 PM, Alexander Best wrote: > > > hi there, > > > > i just had the following idea: how about instead of copying the current > > kernel > > to /boot/kernel.old and then installing the new one under /boot/kernel as > > the > > results of target installkernel, we create a unique directory name for the > > old > > kernel? > > > > something like /boot/kernel-r${revision}-${/dev/random}? > > > > that would let people not only boot the previous kernel, but all kernels > > that > > have been replaced by target installkernel. this would make tracking issues, > > which have been introduced by a certain commit much easier, imho. > > > > i don't think implementing this logic would be that difficult. the only > > problem > > i see is with ${/dev/random} in the case where people are running a kernel > > without /dev/{u}random support. > > Why not just use INSTKERNNAME? hmm...won't setting INSTKERNNAME set the path to where the new kernel will be installed and not where the current kernel will be backup'ed? > -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On Aug 13, 2011, at 12:51 PM, Alexander Best wrote: > hi there, > > i just had the following idea: how about instead of copying the current kernel > to /boot/kernel.old and then installing the new one under /boot/kernel as the > results of target installkernel, we create a unique directory name for the old > kernel? > > something like /boot/kernel-r${revision}-${/dev/random}? > > that would let people not only boot the previous kernel, but all kernels that > have been replaced by target installkernel. this would make tracking issues, > which have been introduced by a certain commit much easier, imho. > > i don't think implementing this logic would be that difficult. the only > problem > i see is with ${/dev/random} in the case where people are running a kernel > without /dev/{u}random support. Why not just use INSTKERNNAME? -Garrett___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On Sat Aug 13 11, Chris Rees wrote: > On 13 August 2011 20:51, Alexander Best wrote: > > hi there, > > > > i just had the following idea: how about instead of copying the current > > kernel > > to /boot/kernel.old and then installing the new one under /boot/kernel as > > the > > results of target installkernel, we create a unique directory name for the > > old > > kernel? > > > > something like /boot/kernel-r${revision}-${/dev/random}? > > > > that would let people not only boot the previous kernel, but all kernels > > that > > have been replaced by target installkernel. this would make tracking issues, > > which have been introduced by a certain commit much easier, imho. > > > > i don't think implementing this logic would be that difficult. the only > > problem > > i see is with ${/dev/random} in the case where people are running a kernel > > without /dev/{u}random support. > > > > cheers. > > alex > > mktemp? ahh. nice. unless mktemp(1) relies on "device random", that sounds like a good solution. :) > > Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
On 13 August 2011 20:51, Alexander Best wrote: > hi there, > > i just had the following idea: how about instead of copying the current kernel > to /boot/kernel.old and then installing the new one under /boot/kernel as the > results of target installkernel, we create a unique directory name for the old > kernel? > > something like /boot/kernel-r${revision}-${/dev/random}? > > that would let people not only boot the previous kernel, but all kernels that > have been replaced by target installkernel. this would make tracking issues, > which have been introduced by a certain commit much easier, imho. > > i don't think implementing this logic would be that difficult. the only > problem > i see is with ${/dev/random} in the case where people are running a kernel > without /dev/{u}random support. > > cheers. > alex mktemp? Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[rfc] replacing /boot/kernel.old with a unique directory name
hi there, i just had the following idea: how about instead of copying the current kernel to /boot/kernel.old and then installing the new one under /boot/kernel as the results of target installkernel, we create a unique directory name for the old kernel? something like /boot/kernel-r${revision}-${/dev/random}? that would let people not only boot the previous kernel, but all kernels that have been replaced by target installkernel. this would make tracking issues, which have been introduced by a certain commit much easier, imho. i don't think implementing this logic would be that difficult. the only problem i see is with ${/dev/random} in the case where people are running a kernel without /dev/{u}random support. cheers. alex ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"