I'm currently trying to rebuild the kernel for a proprietary device. In order to do this I will need to produce a kernel config for the device. While I could likely do this through trial and error, it would be better to see if I can extract the config from the running host.

That being said the running kernel was not compiled with CONFIG_IKCONFIG (and thus not CONFIG_IKCONFIG_PROC either). This means that there is no /proc/config.gz to extract.

In addition, they didn't bother to package the config in /boot either. Thus, the two common places where a kernel config is generally stored are out of luck.

Most everything was compiled statically into this kernel:

 # cat /proc/modules
 linux_user_bde           12327 0                         - Live 0xf8536000 (PO)
 linux_kernel_bde         29225 1           linux_user_bde, Live 0xf8524000 (PO)
 pciDrv                    1448 0                         - Live 0xf8510000 (O)
 iTCO_wdt                  4456 0                         - Live 0xf83fb000 
 iTCO_vendor_support       2003 1                 iTCO_wdt, Live 0xf83f7000 
 i2c_dev                   5443 0                         - Live 0xf83f2000 
 i2c_i801                  9421 0                         - Live 0xf83eb000 
 i2c_core                 20859 3 i2cscan,i2c_dev,i2c_i801, Live 0xf83e0000 
 igb                     148294 0                         - Live 0xf83ae000 (O)
 dca                       4665 0                         - Live 0xf804c000 
 # ls -l /proc/conf*
 ls: /proc/conf*: No such file or directory
 # find /boot/ -name "conf*"
 # modprobe configs
 modprobe: module 'configs' not found
  • For future reference, the config might also be available at /lib/modules/$(uname -r)/config
    – 1ace
    Apr 7, 2021 at 17:56
  • 1
    The step of adding config to that path is generally a function of the underlying packaging mechanism (if one exists). Definitely an entry to add into the list of places to check but alas it wasn't on the device I'm working on (still.... almost 5 years later). Apr 14, 2021 at 22:41

2 Answers 2


One, arguably silly, idea that comes to mind is to see if you can pull the kernel's symbol table from the image or from /proc/kallsyms or somewhere, and reverse engineer at least the included drivers based on that. Though with something like 35000 symbols shown by kallsyms on a stock distribution kernel, that would require some scripting.

  • This seems like the best bet from answers provided thus far [and shows you actually read the question! :) ]. At first glance I can easily map symbols to existing modules (cat /proc/kallsyms | awk '/\[/ {print $NF}' | sort -u). There are about 53000 symbols in this kernel with ~1200 coming from the modules so there's quite a bit of work to do, but this is pretty promising. I'll dig in further and report. Aug 28, 2016 at 21:07

Non-technical answer but under the GPLv2 you are entitled to the source code and any modifications to it, as well as the configurations used to create the running version.

So, one way is to ask the makers of the "proprietary device" (if they still exist) to provide you the sources you are entitled to under the GPL.

  • 5
    Unfortunately if this was a feasible answer I wouldn't be asking on stack exchange. Aug 23, 2016 at 4:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .