Re: kernel reordering and config -e
On Wed, Nov 22, 2017 at 04:45:59PM +, Kevin Chadwick wrote: > I believe the second scenario would need /dev/mem access making it a > larger change than it first appears (config with a new option could > possibly save the original kernel file and compare the two kernel > files). Ah, I didn't mean that; I meant save your interactive 'config -e' session in a file that could be played back later. IE, you run 'config -e - /etc/ukc.conf ...', then type 'change x', 'disable y' etc, and then when you 'quit', config would write a transcript of your changes to /etc/ukc.conf such that 'config -e -
Re: kernel reordering and config -e
On Tue, 21 Nov 2017 12:41:41 -0800 > Or would you want > something more integrated into config where it would have a new > command that would generate a file based on the current session, and > a new option to process changes from a file rather than > interactively? It looks like it would be difficult to detect errors > in the first scenario, and I don't know if that would be an issue I believe the second scenario would need /dev/mem access making it a larger change than it first appears (config with a new option could possibly save the original kernel file and compare the two kernel files). -u Check to see if the kernel configuration was modified at boot- time (i.e. boot -c was used). If so, compare the running kernel with the kernel to be edited (infile). If they seem to be the same, apply all configuration changes performed at boot. Using this option requires read access to /dev/mem, which may be restricted based upon the value of the kern.allowkmem sysctl(8).
RE: kernel reordering and config -e
"Ed Hynan" wrote: > No patch from OP yet, Yeah, I'm sorry, my OpenBSD machine is currently air-gapped and is still running 6.1 :( It's been hectic IRL 'round here. > so how about this: for someone needing config -e > it's probably sufficient if /usr/libexec/reorder_kernel checks for > a post-processing script, and invokes it if present and executable. > > If the patch is acceptable, I'll post a sample post-processing script > that, for config -f -e, should only need one parameter change for > specific needs. I think that's better than my hack :) Is it really a good idea to have the kernel file name hardcoded like that? Granted, I usually use a symlink myself, but still... --schaafuit.
Re: kernel reordering and config -e
On Mon, 20 Nov 2017, Theo de Raadt wrote:
If someone wants to solve this fully there have been some proposals
for keeping track of the instruction sequence, and attempting to
reapply it upon each relink in the build directory. There just hasn't
been any scripting changes to do that from anyone, and it isn't on my
radar as important.
How about making reorder_kernel do something like:
$ if test -f /etc/ukc.conf; then
Hmm... I can't seem to find a patch in there anywhere.
No patch from OP yet, so how about this: for someone needing config -e
it's probably sufficient if /usr/libexec/reorder_kernel checks for
a post-processing script, and invokes it if present and executable.
If the patch is acceptable, I'll post a sample post-processing script
that, for config -f -e, should only need one parameter change for
specific needs.
Patch (against 6.2 stable):
--- usr/libexec/reorder_kernel.orig Tue Oct 3 23:13:27 2017
+++ usr/libexec/reorder_kernel Wed Nov 22 09:30:27 2017
@@ -30,6 +30,8 @@
LOGFILE=$COMPILE_DIR/$KERNEL/relink.log
PROGNAME=${0##*/}
SHA256=/var/db/kernel.SHA256
+# optional local postprocessing, e.g. config -e
+POSTPROC=/etc/after-karl
# Create kernel compile dir and redirect stdout/stderr to a logfile.
mkdir -m 700 -p $COMPILE_DIR/$KERNEL
@@ -55,6 +57,11 @@
cd $COMPILE_DIR/$KERNEL
make newbsd
make newinstall
+
+# optional local postprocessing, e.g. config -e
+if [[ -f $POSTPROC && -x $POSTPROC ]]; then
+ "$POSTPROC" /bsd "$SHA256" /dev/stdout
+fi
echo "\nKernel has been relinked and is active on next reboot.\n"
cat $SHA256
Re: kernel reordering and config -e
On Tue, Nov 21, 2017 at 09:49:37AM +, Dimitris Papastamos wrote: > This is what I do in rc.shutdown to handle this case: > > /usr/bin/printf "disable inteldrm*\nquit\n" | /usr/sbin/config -ef /bsd > /bin/sha256 -h /var/db/kernel.SHA256 /bsd Cool, thanks for the suggestion; that should be good as long as the box doesn't panic or otherwise have an unclean shutdown.
Re: kernel reordering and config -e
On Mon, Nov 20, 2017 at 02:01:56PM -0700, Theo de Raadt wrote: > If someone wants to solve this fully there have been some proposals > for keeping track of the instruction sequence, and attempting to > reapply it upon each relink in the build directory. There just hasn't > been any scripting changes to do that from anyone, and it isn't on my > radar as important. Ah, rather than make binary changes to the object files that get linked, just redo the changes to the resultant kernel binary every time it is generated. That's definitely simpler to do with the existing tools. I see someone made a suggestion that you replied to with a classic "where's the patch" :), I don't think he was suggesting someone else do it but more looking for guidance on what you'd considerable acceptable before spending time on it. For example, would the basic "user manually constructs a text file with config commands by hand that then just gets passed to config on stdin" approach he mentioned be good enough to commit? Or would you want something more integrated into config where it would have a new command that would generate a file based on the current session, and a new option to process changes from a file rather than interactively? It looks like it would be difficult to detect errors in the first scenario, and I don't know if that would be an issue. Thanks...
Re: kernel reordering and config -e
On Sun, Nov 19, 2017 at 07:31:20PM -0800, Paul B. Henson wrote: > I just updated a server to 6.2; unfortunately this box has an oddball > SOL com2 on irq10 so I need to run 'config -e' on the kernel to update > it and make the serial console work. I noticed afterwards in the boot > messages it was complaining about kernel reordering failures, and > thinking I was fixing it, I updated the file /var/db/kernel.SHA256 with > the hash of my modified kernel. I quickly discovered that resulted in a > successfully reordered kernel with a stock com2 irq :(. > > I didn't see anything in the config man page or faq about interaction > between kernel reordering and config on a binary kernel. In hindsight I > see that the hash check is to keep from replacing a locally modified > kernel. Is there a supported way to both fix hardcoded settings on a > stock kernel and use reordering? Or do you need to update your settings > in the config and compile a kernel from scratch? If you do, does > /usr/share/compile automatically get populated with your new kernel > objects and reordering just starts working, or do you need to do > something manually to get it running with a locally compiled kernel? This is what I do in rc.shutdown to handle this case: /usr/bin/printf "disable inteldrm*\nquit\n" | /usr/sbin/config -ef /bsd /bin/sha256 -h /var/db/kernel.SHA256 /bsd
RE: kernel reordering and config -e
theo wrote: > Hmm... I can't seem to find a patch in there anywhere. I'll read that as 'proposal accepted', and will try and provide a patch soon. --schaafuit.
Re: RE: kernel reordering and config -e
> > If someone wants to solve this fully there have been some proposals > > for keeping track of the instruction sequence, and attempting to > > reapply it upon each relink in the build directory. There just hasn't > > been any scripting changes to do that from anyone, and it isn't on my > > radar as important. > > How about making reorder_kernel do something like: > > $ if test -f /etc/ukc.conf; then
RE: kernel reordering and config -e
theo wrote: > If someone wants to solve this fully there have been some proposals > for keeping track of the instruction sequence, and attempting to > reapply it upon each relink in the build directory. There just hasn't > been any scripting changes to do that from anyone, and it isn't on my > radar as important. How about making reorder_kernel do something like: $ if test -f /etc/ukc.conf; then
Re: kernel reordering and config -e
> On Mon, Nov 20, 2017 at 08:37:43AM +, Roderick wrote: > > > Commenting out the line "/usr/libexec/reorder_kernel &" at the > > end of rc? > > > > I suspect it is not forseen not to benefice of KARL. > > No, actually, if the hash of the kernel is different than expected, the > reorder_kernel aborts and doesn't generate a new one. So you don't need > to do anything explicitly after the config -e to avoid your change being > wiped out. What I did was update the saved hash with one matching my > modified kernel (not quite understanding what was going on yet) which > caused KARL to wipe my changes out with the default. Correct. If you use config -e, you disable KARL. If you disable KARL, the change sticks. But KARL is disabled. If someone wants to solve this fully there have been some proposals for keeping track of the instruction sequence, and attempting to reapply it upon each relink in the build directory. There just hasn't been any scripting changes to do that from anyone, and it isn't on my radar as important.
Re: kernel reordering and config -e
On Mon, Nov 20, 2017 at 08:37:43AM +, Roderick wrote: > Commenting out the line "/usr/libexec/reorder_kernel &" at the > end of rc? > > I suspect it is not forseen not to benefice of KARL. No, actually, if the hash of the kernel is different than expected, the reorder_kernel aborts and doesn't generate a new one. So you don't need to do anything explicitly after the config -e to avoid your change being wiped out. What I did was update the saved hash with one matching my modified kernel (not quite understanding what was going on yet) which caused KARL to wipe my changes out with the default.
RE: kernel reordering and config -e
Hi, "Paul B. Henson" wrote: > Or do you need to update your settings > in the config and compile a kernel from scratch? If you do, does > /usr/share/compile automatically get populated with your new kernel > objects and reordering just starts working, or do you need to do > something manually to get it running with a locally compiled kernel? A hack that might work is to ensure that the config -e is done each time after the reorder, and the checksum updated for the next time 'round. If the power ever goes off between the two passes, though, you'll probably end up with the situation you bumped into now. --schaafuit.
Re: kernel reordering and config -e
On Mon, 20 Nov 2017, Sebastien Marie wrote: config -e and KARL (kernel reordering) are mutually incompatibles. [...] So currently, you have to choose between: - modifying /bsd with config(8) and don't benefice of KARL Commenting out the line "/usr/libexec/reorder_kernel &" at the end of rc? I suspect it is not forseen not to benefice of KARL. Rodrigo.
Re: kernel reordering and config -e
On Sun, Nov 19, 2017 at 10:19:05PM -0800, Paul B. Henson wrote: > On Mon, Nov 20, 2017 at 06:50:30AM +0100, Sebastien Marie wrote: > > > For me, there is currently no way to ask config(8) to alter the right > > file in /usr/share/relink/kernel to "ship" the modification in all > > future generated KARL kernels. > > I thought that might be the case; maybe someday config(8) will be > extended to work with the object files as well as the kernel binary > itself to allow that. I think it should be possible, but it isn't trivial to implement as it is a binary editing. It needs to locate proper offset of a symbol inside ELF file, and make changes. > > - makes your changes in /usr/src/sys, build and install a new no-GENERIC > > kernel (and do it at each upgrade) > > If I do that, can the resultant object files (which will have my com2 > irq change) be used with KARL? Hmm, it seems like all I really need to > do is compile a new com_isa.o and drop it in to the existing directory? > Or replace whichever object file contains the constant I need to change; > it's not like I'm modifying code or making any drastic changes... Hmm, As long you use standard "make install" to install the kernel, it will do all the stuff for you: installing the /bsd file and generating KARL files for the next boot. > I'll have to compile a new kernel and poke at it; it'll just be a matter > of remembering to redo it after patches, but I already had to redo the > config -e anyway. I use config(8) for some hosts using cupsd with usb printers, so I need to do config(8) stuff each time I upgrade (disabling ulpt(4)). It could be easily instrumented in /upgrade.site. Recompiling a kernel is a more complex task, not really doable in /upgrade.site. -- Sebastien Marie
Re: kernel reordering and config -e
On Mon, Nov 20, 2017 at 06:50:30AM +0100, Sebastien Marie wrote: > When it did that, it uses the object (I didn't recall the exact name) > with the previous mentioned array, with *default* configuration. So the > previous modification done with config(8) is cleared. Yeah, I figured that out after I updated the saved KARL hash and then my box came up with no serial console :). > For me, there is currently no way to ask config(8) to alter the right > file in /usr/share/relink/kernel to "ship" the modification in all > future generated KARL kernels. I thought that might be the case; maybe someday config(8) will be extended to work with the object files as well as the kernel binary itself to allow that. > - makes your changes in /usr/src/sys, build and install a new no-GENERIC > kernel (and do it at each upgrade) If I do that, can the resultant object files (which will have my com2 irq change) be used with KARL? Hmm, it seems like all I really need to do is compile a new com_isa.o and drop it in to the existing directory? Or replace whichever object file contains the constant I need to change; it's not like I'm modifying code or making any drastic changes... Hmm, I'll have to compile a new kernel and poke at it; it'll just be a matter of remembering to redo it after patches, but I already had to redo the config -e anyway. Thanks...
Re: kernel reordering and config -e
On Sun, Nov 19, 2017 at 07:31:20PM -0800, Paul B. Henson wrote: > I just updated a server to 6.2; unfortunately this box has an oddball > SOL com2 on irq10 so I need to run 'config -e' on the kernel to update > it and make the serial console work. I noticed afterwards in the boot > messages it was complaining about kernel reordering failures, and > thinking I was fixing it, I updated the file /var/db/kernel.SHA256 with > the hash of my modified kernel. I quickly discovered that resulted in a > successfully reordered kernel with a stock com2 irq :(. > > I didn't see anything in the config man page or faq about interaction > between kernel reordering and config on a binary kernel. In hindsight I > see that the hash check is to keep from replacing a locally modified > kernel. Is there a supported way to both fix hardcoded settings on a > stock kernel and use reordering? Or do you need to update your settings > in the config and compile a kernel from scratch? If you do, does > /usr/share/compile automatically get populated with your new kernel > objects and reordering just starts working, or do you need to do > something manually to get it running with a locally compiled kernel? > config -e and KARL (kernel reordering) are mutually incompatibles. By using config -e, you modify /bsd: config(8) did a binary change in a particular array in the kernel file (in short, the one which contains the list of drivers to load: it sets a bit to saying "disabled" for a particular driver, for example). KARL uses /usr/share/relink/kernel/*/*.o files to regenerate a new kernel (and placing objects in random order). A new /bsd file is generated using these objects. When it did that, it uses the object (I didn't recall the exact name) with the previous mentioned array, with *default* configuration. So the previous modification done with config(8) is cleared. For me, there is currently no way to ask config(8) to alter the right file in /usr/share/relink/kernel to "ship" the modification in all future generated KARL kernels. So currently, you have to choose between: - modifying /bsd with config(8) and don't benefice of KARL - have KARL and using a default kernel - makes your changes in /usr/src/sys, build and install a new no-GENERIC kernel (and do it at each upgrade) Thanks. -- Sebastien Marie
kernel reordering and config -e
I just updated a server to 6.2; unfortunately this box has an oddball SOL com2 on irq10 so I need to run 'config -e' on the kernel to update it and make the serial console work. I noticed afterwards in the boot messages it was complaining about kernel reordering failures, and thinking I was fixing it, I updated the file /var/db/kernel.SHA256 with the hash of my modified kernel. I quickly discovered that resulted in a successfully reordered kernel with a stock com2 irq :(. I didn't see anything in the config man page or faq about interaction between kernel reordering and config on a binary kernel. In hindsight I see that the hash check is to keep from replacing a locally modified kernel. Is there a supported way to both fix hardcoded settings on a stock kernel and use reordering? Or do you need to update your settings in the config and compile a kernel from scratch? If you do, does /usr/share/compile automatically get populated with your new kernel objects and reordering just starts working, or do you need to do something manually to get it running with a locally compiled kernel? Thanks...
