OpenBSD Journal

Kernel Config Recovery

Contributed by jose on from the rm--f- dept.

have you ever wiped your kernel config accidentally? this can hurt, especially when you've spent a lot of time optimizing it, paring it down or pimping it up. how can you recover this from a running kernel? read on ...

while its easy to make an offsite backup of your config, or maybe you even store it in CVS, but if you haven't, what can you do? i have been able to only find two ways to do this, and i'm looking to see if the userbase knows of more.

the first is to use dmassage , which can parse the output of dmesg and produce a device tree.

the second is to manually rebuild the device and option list from config -e /bsd , which produces output like this: 



$ config -e /bsd                                                               
OpenBSD 3.1-current (TANK) #1: Thu Apr 18 21:25:53 EDT 2002
    jose@tank:/usr/src/sys/arch/i386/compile/TANK
warning: no output file specified
Enter 'help' for information
ukc> list
  0 audio* at clct* flags 0x0
  1 nsphy* at aue*|fxp*|fxp*|ep0|ep0|ep0|ep*|ep*|ep*|ep* phy -1 flags 0x0
  2 nsphyter* at aue*|fxp*|fxp*|ep0|ep0|ep0|ep*|ep*|ep*|ep* phy -1 flags 0x0
  3 qsphy* at aue*|fxp*|fxp*|ep0|ep0|ep0|ep*|ep*|ep*|ep* phy -1 flags 0x0
  4 inphy* at aue*|fxp*|fxp*|ep0|ep0|ep0|ep*|ep*|ep*|ep* phy -1 flags 0x0
[snip]
however, each method means you can lose vital information, like the number of pty's or psuedo-devices you created, the amount of kernel memory you may have allocated, or the like.

have any of you been able to nearly completely recover your kernel config from a running system?

(Comments are closed)

Comments

  1. By Anonymous Coward () on

    It's called a backup.

    Comments

    1. By Anonymous Coward () on

      No, better practice is called "running GENERIC whenever we can get away with it" :)

      Comments

      1. By Anonymous Coward () on

        As long as you aren't an OpenBSD developer, I don't see what the harm of running a non-generic kernel is. What's the harm in not probing a bus where you know something isn't to shave a few milliseconds off your boot time? Or consider the case (which recently came up with me) of running a router with 4M of RAM - without paring the kernel down significantly, you're SOL.

        Comments

        1. By Anonymous Coward () on

          Or consider the case (which recently came up with me) of running a router with 4M of RAM

          you're also SOL if you try to handle more than a handful of states at a time.

          the reason to run GENERIC is b/c the developers will help you if you run into problems. otherwise you may be out of luck.

        2. By Anonymous Coward () on

          > I don't see what the harm of running a non-generic kernel

          The harm is that if you stumble across some bug, developers won't even look at it if you are not running GENERIC. Otherwise I agree with you - if you know what you are doing, there is no harm in building custom kernel.

          Heck, if you have a SUN4M sparc (sparc-classic and newer machines), than your performance really suffers (and developers will confirm that, since it was done intentionally) with GENERIC kernel - building a new kernel from provided SUN4M config allowes the OS to take great advantage of newer features in sparc CPUs, but makes the kernel incompatible with IPC, IPX, sparcstation1, etc.

          Comments

          1. By Anonymous Coward () on

            if you do run a reconfigured kernel and run into problems, many developers will help you, and they'll be happy to hear your reports. however, you had better be prepared to provide a LOT of info and work a LOT with a developer (or two) to figure something out. simply whining about something broken wont get you very far, but turning up a real bug is always appreciated. if all you do is say "it no worky", you're plum out of luck, as you should be. you get back when you put into the process.

        3. By Anonymous Coward () on

          Well, if you *were* supposed to only run GENERIC, why the hell *can* we configure and compile the kernel in the first place ??? duh. ..... if it was the prime objective to make everybody run GENERIC, I would not give the user the possibility to configure his own kernel.

          Comments

          1. By Anonymous Coward () on

            Well, if you *were* supposed to only run GENERIC, why the hell *can* we configure and compile the kernel in the first place ??? duh. ..... if it was the prime objective to make everybody run GENERIC, I would not give the user the possibility to configure his own kernel.

            you can do whatever you want with the code. you can print out all the source code, use it to make a paper mache statue of Natalie Portman, and jack off to it all day if you want. but when birds start to roost in the statue and crap all over it, don't go running to the developers asking how to get rid of the birds.

            Comments

            1. By Anonymous Coward () on

              I dont know about the rest of you but this post just turned me on and im making paper mache now of theo!

              Comments

              1. By s4lty l1pz () on

                mmm... make sure to include the glove-parrot! :o =D

            2. By Anonymous Coward () on

              Natalie Portman Naked and Petrified?

              (-1, Hella-not-funny)

            3. By Uh, Uh, Uh () on

              Been there, done that. In fact, my Natalie started out 3/4 scale and she's now just a little over 100% size :-) No bird crap tho, she's in-doors.

              Coupla' more months and I'll have to raise the roof. Really.

  2. By Anonymous () on

    netbsd has nice INCLUDE_CONFIG_FILE kernel option some info from options(4) manual: options INCLUDE_CONFIG_FILE Embeds the kernel config file used to define the kernel in the kernel binary itself. The embedded data also includes any files directly includedby the config file itself, e.g. GENERIC.local or std.$MACHINE. The embedded config file can be extracted from the resulting kernel by the following command:

    strings netbsd | sed -n 's/^_CFG_//p' | unvis

  3. By Marc Espie () espie@openbsd.org on mailto:espie@openbsd.org

    ... I just run GENERIC !

    which is what *ALL THE DOCUMENTATION* for OpenBSD recommends anyways, and for goot reasons.

    Comments

    1. By Anonymous Coward () on

      Allright, but if you add somethings like USER_LDT for example, why not tune the rest of it to your system too?

      Comments

      1. By Gioffreus () on

        ayup, i agree. i always keep a GENERIC kernel around just in case, but for a good while now i've run a slimmed-down custom config'd kernel.

        the first thing i always do when i install a new system is to build a new kernel. the main reason is to simply add "option BUFCACHEPERCENT=20" and remove "option LKM"... recently though, i decided to remove a bunch of drivers for things i don't have (e.g. USB devices).

        really though, the thing i don't like about GENERIC is that i don't see the point of a kernel binary that is 4.5M especially when i can easily make a config that gives a binary about 750K smaller than that.

        and everything works fine... =) no need for drivers in the kernel that you don't have hardware for... am i alone in this opinion?

        BTW, i do indeed have backups of all my kernel config changes... i wouldn't want to lose those. that would make me a sad monkey ;)
        backups are good

      2. By fansipans () on http://dub.gmu.edu/~fansipans/

        > Allright, but if you add somethings like USER_LDT for example, why not tune the rest of it to your system too?

        for me: priorities
        because if i'm messing with anything as hairy as wine (which requires USER_LDT) or new binutils to get *some new port* to use windows libraries (which requires USER_LDT) then then LAST thing i want to do is get all disco-crazy about some whacked out kernel configgin'

    2. By niekze () on

      Why don't we just use Microsoft Products, I'm sure that's what good 'ole Bill recommends. OMFG!!1 What if you have problems with your kernel and it's not GENERIC?!?!? The developers will tell you to eat a dick! Well, then see if the problem occurs with a GENERIC kernel then move on from there. Jesus Christ some of the people on here don't think things through very well. Funny thing is that these people actually think that even if you have all the stuff that you're supposed to, the developers will be eager to help you. I really see that one happening: "OpenBSD: We're Eager To Help You." I think I've done a good job of simulating the average #openbsd 'help session' on my #openbsd page.

      http://www.nothingkillsfaster.com/answers/

      funny too, if you put "OpenBSD" and "Questions" into google, it's the 1st thing that comes up. Now *that's* funny.

      Comments

      1. By Marc Espie () espie@openbsd.org on mailto:espie@openbsd.org

        Of course, you think that OpenBSD developers hang out on
        #openbsd.

        That's not true. We hang out on the mailing-lists, and
        newsgroups. And most of us usually answer questions.

        I think you are missing a point: developers are eager
        to fix *bugs* they can.

        When you've spent two hours writing a manpage, and bundling
        it in OpenBSD 3.1, do you think you're eager to answer
        a twit who comes around and asks a question whose answer
        is exactly that manpage contents ?

        Or, do you really feel like answering a question that
        amounts to the `hardware' section of the FAQ, paragraph
        NOT SUPPORTED ?

        And of course, there are cases of tough kernel problems
        that can take time to solve.

        But really, if you're not starting from GENERIC, and the
        problem doesn't occur in GENERIC, it's very likely no
        developer has the exact same configuration that you do
        and thus, no-one can help you. Because remote debugging
        is a pain in the ass, and if bloody GENERIC works for you,
        this is all the advice you'll get: tough cookies, your
        custom kernel config is broken, go back to a normal kernel
        config, we have better things to fix first.

        Comments

        1. By lack () on

          He says: "Of course, you think that OpenBSD developers hang out on #openbsd.

          That's not true. We hang out on the mailing-lists, and newsgroups. And most of us usually answer questions."

          I say: "You're wrong. Although *you* don't hang around there (at least that's what i conclude from your own words), some developers do. But then, again so what ? Are you going to punish them for using that evil thing called IRC ? And (surprise surprise) they do answer to questions, intelligent ones or not, documented ones or not."

          He says: "When you've spent two hours writing a manpage, and bundling it in OpenBSD 3.1, do you think you're eager to answer a twit who comes around and asks a question whose answer is exactly that manpage contents ?

          Or, do you really feel like answering a question that amounts to the `hardware' section of the FAQ, paragraph NOT SUPPORTED ?"

          I say: "I agree completely with you there. But then again, i see developers answering annoying questions in the mailing-lists and newsgroups that could be easily answered if the clueless user cared for some googling or some lack of lazyness. What i find funny is that the answers given (or not) really depend on the answerer's mood (yours for instance).
          So i don't criticize you for taking such an inflexible position, but sometimes accepting that OpenBSD exists also due to the users effort wouldn't hurt that much.
          Yes i know, OpenBSD isn't for idiots and lazy people, i myself advocate that, but rudeness doesn't help, though i know that patience is a finite thing."

          He says: "... custom kernel config is broken, go back to a normal kernel config, we have better things to fix first."

          I say: "True agreed, and i sign below."

          Have a nice day monsieur.

          Comments

          1. By Anonymous Coward () on

            > ...the answers given (or not) really depend on the answerer's mood (yours for instance).

            Ohhh, the mistery of Marc Espie's mood... The flow of it still can not be predicted due to the lack of computing power that is up to the task at hand.

            ;)

        2. By niekze () on

          "Or, do you really feel like answering a question that amounts to the `hardware' section of the FAQ, paragraph NOT SUPPORTED?"

          of course not. that's when you say to them: look in the FAQ, under the paragraph NOT SUPPORTED.

          Now, i'm not talking about every single developer. that's would make quite a broad generalization. I believe I did say that if someone did have a problem with a custom kernel, that they should see if the problem exists with the GENERIC kernel. Personally, I've never had any problems with custom kernels. I noticed a problem with a GENERIC kernel waaaay back in 2.7 or so, and I submitted the problem. (didn't get a response though, but i'll live) As for 2 hours writing a manpage, OpenBSD has some of the best manpages in the *nix world. I'll look at them even when I'm working on some other machine. And I really can't talk about what's going on in #openbsd, because I havn't been there in a year. Got tired of all the bullshit. My little "#openbsd questions answered" page has quite a *long* list of resources to look for OpenBSD resources. I don't ask OpenBSD questions, because I know that It is far easier to find the answer myself. But I do like the idea that someone mentioned that NetBSD can store the config in the kernel, where it can be easily extracted. That's a good idea :) Doesn't even have to be used in GENERIC, since the GENERIC config is everywhere ;) Still, if dealing with a "twit," would it be difficult to lead them to the information that solves their problem? Once you show someone how they can find the information they need, they usually stop being a "twit." ;)

      2. By Anonymous Coward () on

        mmm.... What is #openbsd?

        Seriously, if some IRC channel has "openbsd" in it's name, it does NOT mean it has ANYTHING to do with openbsd.org. It's not even mentioned anywhere on the web-site and you won't find any developers there - they are busy working on the code.

        Comments

        1. By niekze () on

          from http://www.openbsd.org/report.html

          How to create a problem report
          Always provide as much information as possible. Try to pin-point the exact problem. Never give vague instructions, or detail vague problems like "it crashes" or "I get strange interrupt issues on this one box that I built." Talk to others on IRC or some other forum to confirm that it is new, repeatable, etc. and make sure it is not a local problem

          seems you are incorrect. Take that off the page and then you will be correct, and I will have no reason to mention irc and OpenBSD in the same sentence.

          Comments

          1. By vincent labrecque () on

            wow, that was a good answer.... and if it says to ask your peers at work, and one of them doesn't want to help you adn is rude, is it also because of the FAQ?

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]