Message-ID: <1512044683.3287.9.camel@lee-LibreBook>
Date:   Thu, 30 Nov 2017 07:24:43 -0500
From:   Lee Strobel <leestrobel@...root.org>
To:     Randy Dunlap <rdunlap@...radead.org>
Cc:     linux-kernel@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Missing version line in System.map file?

> What does not having that line in the System.map file break?
> Should klogd be looking in the System.map file for a kernel version
> number? Can you make a good argument for this change?

> OTOH, all it does is add an integer variable to the kernel and one
> line to the System.map file, so if it fixes something, it shouldn't be
> a big deal.

It appears that klogd is searching the map file for that version line.
If it doesn't find it then it won't accept the map file and prints an
error message saying that it can't find it. I have to admit that I don't
know what that actually breaks - my system still booted up and seemed to
work fine, even when klogd wasn't finding the file.

But, as you say, it is just one line of text in the map file, so I would
think it would be worth including, if it helps compatibility. It also
makes sense to me, that there should be some way for an external service
to verify that the map file is the correct version (to avoid possible
confusion).

That's my take on it, anyway.

Thanks again,

Lee


On Wed, 2017-11-29 at 19:19 -0800, Randy Dunlap wrote:
> On 11/29/2017 06:56 PM, Lee Strobel wrote:
> > Hi Randy,
> > 
> > Thank you for replying to my e-mail. That is interesting and it seems to
> > explain why my map file didn't have that version line. I hadn't realized
> > that it depends on the CONFIG_KALLSYMS option (which I did indeed have
> > enabled). I am somewhat new to configuring/building the kernel and, from
> > the help description, enabling that option seemed like a good idea at
> > the time.
> 
> Yes, I agree.
> 
> > However, I think it would be good if the map file could be set to always
> > include the version line, if that would help compatibility with sysklogd
> > (and, of course, if it doesn't break anything else).
> > 
> > So, is that an easy change to make? How will I know if it gets approved
> > for the next version release?
> 
> It's easy to make the change on my system.
> It's not so easy to know if that change would be approved (merged).
> 
> What does not having that line in the System.map file break?
> Should klogd be looking in the System.map file for a kernel version number?
> Can you make a good argument for this change?
> 
> OTOH, all it does is add an integer variable to the kernel and one line to
> the System.map file, so if it fixes something, it shouldn't be a big deal.
> 
> > Also, can you tell me which kernel version that previous change was made
> > in?
> 
> Probably 2.6.27.
> 
> > Sorry for all the questions, but I haven't had any previous involvement
> > with kernel development.
> 
> No problem.
> 
> > Regards,
> > 
> > Lee
> > 
> > 
> > On Wed, 2017-11-29 at 11:31 -0800, Randy Dunlap wrote:
> >> On 11/29/2017 11:07 AM, Randy Dunlap wrote:
> >>> On 11/28/2017 07:20 PM, Lee Strobel wrote:
> >>>> Hi,
> >>>>
> >>>> I have a question about the Linux kernel, which I have been trying to
> >>>> find an answer to through various forums for some time now, but without
> >>>> success. I'm wondering if anyone on this mailing list might be able to
> >>>> help?
> >>>>
> >>>> I've been trying to build a Linux From Scratch (LFS) system, using
> >>>> SysVinit and sysklogd. However, when I tried to boot up, klogd wasn't
> >>>> accepting the System.map file, printing log messages such as:
> >>>>
> >>>>    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.
> >>>>
> >>>> So, I dug into the source code for klogd a little bit, and it appears
> >>>> the reason the map file wasn't being accepted was because it didn't
> >>>> contain a 'version' line, which klogd was looking for, in the form:
> >>>>
> >>>>    [address] [type] Version_XXXXX
> >>>>
> >>>> (where XXXXX is the kernel version # in base 256).
> >>>>
> >>>> So, I've been asking around on various forums. It seems that none of the
> >>>> map files that are being produced by more recent kernel versions include
> >>>> this line and no-one that I've spoken to on the Linux user forums seems
> >>>> to know why this is.
> >>>>
> >>>> Was a change made to the kernel, to remove this 'version' line
> >>>> from the map file? If so, how are the newer init systems verifying that
> >>>> the map file is the same version as the running kernel? Perhaps sysklogd
> >>>> needs to be updated?
> >>>>
> >>>> By the way, I tried adding a 'dummy' version line to my map file and
> >>>> klogd accepted it fine.
> >>>>
> >>>> Hopefully someone out there can assist, as no-one in the Linux user
> >>>> community seems to know what is going on with this.
> >>>>
> >>>> Best regards,
> >>>>
> >>>> Lee Strobel
> >>>> Engineer/Tinkerer/Free Software Supporter ..
> >>>
> >>> Hi,
> >>>
> >>> Having that symbol in the System.map file depends on the kernel config
> >>> symbol CONFIG_KALLSYMS.  KALLSYMS must be disabled (unset) for that
> >>> symbol to be generated.  I don't know why it's like that.
> >>>
> >>> ffffffff815e50a8 B Version_197216
> >>>
> >>> Ted, do you have any idea about that?
> >>>
> >>> thanks.
> >>
> >> ah, git log tells us:
> >>
> >> commit 197dcffc8ba0ea943fee86e28e99cd9575799772
> >> Author: Daniel Guilak <guilak@...ux.vnet.ibm.com>
> >> Date:   Fri Jul 25 01:45:50 2008 -0700
> >>
> >>     init/version.c: define version_string only if CONFIG_KALLSYMS is not defined
> >>     
> >>     int Version_* is only used with ksymoops, which is only needed (according
> >>     to README and Documentation/Changes) if CONFIG_KALLSYMS is NOT defined.
> >>     Therefore this patch defines version_string only if CONFIG_KALLSYMS is not
> >>     defined.
> >>     
> >>     Signed-off-by: Daniel Guilak <daniel@...ielguilak.com>
> >>     Cc: Randy Dunlap <randy.dunlap@...cle.com>
> >>     Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
> >>     Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
> >>
> >>
> >> I would be OK with reverting that commit so that Version_xxxxxx is
> >> always present in System.map.
> 
> 

Powered by blists - more mailing lists