Mailing List Archive

There is a lot online - basically its optional and needed just in case
(!) and should be versioned like its matching kernel and initrd.

BillK

one of many refs:
https://stackoverflow.com/questions/28936630/what-is-the-need-of-having-both-system-map-file-and-proc-kallsyms


On 1/7/21 2:59 pm, Dale wrote:
> Howdy,
>
> The subject line pretty much describes this.  How does one manage the
> system.map file in /boot?  Is it needed?  Should it be updated with each
> kernel?  I tend to keep 2 to 3 kernels installed.  I tend to keep 2 that
> I know are stable and one testing.  After a while, I may remove the
> oldest one and only have two, just in case.  Should I version the
> system.map file the same as kernels?  Does just one with no version get
> the job done?  Update the file with each kernel upgrade or install one
> and done?
>
> While at it, what does it even do?  If it needs it, it doesn't matter
> but just curious. 
>
> Thanks for any tips on this.
>
> Dale
>
> :-)  :-) 
>

Dale,

On Thursday, 2021-07-01 01:59:57 -0500, you wrote:

> ...
>
> The subject line pretty much describes this.? How does one manage the
> system.map file in /boot?? Is it needed?? Should it be updated with each
> kernel?? I tend to keep 2 to 3 kernels installed.

Same here. And whenever I configure a new kernel my kernel managing
script makes sure both, the kernel I'm currenty running on and the one
just configured are in "@world". That way "emerge --depclean" will nev-
er remove a kernel package.

When I finally decide to explicitly remove a kernel my kernel managing
script will basically execute this before calling "grub-mkconfig":

# Argument 1 must contain slot number of kernel to be removed.

emerge --deselect --quiet sys-kernel/gentoo-sources:$1
rm -fr /lib/modules/$1-gentoo /boot/*-$1-gentoo{,.old} \
/usr/src/linux-$1-gentoo

This is stuff I somewhere picked up from the Gentoo Handbook when I did
my first Gentoo install.

> ...
> ? Should I version the
> system.map file the same as kernels?

Not sure about that. Mine ARE versioned. That's probably what "grub-
mkconfig" is doing by default.

Sincerely,
Rainer

On 2021-07-01 13:16+0200 Dr Rainer Woitok <rainer.woitok@gmail.com>
wrote:

> Dale,
>
> On Thursday, 2021-07-01 01:59:57 -0500, you wrote:
>
> > ...
> >   Should I version the
> > system.map file the same as kernels?
>
> Not sure about that. Mine ARE versioned. That's probably what
> "grub- mkconfig" is doing by default.

I compile kernels with `genkernel`, and it produces versioned files:
System.map-5.4.97-gentoo-x86_64
System.map-5.10.27-gentoo-x86_64
initramfs-5.4.97-gentoo-x86_64.img
initramfs-5.10.27-gentoo-x86_64.img
vmlinuz-5.4.97-gentoo-x86_64
vmlinuz-5.10.27-gentoo-x86_64

Kind regards, tastytea

--
Get my PGP key with `gpg --locate-keys tastytea@tastytea.de` or at
<https://tastytea.de/tastytea.asc>.

tastytea wrote:
> On 2021-07-01 13:16+0200 Dr Rainer Woitok <rainer.woitok@gmail.com>
> wrote:
>
>> Dale,
>>
>> On Thursday, 2021-07-01 01:59:57 -0500, you wrote:
>>
>>> ...
>>>   Should I version the
>>> system.map file the same as kernels?
>> Not sure about that. Mine ARE versioned. That's probably what
>> "grub- mkconfig" is doing by default.
> I compile kernels with `genkernel`, and it produces versioned files:
> System.map-5.4.97-gentoo-x86_64
> System.map-5.10.27-gentoo-x86_64
> initramfs-5.4.97-gentoo-x86_64.img
> initramfs-5.10.27-gentoo-x86_64.img
> vmlinuz-5.4.97-gentoo-x86_64
> vmlinuz-5.10.27-gentoo-x86_64
>
> Kind regards, tastytea
>


This info is helpful.  I tend to do mine by hand, I may only upgrade my
kernel once, maybe twice, a year.  I don't reboot very often so there is
no point in upgrading every time a new one comes out.  After reading
this, I've copied over the proper system.map files and versioned them to
match the kernel names.  I'll run grub-mkconfig just in case shortly. 
I've always had *A* file there but never copied newer versions over
before. Honestly, I didn't know if it was needed or not.  It has a lot
of info in it tho so I figured it wise to ask. 

Thanks to all for the info.  Now I have a better understanding of what I
need to do and how.

Dale

:-)  :-) 

P. S.  Back to the woods.  Putting out fertilizer for the trees. 
Supposed to rain in the next day or so.

On Thu, 1 Jul 2021 13:16:29 +0200, Dr Rainer Woitok wrote:

> Same here. And whenever I configure a new kernel my kernel managing
> script makes sure both, the kernel I'm currenty running on and the one
> just configured are in "@world". That way "emerge --depclean" will nev-
> er remove a kernel package.

You can also do that with sets. Add this to sets.conf

[kernels]
class = portage.sets.dbapi.OwnerSet
world-candidate = False
files = /usr/src

add emerge -n @kernels once. Then depclean will never touch a kernel
source package.

> > ...
> >   Should I version the
> > system.map file the same as kernels?
>
> Not sure about that. Mine ARE versioned. That's probably what "grub-
> mkconfig" is doing by default.

grub-mkconfig only reads the files, it is the make install step of kernel
installation that takes care of copying the files to /boot with the
correct version numbers. ISTR Dale prefers to copy the kernel files
manually, which is why his System.map is not versioned.


--
Neil Bothwick

Suborbital Ballistic-Propulsion Engineer
Not Exactly A Rocket Scientist

Neil Bothwick wrote:
> On Thu, 1 Jul 2021 13:16:29 +0200, Dr Rainer Woitok wrote:
>
>> Same here. And whenever I configure a new kernel my kernel managing
>> script makes sure both, the kernel I'm currenty running on and the one
>> just configured are in "@world". That way "emerge --depclean" will nev-
>> er remove a kernel package.
> You can also do that with sets. Add this to sets.conf
>
> [kernels]
> class = portage.sets.dbapi.OwnerSet
> world-candidate = False
> files = /usr/src
>
> add emerge -n @kernels once. Then depclean will never touch a kernel
> source package.
>
>>> ...
>>>   Should I version the
>>> system.map file the same as kernels?
>> Not sure about that. Mine ARE versioned. That's probably what "grub-
>> mkconfig" is doing by default.
> grub-mkconfig only reads the files, it is the make install step of kernel
> installation that takes care of copying the files to /boot with the
> correct version numbers. ISTR Dale prefers to copy the kernel files
> manually, which is why his System.map is not versioned.
>
>


I do copy mine manually.  It's how it was done when I first started
using Gentoo and I just stuck with it, it works.  It's just one
additional file.  Thing is, I may read up on the script way of doing
things.  It may help make dracut and grub-mkconfig happy.  Sometimes I
have to fiddle with names to get them both happy.  I suspect the script
tools handle that with ease. 

Now I got to go find that signature about the cat and free bagpipes.  I
want to send that to a friend.  She'll get a kick out of that.  lol 

Dale

:-)  :-) 

On Thu, 1 Jul 2021 09:41:27 -0500, Dale wrote:

> > grub-mkconfig only reads the files, it is the make install step of
> > kernel installation that takes care of copying the files to /boot
> > with the correct version numbers. ISTR Dale prefers to copy the
> > kernel files manually, which is why his System.map is not versioned.

> I do copy mine manually.  It's how it was done when I first started
> using Gentoo and I just stuck with it, it works.  It's just one
> additional file.  Thing is, I may read up on the script way of doing
> things.  It may help make dracut and grub-mkconfig happy.  Sometimes I
> have to fiddle with names to get them both happy.  I suspect the script
> tools handle that with ease. 

make install names the files in a way that dracut and grub-mkconfig
recognise. Just run make install after make modules install. You've let
the makefile copy all the other files, you may as well let it handle the
final two :)


--
Neil Bothwick

By the time you can make ends meet, they move the ends.

Neil,

On Thursday, 2021-07-01 15:28:51 +0100, you wrote:

> On Thu, 1 Jul 2021 13:16:29 +0200, Dr Rainer Woitok wrote:
>
> > Same here. And whenever I configure a new kernel my kernel managing
> > script makes sure both, the kernel I'm currenty running on and the one
> > just configured are in "@world". That way "emerge --depclean" will nev-
> > er remove a kernel package.
>
> You can also do that with sets. Add this to sets.conf
>
> [kernels]
> class = portage.sets.dbapi.OwnerSet
> world-candidate = False
> files = /usr/src
>
> add emerge -n @kernels once. Then depclean will never touch a kernel
> source package.

Nice trick, thank you :-). This would slightly simplify my kernel man-
aging script.

Sincerely,
Rainer

On 01/07/2021 15:41, Dale wrote:
> I do copy mine manually.  It's how it was done when I first started
> using Gentoo and I just stuck with it, it works.  It's just one
> additional file.

I copied my kernels manually to start with. Then I discovered "make
install". (and "make modules_install"). Much simpler.

And you don't need to muck about with grub.cfg by hand either. I think
I'm going to switch to grub-mkconfig, because you can always output it
to a new file to sanity-check before you send it live (and back up the
old one, so you can always recover ...).

Cheers,
Wol

On 2021-07-01, Neil Bothwick <neil@digimed.co.uk> wrote:

> make install names the files in a way that dracut and grub-mkconfig
> recognise. Just run make install after make modules install. You've let
> the makefile copy all the other files, you may as well let it handle the
> final two :)

IIRC, "make install" requiers /sbin/installkernel -- an executable
that's provided by one of installkernel-gentoo-3, debianutils, or
installkernel-systemd-boot. Back in the day, a base installation
didn't have /sbin/installkernel, and you needed to install it
manually. Has that changed?

--
Grant

On Thu, 2021-07-01 at 15:14 +0000, Grant Edwards wrote:
> On 2021-07-01, Neil Bothwick <neil@digimed.co.uk> wrote:
>
> > make install names the files in a way that dracut and grub-mkconfig
> > recognise. Just run make install after make modules install. You've
> > let
> > the makefile copy all the other files, you may as well let it handle
> > the
> > final two :)
>
> IIRC, "make install" requiers /sbin/installkernel -- an executable
> that's provided by one of installkernel-gentoo-3, debianutils, or
> installkernel-systemd-boot. Back in the day, a base installation
> didn't have /sbin/installkernel, and you needed to install it
> manually. Has that changed?
>
> --
> Grant
>
>


The handbook says that sys-kernel/installkernel-gentoo should be
installed by default. [1]

Just throw in my 2 cents, I use genkernel to manage compiling and
installing the kernel. With a little configuring you can get it to
compile, install and run grub-mkconfig for you. That way I can't forget
to run grub-mkconfig or something.

Hayley

[1]
https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel#Installing_correct_installkernel

On 6/30/21 11:59 PM, Dale wrote:
> Howdy,
>
> The subject line pretty much describes this.  How does one manage the
> system.map file in /boot?  Is it needed?  Should it be updated with each
> kernel?  I tend to keep 2 to 3 kernels installed.  I tend to keep 2 that
> I know are stable and one testing.  After a while, I may remove the
> oldest one and only have two, just in case.  Should I version the
> system.map file the same as kernels?  Does just one with no version get
> the job done?  Update the file with each kernel upgrade or install one
> and done?
>
> While at it, what does it even do?  If it needs it, it doesn't matter
> but just curious.
>
> Thanks for any tips on this.
>
> Dale
>
> :-)  :-)
>

I never copy it over unless I have some kernel panic (so not for well
over a decade.) So there's nothing for me to manage (I only copy the
kernel and kernel config to /boot.)

Dan

Daniel Frey wrote:
> On 6/30/21 11:59 PM, Dale wrote:
>> Howdy,
>>
>> The subject line pretty much describes this.  How does one manage the
>> system.map file in /boot?  Is it needed?  Should it be updated with each
>> kernel?  I tend to keep 2 to 3 kernels installed.  I tend to keep 2 that
>> I know are stable and one testing.  After a while, I may remove the
>> oldest one and only have two, just in case.  Should I version the
>> system.map file the same as kernels?  Does just one with no version get
>> the job done?  Update the file with each kernel upgrade or install one
>> and done?
>>
>> While at it, what does it even do?  If it needs it, it doesn't matter
>> but just curious.
>>
>> Thanks for any tips on this.
>>
>> Dale
>>
>> :-)  :-)
>>
>
> I never copy it over unless I have some kernel panic (so not for well
> over a decade.) So there's nothing for me to manage (I only copy the
> kernel and kernel config to /boot.)
>
> Dan
>
>
>


So if it isn't there or something, it isn't going to break anything. 
That's good to know too. 

Dale

:-)  :-) 

On Saturday, July 3, 2021 1:54:13 AM CEST Dale wrote:
> Daniel Frey wrote:
> > On 6/30/21 11:59 PM, Dale wrote:
> >> Howdy,
> >>
> >> The subject line pretty much describes this. How does one manage the
> >> system.map file in /boot? Is it needed? Should it be updated with each
> >> kernel? I tend to keep 2 to 3 kernels installed. I tend to keep 2 that
> >> I know are stable and one testing. After a while, I may remove the
> >> oldest one and only have two, just in case. Should I version the
> >> system.map file the same as kernels? Does just one with no version get
> >> the job done? Update the file with each kernel upgrade or install one
> >> and done?
> >>
> >> While at it, what does it even do? If it needs it, it doesn't matter
> >> but just curious.
> >>
> >> Thanks for any tips on this.
> >>
> >> Dale
> >>
> >> :-) :-)
> >
> > I never copy it over unless I have some kernel panic (so not for well
> > over a decade.) So there's nothing for me to manage (I only copy the
> > kernel and kernel config to /boot.)
> >
> > Dan
>
> So if it isn't there or something, it isn't going to break anything.
> That's good to know too.

I only copy the kernel image (and initrd if required)
I haven't done anything with the System.map or config (apart from keeping it
updated for compiling the kernel) in over a decade.

My boot-partition isn't even mounted unless I update the kernel, so a file
there wouldn't even be visible to the system.

--
Joost