Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Wednesday, November 06, 2013 19:18:31 UTC Baldwin, John wrote: On Wednesday, November 06, 2013 10:22:44 am Teske, Devin wrote: On Nov 6, 2013, at 1:18 AM, Lars Engels wrote: Am 05.11.2013 18:06, schrieb Kurt Lidl: Well, I'd probably be in support of this change - it sure beats having to interrupt the normal boot sequence and typing: unload load /boot/kernel.old/kernel load /boot/kernel.old/opensolaris.ko load /boot/kernel.old/zfs.ko boot To load an older kernel I always just type boot kernel.old Doesn't that unload the currently loaded kernel automatically? Actually... it does. Thanks for pointing that out (forgot about that). The only thing that it doesn't do which I wish it did was fixup module_path. Right now if you break into the loader prompt and do 'boot foo', you end up with module_path containing /boot/kernel;/boot/modules;/boot/foo. What I would like is to be able to use 'boot foo' and get a proper module_path. Yeah - I found this out the hard way when playing with incompatible versions of zfs.ko. I suppose the boot kernel.old method works if kernel.old is close enough to kernel, as you'll get the kernel.old/kernel file, and kernel/zfs.ko kernel/opensolaris.ko modules loaded that way. -Kurt ___ 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: [CFT] Kernel-Selection Enhancemnt to Boot Menu
Am 05.11.2013 18:06, schrieb Kurt Lidl: Well, I'd probably be in support of this change - it sure beats having to interrupt the normal boot sequence and typing: unload load /boot/kernel.old/kernel load /boot/kernel.old/opensolaris.ko load /boot/kernel.old/zfs.ko boot To load an older kernel I always just type boot kernel.old Doesn't that unload the currently loaded kernel automatically? ___ 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: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Nov 6, 2013, at 1:18 AM, Lars Engels wrote: Am 05.11.2013 18:06, schrieb Kurt Lidl: Well, I'd probably be in support of this change - it sure beats having to interrupt the normal boot sequence and typing: unload load /boot/kernel.old/kernel load /boot/kernel.old/opensolaris.ko load /boot/kernel.old/zfs.ko boot To load an older kernel I always just type boot kernel.old Doesn't that unload the currently loaded kernel automatically? Actually... it does. Thanks for pointing that out (forgot about that). I think we still want the loader_delay feature added by the last patch I shared on-list. Yeah? I think it's still a good (optional) value-add. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Wednesday, November 06, 2013 10:22:44 am Teske, Devin wrote: On Nov 6, 2013, at 1:18 AM, Lars Engels wrote: Am 05.11.2013 18:06, schrieb Kurt Lidl: Well, I'd probably be in support of this change - it sure beats having to interrupt the normal boot sequence and typing: unload load /boot/kernel.old/kernel load /boot/kernel.old/opensolaris.ko load /boot/kernel.old/zfs.ko boot To load an older kernel I always just type boot kernel.old Doesn't that unload the currently loaded kernel automatically? Actually... it does. Thanks for pointing that out (forgot about that). The only thing that it doesn't do which I wish it did was fixup module_path. Right now if you break into the loader prompt and do 'boot foo', you end up with module_path containing /boot/kernel;/boot/modules;/boot/foo. What I would like is to be able to use 'boot foo' and get a proper module_path. -- John Baldwin ___ 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: [CFT] Kernel-Selection Enhancemnt to Boot Menu
You can try enabling the beastie menu on sparc64 by editing /boot/loader.rc: === Change #1 in /boot/loader.rc to enable beastie menu === Find: \ Reads and processes loader.conf variables \ NOTE: Change to `initialize' if you enable the below boot menu start Change start to initialize as shown below: \ Reads and processes loader.conf variables \ NOTE: Change to `initialize' if you enable the below boot menu initialize === Change #2 in [same file] to enable beastie menu === Find: \ Uncomment to enable boot menu \ include /boot/beastie.4th \ beastie-start Uncomment beastie-start as shown below: \ Uncomment to enable boot menu \ include /boot/beastie.4th beastie-start == If you find that making those two trivial changes, that you are able to load the menu... then maybe it's time for us to start thinking about enabling the beastie menu by-default for the sparc64 architecture. Seems to work just fine. I tested by booting, toggling through the different kernel choices (/boot/kernel/kernel /boot/kernel.old/kernel) and both worked correctly. (Although I uncommented the include /boot/beastie.4th line too.) Does anybody else have any thoughts on enabling it for sparc64? Well, I'd probably be in support of this change - it sure beats having to interrupt the normal boot sequence and typing: unload load /boot/kernel.old/kernel load /boot/kernel.old/opensolaris.ko load /boot/kernel.old/zfs.ko boot When I need to get back to the prior version of the kernel. -Kurt ___ 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: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Nov 5, 2013, at 9:06 AM, Kurt Lidl wrote: You can try enabling the beastie menu on sparc64 by editing /boot/loader.rc: === Change #1 in /boot/loader.rc to enable beastie menu === Find: \ Reads and processes loader.conf variables \ NOTE: Change to `initialize' if you enable the below boot menu start Change start to initialize as shown below: \ Reads and processes loader.conf variables \ NOTE: Change to `initialize' if you enable the below boot menu initialize === Change #2 in [same file] to enable beastie menu === Find: \ Uncomment to enable boot menu \ include /boot/beastie.4th \ beastie-start Uncomment beastie-start as shown below: \ Uncomment to enable boot menu \ include /boot/beastie.4th beastie-start == If you find that making those two trivial changes, that you are able to load the menu... then maybe it's time for us to start thinking about enabling the beastie menu by-default for the sparc64 architecture. Seems to work just fine. I tested by booting, toggling through the different kernel choices (/boot/kernel/kernel /boot/kernel.old/kernel) and both worked correctly. (Although I uncommented the include /boot/beastie.4th line too.) Oops, heh, good eye ;D and sorry if that caused any pain for you. Does anybody else have any thoughts on enabling it for sparc64? Well, I'd probably be in support of this change - it sure beats having to interrupt the normal boot sequence and typing: unload load /boot/kernel.old/kernel load /boot/kernel.old/opensolaris.ko load /boot/kernel.old/zfs.ko boot When I need to get back to the prior version of the kernel. We'll have to draw up a clean patch to draw this in for sparc64. For i386 and amd64, they have a dedicated separate loader.rc stashed in sys/boot/i386/loader/ Not sure of the cleanest way to do this for sparc64 (dup the loader.rc and make sparc64 drop it's own? or perhaps make sparc64 drop the i386 loader.rc? I think amd64 does the latter). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On 11/05/13 11:06, Kurt Lidl wrote: You can try enabling the beastie menu on sparc64 by editing /boot/loader.rc: === Change #1 in /boot/loader.rc to enable beastie menu === Find: \ Reads and processes loader.conf variables \ NOTE: Change to `initialize' if you enable the below boot menu start Change start to initialize as shown below: \ Reads and processes loader.conf variables \ NOTE: Change to `initialize' if you enable the below boot menu initialize === Change #2 in [same file] to enable beastie menu === Find: \ Uncomment to enable boot menu \ include /boot/beastie.4th \ beastie-start Uncomment beastie-start as shown below: \ Uncomment to enable boot menu \ include /boot/beastie.4th beastie-start == If you find that making those two trivial changes, that you are able to load the menu... then maybe it's time for us to start thinking about enabling the beastie menu by-default for the sparc64 architecture. Seems to work just fine. I tested by booting, toggling through the different kernel choices (/boot/kernel/kernel /boot/kernel.old/kernel) and both worked correctly. (Although I uncommented the include /boot/beastie.4th line too.) Does anybody else have any thoughts on enabling it for sparc64? Well, I'd probably be in support of this change - it sure beats having to interrupt the normal boot sequence and typing: unload load /boot/kernel.old/kernel load /boot/kernel.old/opensolaris.ko load /boot/kernel.old/zfs.ko boot When I need to get back to the prior version of the kernel. Is there a way to make this work even without the beastie menu? A way to interrupt the boot before kernel load (even holding down a key) would be really valuable, even on systems that do not support fancy terminals with colors and such. -Nathan ___ 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: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Nov 5, 2013, at 9:28 AM, Nathan Whitehorn wrote: On 11/05/13 11:06, Kurt Lidl wrote: You can try enabling the beastie menu on sparc64 by editing /boot/loader.rc: === Change #1 in /boot/loader.rc to enable beastie menu === Find: \ Reads and processes loader.conf variables \ NOTE: Change to `initialize' if you enable the below boot menu start Change start to initialize as shown below: \ Reads and processes loader.conf variables \ NOTE: Change to `initialize' if you enable the below boot menu initialize === Change #2 in [same file] to enable beastie menu === Find: \ Uncomment to enable boot menu \ include /boot/beastie.4th \ beastie-start Uncomment beastie-start as shown below: \ Uncomment to enable boot menu \ include /boot/beastie.4th beastie-start == If you find that making those two trivial changes, that you are able to load the menu... then maybe it's time for us to start thinking about enabling the beastie menu by-default for the sparc64 architecture. Seems to work just fine. I tested by booting, toggling through the different kernel choices (/boot/kernel/kernel /boot/kernel.old/kernel) and both worked correctly. (Although I uncommented the include /boot/beastie.4th line too.) Does anybody else have any thoughts on enabling it for sparc64? Well, I'd probably be in support of this change - it sure beats having to interrupt the normal boot sequence and typing: unload load /boot/kernel.old/kernel load /boot/kernel.old/opensolaris.ko load /boot/kernel.old/zfs.ko boot When I need to get back to the prior version of the kernel. Is there a way to make this work even without the beastie menu? A way to interrupt the boot before kernel load (even holding down a key) would be really valuable, even on systems that do not support fancy terminals with colors and such. Nathan, Can you drop into your /boot/loader.conf: loader_delay=3 And reboot? I'm trying to think how we could use that to our advantage. I'm interested in creative applications thereof. For more skinny on what that does... man delay.4th, it spills the beans on a delayed command execution module that I added a few years ago. For example... Here's my idea of making things easier on the user that wants to load a different kernel, but *without* using a menu... 1. We have loader_delay default to 3 2. Dots are displayed for 3 seconds before we do anything (like load a kernel) 3. User presses ENTER during those 3 seconds, and the delay is truncated 4. User presses Ctrl-C during those 3 seconds (or ESC) and they get a prompt (before the kernel has loaded). Then here's what I would do (as to not have to load separate modules)... set kernel=kernel.old boot + The forth code figures out that the kernel is in /boot + If loader.conf had opensolaris_load=YES and + zfs_load=YES then the forth code also loads those from kernel.old But let's say loader.conf was bare, you could do: set kernel=kernel.old set opensolaris_load=YES set zfs_load=YES boot NB: The reason this works is because you would not call start in your loader.rc (which actually loads things), but instead initialize (which only loads loader.conf et. al.) followed by dc_execute to fire off autoboot in 3 seconds (with the aforementioned allowed interrupt ability). Is that what you were thinking? Will that work? Bonus: It would be extremely trivial to implement. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Nov 5, 2013, at 9:53 AM, Teske, Devin wrote: On Nov 5, 2013, at 9:28 AM, Nathan Whitehorn wrote: On 11/05/13 11:06, Kurt Lidl wrote: You can try enabling the beastie menu on sparc64 by editing /boot/loader.rc: === Change #1 in /boot/loader.rc to enable beastie menu === Find: \ Reads and processes loader.conf variables \ NOTE: Change to `initialize' if you enable the below boot menu start Change start to initialize as shown below: \ Reads and processes loader.conf variables \ NOTE: Change to `initialize' if you enable the below boot menu initialize === Change #2 in [same file] to enable beastie menu === Find: \ Uncomment to enable boot menu \ include /boot/beastie.4th \ beastie-start Uncomment beastie-start as shown below: \ Uncomment to enable boot menu \ include /boot/beastie.4th beastie-start == If you find that making those two trivial changes, that you are able to load the menu... then maybe it's time for us to start thinking about enabling the beastie menu by-default for the sparc64 architecture. Seems to work just fine. I tested by booting, toggling through the different kernel choices (/boot/kernel/kernel /boot/kernel.old/kernel) and both worked correctly. (Although I uncommented the include /boot/beastie.4th line too.) Does anybody else have any thoughts on enabling it for sparc64? Well, I'd probably be in support of this change - it sure beats having to interrupt the normal boot sequence and typing: unload load /boot/kernel.old/kernel load /boot/kernel.old/opensolaris.ko load /boot/kernel.old/zfs.ko boot When I need to get back to the prior version of the kernel. Is there a way to make this work even without the beastie menu? A way to interrupt the boot before kernel load (even holding down a key) would be really valuable, even on systems that do not support fancy terminals with colors and such. Nathan, Can you drop into your /boot/loader.conf: loader_delay=3 And reboot? I'm trying to think how we could use that to our advantage. I'm interested in creative applications thereof. For more skinny on what that does... man delay.4th, it spills the beans on a delayed command execution module that I added a few years ago. For example... Here's my idea of making things easier on the user that wants to load a different kernel, but *without* using a menu... 1. We have loader_delay default to 3 2. Dots are displayed for 3 seconds before we do anything (like load a kernel) 3. User presses ENTER during those 3 seconds, and the delay is truncated 4. User presses Ctrl-C during those 3 seconds (or ESC) and they get a prompt (before the kernel has loaded). Then here's what I would do (as to not have to load separate modules)... set kernel=kernel.old boot + The forth code figures out that the kernel is in /boot + If loader.conf had opensolaris_load=YES and + zfs_load=YES then the forth code also loads those from kernel.old But let's say loader.conf was bare, you could do: set kernel=kernel.old set opensolaris_load=YES set zfs_load=YES boot NB: The reason this works is because you would not call start in your loader.rc (which actually loads things), but instead initialize (which only loads loader.conf et. al.) followed by dc_execute Err, dc_execute is what I called it nearly a decade ago when I first wrote it at $work. I forgot that I renamed it to delay_execute (used to be dc_execute for delayed-command execute). to fire off autoboot in 3 seconds (with the aforementioned allowed interrupt ability). Is that what you were thinking? Will that work? Bonus: It would be extremely trivial to implement. I wipped up a patch... (and tested it about 12 different ways) See attached patch.txt. It should achieve what you're looking for. I was able to trim down Kurt's process from 6 steps: 1. Escape 10-second autoboot 2. unload 3. load /boot/kernel.old/kernel 4. load /boot/kernel.old/opensolaris.ko 5. load /boot/kernel.old/zfs.ko 6. boot To simply 2 (with loader_delay=3 in loader.conf(5)): 1. Escape new 3-second delay 2. boot kernel.old No beastie menu. Will this work? -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. Index: sys/boot/forth/beastie.4th === --- sys/boot/forth/beastie.4th (revision 257650) +++ sys/boot/forth/beastie.4th (working copy) @@ -28,8 +28,6 @@ marker task-beastie.4th -include /boot/delay.4th - only forth definitions also
Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Nov 2, 2013, at 1:45 AM, Sam Fourman Jr. wrote: On Sat, Nov 2, 2013 at 7:09 AM, Teske, Devin Devin.Teske at fisglobal.com wrote: Hi all, Here's a chance to test out the kernel selection menu enhancements to the boot loader menu before they go into HEAD. Discussion welcome, feedback desired. No recompile needed, just drop the new forth files onto a HEAD or stable/9 box and reboot. -- Cheers, Devin where are the forth files in question? D'Oh! Here they are: http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/ Supplied as patches to either stable/9 or head. -- Devin Hmmm. I saw no appreciable changes to behavior when I patched all the files in /boot with these versions. This was on a sparc64 host running 10-BETA3 (compile this morning). Notably, the kernel and modules still loaded before presenting me with the option to tell it which kernel to load: Executing last command: boot /pci@1f,0/pci@1/scsi@8/disk@0,0:a Boot device: /pci@1f,0/pci@1/scsi@8/disk@0,0:a File and args: FreeBSD/sparc64 ZFS boot block Boot path: /pci@1f,0/pci@1/scsi@8/disk@0,0:a Consoles: Open Firmware console \ FreeBSD/sparc64 ZFS enabled bootstrap loader, Revision 1.0 (r...@snap.freebsd.org, Sun Oct 27 07:20:42 UTC 2013) bootpath=zfs:sys/ROOT/default: Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x8d54c0+0x66180 syms=[0x8+0x954f0+0x8+0x8d7ef] /boot/kernel/zfs.ko text=0x223328 data=0xa4e0+0x17fc0 syms=[0x8+0x197b8+0x8+0x143f8] loading required module 'opensolaris' /boot/kernel/opensolaris.ko text=0x3130 data=0x2c8+0x2030 syms=[0x8+0xd98+0x8+0x929] /boot/kernel/geom_mirror.ko text=0x38430 data=0x5b0+0x20 syms=[0x8+0x16b0+0x8+0x119e] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... -Kurt ___ 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: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Nov 4, 2013, at 2:43 PM, Kurt Lidl wrote: On Nov 2, 2013, at 1:45 AM, Sam Fourman Jr. wrote: On Sat, Nov 2, 2013 at 7:09 AM, Teske, Devin Devin.Teske at fisglobal.com wrote: Hi all, Here's a chance to test out the kernel selection menu enhancements to the boot loader menu before they go into HEAD. Discussion welcome, feedback desired. No recompile needed, just drop the new forth files onto a HEAD or stable/9 box and reboot. -- Cheers, Devin where are the forth files in question? D'Oh! Here they are: http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/ Supplied as patches to either stable/9 or head. -- Devin Hmmm. I saw no appreciable changes to behavior when I patched all the files in /boot with these versions. This was on a sparc64 host running 10-BETA3 (compile this morning). Excellent! Thank you for testing. NB: That's what *should* happen on sparc64 since that architecture doesn't actually enable the beastie menu (sad, I know... I wish that the beastie menu was active on all platforms by default). Notably, the kernel and modules still loaded before presenting me with the option to tell it which kernel to load: Executing last command: boot /pci@1f,0/pci@1/scsi@8/disk@0,0:a Boot device: /pci@1f,0/pci@1/scsi@8/disk@0,0:a File and args: FreeBSD/sparc64 ZFS boot block Boot path: /pci@1f,0/pci@1/scsi@8/disk@0,0:a Consoles: Open Firmware console \ FreeBSD/sparc64 ZFS enabled bootstrap loader, Revision 1.0 (r...@snap.freebsd.org, Sun Oct 27 07:20:42 UTC 2013) bootpath=zfs:sys/ROOT/default: Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x8d54c0+0x66180 syms=[0x8+0x954f0+0x8+0x8d7ef] /boot/kernel/zfs.ko text=0x223328 data=0xa4e0+0x17fc0 syms=[0x8+0x197b8+0x8+0x143f8] loading required module 'opensolaris' /boot/kernel/opensolaris.ko text=0x3130 data=0x2c8+0x2030 syms=[0x8+0xd98+0x8+0x929] /boot/kernel/geom_mirror.ko text=0x38430 data=0x5b0+0x20 syms=[0x8+0x16b0+0x8+0x119e] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... You can try enabling the beastie menu on sparc64 by editing /boot/loader.rc: === Change #1 in /boot/loader.rc to enable beastie menu === Find: \ Reads and processes loader.conf variables \ NOTE: Change to `initialize' if you enable the below boot menu start Change start to initialize as shown below: \ Reads and processes loader.conf variables \ NOTE: Change to `initialize' if you enable the below boot menu initialize === Change #2 in [same file] to enable beastie menu === Find: \ Uncomment to enable boot menu \ include /boot/beastie.4th \ beastie-start Uncomment beastie-start as shown below: \ Uncomment to enable boot menu \ include /boot/beastie.4th beastie-start == If you find that making those two trivial changes, that you are able to load the menu... then maybe it's time for us to start thinking about enabling the beastie menu by-default for the sparc64 architecture. Does anybody else have any thoughts on enabling it for sparc64? -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Nov 2, 2013, at 8:27 PM, Artem Belevich wrote: On Sat, Nov 2, 2013 at 9:47 AM, Teske, Devin devin.te...@fisglobal.com wrote: where are the forth files in question? D'Oh! Here they are: https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0Am=LikaP7fhAuWFwcCB34idLlWshVBNdWkfLMLvZ5MEnX8%3D%0As=3d2d4cfda3daa8bd25f165bb1622cf30975b89ae1bbcaea301da0b8e2f5b00f8 Supplied as patches to either stable/9 or head. -- Devin Thanks for the patches. Tried on stable/9 and they worked great for me. Do you have anything similar to select boot environment as well? You're right to assume that these patches are actually an incremental step in that direction (that is to say, that it's silly to load a kernel before the menu if the menu will allow you to select an ad hoc root device). So indeed, the next step is to allow selecting your root device (be it a ZFS snapshot or alternate root for whatever purpose). I've been giving some thought to this one... and I'm actually thinking about writing this one as an FICL call-out (that is to say, written in the C code of the loader which is then invoked by the Forth code). I have already done mockups for this, but it will take some time before you see a worthy patchset (think 10.1). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. signature.asc Description: Message signed with OpenPGP using GPGMail
[CFT] Kernel-Selection Enhancemnt to Boot Menu
Hi all, Here's a chance to test out the kernel selection menu enhancements to the boot loader menu before they go into HEAD. Discussion welcome, feedback desired. No recompile needed, just drop the new forth files onto a HEAD or stable/9 box and reboot. -- Cheers, Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Sat, Nov 2, 2013 at 7:09 AM, Teske, Devin devin.te...@fisglobal.comwrote: Hi all, Here's a chance to test out the kernel selection menu enhancements to the boot loader menu before they go into HEAD. Discussion welcome, feedback desired. No recompile needed, just drop the new forth files onto a HEAD or stable/9 box and reboot. -- Cheers, Devin where are the forth files in question? -- Sam Fourman Jr. ___ 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: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Nov 2, 2013, at 1:45 AM, Sam Fourman Jr. wrote: On Sat, Nov 2, 2013 at 7:09 AM, Teske, Devin devin.te...@fisglobal.com wrote: Hi all, Here's a chance to test out the kernel selection menu enhancements to the boot loader menu before they go into HEAD. Discussion welcome, feedback desired. No recompile needed, just drop the new forth files onto a HEAD or stable/9 box and reboot. -- Cheers, Devin where are the forth files in question? D'Oh! Here they are: http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/ Supplied as patches to either stable/9 or head. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Sat, Nov 2, 2013 at 12:47 PM, Teske, Devin devin.te...@fisglobal.comwrote: On Nov 2, 2013, at 1:45 AM, Sam Fourman Jr. wrote: On Sat, Nov 2, 2013 at 7:09 AM, Teske, Devin devin.te...@fisglobal.com wrote: Hi all, Here's a chance to test out the kernel selection menu enhancements to the boot loader menu before they go into HEAD. Discussion welcome, feedback desired. No recompile needed, just drop the new forth files onto a HEAD or stable/9 box and reboot. -- Cheers, Devin where are the forth files in question? D'Oh! Here they are: http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/ Supplied as patches to either stable/9 or head. patched the bootloader, seems to function well, love the kernel selection variable -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Sat, Nov 2, 2013 at 9:47 AM, Teske, Devin devin.te...@fisglobal.com wrote: where are the forth files in question? D'Oh! Here they are: http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/ Supplied as patches to either stable/9 or head. -- Devin Thanks for the patches. Tried on stable/9 and they worked great for me. Do you have anything similar to select boot environment as well? --Artem ___ 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
