Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I read the LFS page that you liked and it looks right what you have.
There may be an unresolved issue, yes:- (it's starting to seem that way)
Since the LFS boot directory copied ok and the system.map is correct, I'm not sure what else it could be.
Maybe other members that are good with LFS will see your thread and chime in.
IF you are still having trouble booting via the cmd-line maybe using Grub to get LFS will work?
(just an idea) You don't have to use Grub is you don't want to. http://www.linuxfromscratch.org/lfs/...er08/grub.html
Sorry to hear your still having trouble.
I'm nearing the end of what else I can think of that you could try and what the issue is.
I think it's best to be honest with you.
Ok, so I checked /etc/fstab for the LFS system and realized that I hadn't provided a line for the /boot partition (/dev/sda2), which is obviously why klogd couldn't find the map file. So, I added that and rebooted, now I am getting the following messages:
Quote:
Oct 9 17:24:17 <lee_lfs> kernel: klogd 1.5.1, log source = /proc/kmsg started.
Oct 9 17:24:17 <lee_lfs> kernel: Inspecting /boot/System.map
Oct 9 17:24:17 <lee_lfs> kernel: Cannot find map file.
Oct 9 17:24:17 <lee_lfs> kernel: Loaded 100800 symbols from 32 modules.
Oct 9 17:24:17 <lee_lfs> kernel: [ 0.000000] random: get_random_bytes called from start_kernel+0x30/0x3bc with crng_init=0
Oct 9 17:24:17 <lee_lfs> kernel: [ 0.000000] Linux version 4.13.1-gnu (nobody@lee-LibreBook) (gcc version 7.2.0 (GCC)) #1 SMP PREEMPT Mon Oct 9 13:39:53 EDT 2017
So, that second line suggests that it is now looking at the System.map file on the disk; although, the next line down says that there is still some issue. Btw, this only worked if I renamed the map file to 'System.map', which is consistent with the man page for klogd, which has no mention of any System.map-<version> file.
Quote:
Originally Posted by Ztcoracat
I'm nearing the end of what else I can think of that you could try and what the issue is.
I think it's best to be honest with you.
Sure, I understand. You've already helped me a lot, which I very much appreciate. I might still post some more updates on here though, in case anyone else has seen these issues before and has any suggestions. Thanks! :-)
Sure, I understand. You've already helped me a lot, which I very much appreciate. I might still post some more updates on here though, in case anyone else has seen these issues before and has any suggestions. Thanks! :-)
You are very Welcome:-
I read through my kernel notes and found this: (not sure if it helps or applies)
If the kernel was the same as the stock kernel you must set the local version option found in "General Setup" submenu.
Failure to set this will result in your kernel compile over writing all the mods and render the system unbootable.
I just want to post a quick update on this thread:
I've been investigating further and digging through the source code for klogd, to see what is happening here. The 'Inspecting ...' line in the log file does indeed mean that klogd has found the map file and successfully opened it. However, it seems to be rejecting the System.map file because it does not contain a line in the form:
Code:
[address] [type] Version_XXXXX
(where 'XXXXX' is the version of the kernel, encoded in base 256).
klogd is looking for this line to verify that the map file is the same version as the running kernel, and is rejecting the file because it can't find it.
So, does anyone know what might be causing this, or has anyone encountered a similar issue before?
Do your System.map files include this 'version' line?
Everyone that I've spoken to about this that has checked their map file has also not found any such 'version' line that klogd is looking for. So far, I have yet to find a map file that does include it, which seems strange, as there is no way that klogd would accept any map file without it (at least, not the version of klogd that is recommended (1.5.1) in the most recent LFS release).
I think it's time to take this to the kernel devs and ask them what's going on. Perhaps they changed the way the map file works at some point and klogd wasn't updated?
I don't know any kernel developers personally that you can get in touch with..... so you'll probably have to start with the King, Linus Torvalds and his team. https://www.facebook.com/public/Linus-Torvalds
Thanks for the advice, Ztcoracat. I will try to get in touch with King Linus and the dev team, although it might be a little tricky to get his attention, as I'm sure he gets about a bazillion e-mails a day ...
The thing I'm wondering is that: ok, SysVinit is pretty old now and it's not used much any more in 'production' distros. But, if that version line has been removed from System.map, then how are the more modern init systems verifying that the map file is the same version as the running kernel? Are they just relying on the file name?
I added a 'dummy' version line to the start of my System.map file:
Code:
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:
Code:
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.
I also figured out why my kernel wasn't booting up. It seems that the framebuffer device wasn't properly configured, so I double-checked those settings again and now it boots up fine into the login prompt. Man, the word 'login' never looked so sweet!
I think it was actually trying to boot up and give me the prompt all along - the framebuffer was the only thing that wasn't working, so nothing was showing on the screen. I also verified that it does boot up, even with no System.map file
at all. However, it is probably still worth looking into that issue.
Thanks for the advice, Ztcoracat. I will try to get in touch with King Linus and the dev team, although it might be a little tricky to get his attention, as I'm sure he gets about a bazillion e-mails a day ...
The thing I'm wondering is that: ok, SysVinit is pretty old now and it's not used much any more in 'production' distros. But, if that version line has been removed from System.map, then how are the more modern init systems verifying that the map file is the same version as the running kernel? Are they just relying on the file name?
This needs to be dug into some more.
I honestly don't know how the modern inti systems verifies the map file now that systemd has pretty much taken over.
And, I agree completely this area does need to be dug into more. Good luck getting a hold of Linus and his team.
Maybe have a look at the initialization script that runs at start up after the kernel boots?
(maybe there is clue there)
Hi, I wanted to post an update on this issue. I was able to contact one of the kernel developers via the 'linux-kernel' mailing list. He looked into it and apparently there was a change made somewhere around kernel version 2.6.27, where that version line is only printed in the System.map file if the CONFIG_KALLSYMS option is *not* enabled. With my kernel (and probably most others by default) it was enabled, which meant that klogd wouldn't accept the map file.
He said that, as far as he is concerned, he would be happy for it to be changed so the version line is always included (after all, it is just one line of text). He didn't guarantee that it will make into the next released version, but hopefully it will. In the meantime, disabling CONFIG_KALLSYMS should cause that version line to print, if needed.
Hi, I wanted to post an update on this issue. I was able to contact one of the kernel developers via the 'linux-kernel' mailing list. He looked into it and apparently there was a change made somewhere around kernel version 2.6.27, where that version line is only printed in the System.map file if the CONFIG_KALLSYMS option is *not* enabled. With my kernel (and probably most others by default) it was enabled, which meant that klogd wouldn't accept the map file.
He said that, as far as he is concerned, he would be happy for it to be changed so the version line is always included (after all, it is just one line of text). He didn't guarantee that it will make into the next released version, but hopefully it will. In the meantime, disabling CONFIG_KALLSYMS should cause that version line to print, if needed.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.