Are they really identical?
The built-in one you can find in /usr/src/linux/usr/initramfs_data.cpio.gz
or extract it from the bzImage as described here: https://wiki.gentoo.org/wiki/Custom_Initramfs#Salvaging
If you use that built-in one and use it as external one instead, does it work?
If it's still different, is the kernel itself identical? (compare /proc/config.gz
for both)
There should be some difference. I'm not aware that the kernel cares where the initramfs came from. I'd sooner suspect qemu
of using different settings when passing the -initrd
parameter...
On a sidenote, your /init
looks like its spawning infinite shells to me. setsid
is not exec
. Am I wrong?
So, I've been digging through the source code for klogd, and I think I know what the answer is:
Firstly, the Inspecting ...
line does indeed mean that klogd has found the map file in that location and has successfully opened it.
However, the reason it is printing the Cannot find map file.
line is because it is looking for a line in the map file of the form:
[address] [type] _Version_XXXXX
where 'XXXXX' is the kernel version, encoded in base 256.
However, this version line is not present in any of the map files that have been generated during my kernel build (nor in the map files that are supplied with my pre-packaged Trisquel installation). So, because it can't find this version line, klogd is rejecting the map file.
Obviously, this leads to further questions, though ...
Edit: I have created these follow-on questions:
How big a problem is 'Cannot find map file.' boot message?
Why does my System.map file not contain a 'Version_XXXXX' line?
Edit: I added a 'dummy' version line to the start of my System.map file:
0FFFFFFFFFFFFFFF d Version_265223
The address is one that shouldn't exist in the virtual memory map (so hopefully shouldn't interfere or clash with any other symbols in the file). '265223' is my kernel version (4.12.7) encoded in base 256. I now get the following in my kern.log file on booting:
Nov 3 19:12:02 <lee_lfs> kernel: klogd 1.5.1, log source = /proc/kmsg started.
Nov 3 19:12:02 <lee_lfs> kernel: Inspecting /boot/System.map-4.12.7
Nov 3 19:12:02 <lee_lfs> kernel: Loaded 86148 symbols from /boot/System.map-4.12.7.
Nov 3 19:12:02 <lee_lfs> kernel: Symbols match kernel version 4.12.7.
Nov 3 19:12:02 <lee_lfs> kernel: Loaded 11257 symbols from 31 modules.
So it seems to have worked - klogd finally recognized the map file! The kernel still didn't boot up, although that is probably due to another problem, which I'll have to look into next. This seems to work as a temporary fix for now; however, I will contact the kernel dev team to see what is going on with this.
Best Answer
/etc/init.d/rcS
allows you to run additional programs at boot time. Its typical use is to mount additional filesystems (only the root filesystem is mounted at that point) and launch some daemons.Usually
rcS
is a shell script, which can easily be customized on the fly. Typical distributions makercS
a simple script that executes further scripts in/etc/rcS.d
(the exact location is distribution-dependent); this allows each daemon to be package with its own init script. The file/etc/rc.local
is also executed byrcS
if present; it is intended for commands written by the system administrator.With the traditional SysVinit implementation of init,
/etc/init.d/rcS
is listed in/etc/inittab
(thesysinit
setting). With BusyBox, you can also supply aninittab
(if the feature is compiled in) but there is a built-in default that makes it read/etc/init.d/rcS
(among other things).