system.map

system.map

[adrian kok]

Hi all

Why sometimes I don't need to copy the system.map to
/boot when I update the kernel
and the system also can boot?

Is it correct?

Thank you

_______________________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com.hk address at http://mail.english.yahoo.com.hk

Re: system.map

[Timothy Covell]

On Wednesday 02 January 2002 13:11, adrian kok wrote:
> Hi all
>
> Why sometimes I don't need to copy the system.map to
> /boot when I update the kernel
> and the system also can boot?
>
> Is it correct?
>
> Thank you
>
>
System.map is not required for everyday use of the OS.
It contains symbols which are useful for debugging and
such.   In normal usage, you can ignore the warnings which
as spit out by "ps", and others (?).  

	Of course, you can copy over the new System.map
file to /boot,  but their is no (easy) way of having more than
one active version via "lilo" or "grub".   And that could be 
considered a deficiency of the Linux OS.


-- 
timothy.covell@ashavan.org.

Re: system.map

[Tony Hoyle]

Timothy Covell wrote:


> 	Of course, you can copy over the new System.map
> file to /boot,  but their is no (easy) way of having more than
> one active version via "lilo" or "grub".   And that could be 
> considered a deficiency of the Linux OS.
>

????  Just call it System.map-2.2.17, System.map-2.5.1, etc.  Sounds
pretty 'easy' to me.

'make install' does all this for you, btw.

Tony

 

-
"Wipe Info uses hexadecimal values to wipe files. This provides more 
security than wiping with decimal values." -- Norton SystemWorks 2002 Manual

tmh@nothing-on.tv 
http://www.nothing-on.tv

Re: system.map

[Timothy Covell]

On Wednesday 02 January 2002 13:39, Tony Hoyle wrote:
> Timothy Covell wrote:
> > 	Of course, you can copy over the new System.map
> > file to /boot,  but their is no (easy) way of having more than
> > one active version via "lilo" or "grub".   And that could be
> > considered a deficiency of the Linux OS.
>
> ????  Just call it System.map-2.2.17, System.map-2.5.1, etc.  Sounds
> pretty 'easy' to me.
>
> 'make install' does all this for you, btw.
>
> Tony

Not on grub.  I quote:
	It is also possible to do "make install" if you have lilo 
	installed to suit the kernel makefiles,
  	but you may want to check your particular lilo setup first.

But, on my grub based system, I have to:

1.  "make bzlilo"  which creates vmlinuz and System.map 
and puts them in / and not in /boot.  (make bzlilo is easier to use
than bzimage)

2. cp /vmlinuz /boot/vmlinuz-x.y.x  ;  cp /System.map /boot/System.map-x.y.z

3. rm /boot/System.map ; ln -s /boot/System.map-x.y.z /boot/System.map

4. vi /boot/grub.conf (or /etc/grub.conf) and put in new kernel boot entry.

5. sync;sync;shutdown -r now


-- 
timothy.covell@ashavan.org.

Re: system.map

[Kilobug]

> 5. sync;sync;shutdown -r now

Is there any particular reason for this double sync ? One isn't enough ?
(And is sync even needed with shutdown, all should be synced when 
filesystems are unmounted or remounted read-only, am I wrong ? )

-- 
** Gael Le Mignot "Kilobug", Ing3 EPITA - http://kilobug.free.fr **
Home Mail   : kilobug@freesurf.fr          Work Mail : le-mig_g@epita.fr
GSM         : 06.71.47.18.22 (in France)   ICQ UIN   : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA

"Software is like sex it's better when it's free.", Linus Torvalds

Re: system.map

[Timothy Covell]

On Wednesday 02 January 2002 14:19, Kilobug wrote:
> > 5. sync;sync;shutdown -r now
>
> Is there any particular reason for this double sync ? One isn't enough ?
> (And is sync even needed with shutdown, all should be synced when
> filesystems are unmounted or remounted read-only, am I wrong ? )

The double sync is tradition.  SysV init scripts should sync things,
but "sync;sync;reboot" or "sync;sync;halt" are not so nice in how
they go down; so it's a case of being extra careful.  I don't use
linux all the time, and some of the other unices are less tolerant.
(For example, on a sun box, I would prefer a double sync before I
"<stop>-a".)

-- 
timothy.covell@ashavan.org.

Re: system.map

[Eric S. Johnson]

>The double sync is tradition. 

Actually it is a triple sync that is tradition. Since V7 days.

As in 

"anything I say three times is true" - Lewis Carrol

E

Re: system.map

[Miquel van Smoorenburg]

In article <200201022039.g02KdPSr022018@svr3.applink.net>,
Timothy Covell  <timothy.covell@ashavan.org> wrote:
>On Wednesday 02 January 2002 14:19, Kilobug wrote:
>> > 5. sync;sync;shutdown -r now
>>
>> Is there any particular reason for this double sync ? One isn't enough ?
>> (And is sync even needed with shutdown, all should be synced when
>> filesystems are unmounted or remounted read-only, am I wrong ? )
>
>The double sync is tradition.

The double sync is because traditionally, sync was asyncronous-
it told the kernel 'flush write cache to disk' but it returned
immidiately. That is why people were told to sync 3 times - by
the time you had typed 'sync' for the third time on your 300 baud
lineprinter console the system was done flushing.

sync;sync;sync;reboot is NOT what was used, it was:

# sync
# sync
# sync
# reboot

Anyway, Linux sync is different. It *is* synchronous. However syncing
and then doing a hard reboot is not recommended, you really need to
unmount all filesystems first, and remount root read-only. The
standard shutdown sequence does all of this for you and typing sync
before shutdown -r now is completely useless.

>SysV init scripts should sync things,
>but "sync;sync;reboot" or "sync;sync;halt" are not so nice in how
>they go down; so it's a case of being extra careful.  I don't use
>linux all the time, and some of the other unices are less tolerant.
>(For example, on a sun box, I would prefer a double sync before I
>"<stop>-a".)

If you're going to halt or reboot a system *hard* by using the reset
button or <stop>-a without calling shutdown you better sync before
you do that yes, and then you're still not guaranteed free of fs
corruption - at least kill all processes first to prevent some
process writing to disk in between the sync and the halt/reset.

Mike.

Re: Sync and reboot (was: Re: system.map)

[Miquel van Smoorenburg]

According to vda:
> However, then my shutdown script waits 5 secs before hard rebooting the box: 
> there is no way to be sure that IDE drives flushed their cache, except for 
> large pause.

There is, and sysvinit-2.83 implements it ;)

> (There may be some IDE command to do it, but who said each and every drive 
> will implement it? (and will do it correctly, i.e. would not lie to us that 
> cache is written back) :-)

There's supposed to be an IDE command but it depends on task files and
what not according to Andre Hedrick.

However there is another way. Putting the drive in standby mode also
flushes the write cache, and reboot/halt from sysvinit 2.83 and up
look for all IDE drives and put them in standby mode just before calling
the kernel's hard reboot/halt.

Ofcourse the kernel should do that itself, the IDE driver should
register a reboot handler that does this - but it doesn't, so I
put it in sysvinit for now.

Mike.

Re: Sync and reboot (was: Re: system.map)

[Andre Hedrick]

Sorry but if the patch of mine gets accepted there is a notifier hook that
first flushes_cache and holds for the return, then spins down the disks.

The cache_flushes are called always in addition if you were to look
closely at the new driver, each time you unmount a partition the disk is
flushed.  Overkill sure, but you will always have at least one flush cache
on a drive that has never been mounted.  You will have a min of 3 flush
cache calls on a drive which is mounted.

1 for each partition mounted.
1 of dec the usage counter to 0.
1 for deregistering the device.

Regards,

On Thu, 3 Jan 2002, Miquel van Smoorenburg wrote:

> According to vda:
> > However, then my shutdown script waits 5 secs before hard rebooting the box: 
> > there is no way to be sure that IDE drives flushed their cache, except for 
> > large pause.
> 
> There is, and sysvinit-2.83 implements it ;)
> 
> > (There may be some IDE command to do it, but who said each and every drive 
> > will implement it? (and will do it correctly, i.e. would not lie to us that 
> > cache is written back) :-)
> 
> There's supposed to be an IDE command but it depends on task files and
> what not according to Andre Hedrick.
> 
> However there is another way. Putting the drive in standby mode also
> flushes the write cache, and reboot/halt from sysvinit 2.83 and up
> look for all IDE drives and put them in standby mode just before calling
> the kernel's hard reboot/halt.
> 
> Ofcourse the kernel should do that itself, the IDE driver should
> register a reboot handler that does this - but it doesn't, so I
> put it in sysvinit for now.
> 
> Mike.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
CEO/President, LAD Storage Consulting Group
Linux ATA Development
Linux Disk Certification Project

Re: system.map

[Tony Hoyle]

Timothy Covell wrote:


> Not on grub.  I quote:


It works fine on grub.  I use grub.

make install is completely installation agnostic.  It just calls 
/sbin/installkernel with the paths of the various files.  On any sane 
distribution this will work.  If it doesn't it's only a shell script 
with a few symlink & copy commands in it... just write your own.

Tony

Re: system.map

[Timothy Covell]

On Wednesday 02 January 2002 14:25, Tony Hoyle wrote:
> Timothy Covell wrote:
> > Not on grub.  I quote:
>
> It works fine on grub.  I use grub.
>
> make install is completely installation agnostic.  It just calls
> /sbin/installkernel with the paths of the various files.  On any sane
> distribution this will work.  If it doesn't it's only a shell script
> with a few symlink & copy commands in it... just write your own.
>
> Tony

So, I guess that RedHat 7.2 must be an insane distribution:

make install
[snip]
System is 1308 kB
warning: kernel is too big for standalone boot from floppy
sh -x ./install.sh 2.4.17 bzImage /home/kernel/linux-2.4.17/System.map ""
+ '[' -x /root/bin/installkernel ']'
+ '[' -x /sbin/installkernel ']'
+ exec /sbin/installkernel 2.4.17 bzImage 
/home/kernel/linux-2.4.17/System.map ''
/etc/lilo.conf: No such file or directory
make[1]: *** [install] Error 1
make[1]: Leaving directory `/home/kernel/linux-2.4.17/arch/i386/boot'
make: *** [install] Error 2


-- 
timothy.covell@ashavan.org.

Re: system.map

[Alan Cox]

> So, I guess that RedHat 7.2 must be an insane distribution:
> 
> make install
> + exec /sbin/installkernel 2.4.17 bzImage 
> /home/kernel/linux-2.4.17/System.map ''
> /etc/lilo.conf: No such file or directory
> make[1]: *** [install] Error 1

Thats a bug. Please report it to https://bugzilla.redhat.com/bugzilla if its
not already there

Re: system.map

[Nicholas Harring]

Timothy Covell wrote:

>On Wednesday 02 January 2002 13:39, Tony Hoyle wrote:
>
>>Timothy Covell wrote:
>>
>>>	Of course, you can copy over the new System.map
>>>file to /boot,  but their is no (easy) way of having more than
>>>one active version via "lilo" or "grub".   And that could be
>>>considered a deficiency of the Linux OS.
>>>
>>????  Just call it System.map-2.2.17, System.map-2.5.1, etc.  Sounds
>>pretty 'easy' to me.
>>
>>'make install' does all this for you, btw.
>>
>>Tony
>>
>
>Not on grub.  I quote:
>	It is also possible to do "make install" if you have lilo 
>	installed to suit the kernel makefiles,
>  	but you may want to check your particular lilo setup first.
>
>But, on my grub based system, I have to:
>
>1.  "make bzlilo"  which creates vmlinuz and System.map 
>and puts them in / and not in /boot.  (make bzlilo is easier to use
>than bzimage)
>
>2. cp /vmlinuz /boot/vmlinuz-x.y.x  ;  cp /System.map /boot/System.map-x.y.z
>
>3. rm /boot/System.map ; ln -s /boot/System.map-x.y.z /boot/System.map
>
>4. vi /boot/grub.conf (or /etc/grub.conf) and put in new kernel boot entry.
>
>5. sync;sync;shutdown -r now
>
>
If you export INSTALL_PATH=/boot then the copying and removing and 
relinking will be unnecessary.

Nick Harring
Webley Systems, Inc.

Re: system.map

[Daniel Phillips]

On January 2, 2002 08:39 pm, Tony Hoyle wrote:
> Timothy Covell wrote:
> > 	Of course, you can copy over the new System.map
> > file to /boot,  but their is no (easy) way of having more than
> > one active version via "lilo" or "grub".   And that could be 
> > considered a deficiency of the Linux OS.
> 
> ????  Just call it System.map-2.2.17, System.map-2.5.1, etc.  Sounds
> pretty 'easy' to me.

It is if you know the magic incantation for System.map.

> 'make install' does all this for you, btw.

I've never been sure what 'make install' does, or what it might do in the 
future.  I've always just installed according to the README.  After doing 
this by hand way too many times, and having ferretted out the truth about 
System.map, I wrote the following bash script:

   here=`pwd`
   kernel=`basename $here`
   make modules_install >/dev/null
   cp arch/i386/boot/bzImage /boot/bzImage-$kernel
   cp System.map /boot/System.map-$kernel
   cp .config /boot/config-$kernel
   lilo

I put it in /usr/src and use it as follows:

  cd /usr/src/linux-xx.xx.xx
  sudo ../install

This does everything you need, with the exception of editing lilo.conf.  Note 
that the name of the top level directory is the name of the install, so you 
would probably not want to do 'cd /usr/src/linux' where linux is a symlink.

This is x86-specific, obviously.

--
Daniel

Re: system.map

[Albert D. Cahalan]

Daniel Phillips writes:

>    cp arch/i386/boot/bzImage /boot/bzImage-$kernel
>    cp System.map /boot/System.map-$kernel
>    cp .config /boot/config-$kernel

Gee, exactly the names I use. Surely then, this is correct.
You even take the '.' off of .config like I do. The only
difference is that you don't keep a copy of vmlinuz as well.

For a Mac, the only difference is that you need vmlinuz and
there isn't any bzImage at all. Stuff still goes in /boot.
(plus ybin and yaboot.conf instead of lilo and lilo.conf)

How can one get System.map w/o vmlinux?

[Timothy Covell]

The System.map question brings up several more:

1. Is it correct to say that System.map is basically
the software interrupt table? ( and that for Linux
software Interrupts equal syscalls)

2. If one doesn't have vmlinux lying around, is there
an easy way to recreate this (via a syscall or small
SUID root C program to dump out the vectors)

3. Wouldn't it be a good idea to allow for System.map
to be handled automagically like Lilo and Grub handle
different kernels?  If only to avoid this confusion and
those pesky "ps" warnings.

4. Why does "ps" really care about System.map?


-- 
timothy.covell@ashavan.org.

Re: How can one get System.map w/o vmlinux?

[David Golden]

I've often thought that an alternate scheme would be vaguely
"neater", just have a  boot directory with per-version subdirectories,
and a single symlink "current" to the  one you want to use.
I've never particularly had an urge to try to use one kernel version's
System.map and possibly initrd.img with another version :-)

No doubt there's a reason for not doing it this way, it's
probably been done to death years ago on lkml,
and personally, I don't find the current minor symlink tangle
much harder, but I only seem have 3 or so kernels in /boot at any one time -
I can imagine that having lots of kernels, system.maps and initrds all
in one directory would get tiresome with the current way, but would
be relatively painless like this:

/boot/2.2.20/vmlinuz
/boot/2.2.20/System.map
/boot/2.2.20/initrd.img
/boot/2.4.17/vmlinuz
/boot/2.4.17/System.map
/boot/2.4.17/initrd.img
...
ln -s /boot/2.4.17/  /boot/current
ln -s /boot/2.2.20/  /boot/old
etc.

Re: How can one get System.map w/o vmlinux?

[Christian Koenig]

Hi,

On Wednesday 02 January 2002 20:47, Timothy Covell wrote:
> The System.map question brings up several more:
>
> 1. Is it correct to say that System.map is basically
> the software interrupt table? ( and that for Linux
> software Interrupts equal syscalls)

Nope, software interrupts sound more like the interface 
user -> kernel, but System.map additionaly containing
Kernel only symbols, who are not accessible directly with syscals 
(but may be used by them).

> 2. If one doesn't have vmlinux lying around, is there
> an easy way to recreate this (via a syscall or small
> SUID root C program to dump out the vectors)

cat /proc/ksyms | grep -v "^c8" | sort 
gives a subset off System.map (the Symbols exported for module use).

MfG,Christian König.

Re: system.map

[Horst von Brand]

Timothy Covell <timothy.covell@ashavan.org> said:

[...]

> 	Of course, you can copy over the new System.map
> file to /boot,  but their is no (easy) way of having more than
> one active version via "lilo" or "grub".   And that could be 
> considered a deficiency of the Linux OS.

For kernel 2.4.18pre1 call it /boot/System.map-2.4.18pre1. Everything gets
sorted out if your initscripts symlink that to /boot/System.map (uname(1)
gives you the version of the running kernel).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: system.map

[Keith Owens]

On Wed, 2 Jan 2002 13:26:29 -0600, 
Timothy Covell <timothy.covell@ashavan.org> wrote:
>	Of course, you can copy over the new System.map
>file to /boot,  but their is no (easy) way of having more than
>one active version via "lilo" or "grub".   And that could be 
>considered a deficiency of the Linux OS.

Current versions of ps look for System.map in

      $PS_SYSTEM_MAP
      /boot/System.map-`uname -r`
      /boot/System.map
      /lib/modules/`uname -r`/System.map
      /usr/src/linux/System.map
      /System.map

Copy System.map to /lib/modules/`uname -r`/System.map after make
modules_install, remove any old map files from /boot and / and you
don't need any symlink or bootloader tricks.

The 2.5 kernel build asks if you want to install System.map and
.config.  If you say yes then the default location for these files in
2.5 is /lib/modules/`uname -r`/{System.map,.config}.

Re: system.map

[Timothy Covell]

On Wednesday 02 January 2002 14:54, Keith Owens wrote:
> On Wed, 2 Jan 2002 13:26:29 -0600,
>
> Timothy Covell <timothy.covell@ashavan.org> wrote:
> >	Of course, you can copy over the new System.map
> >file to /boot,  but their is no (easy) way of having more than
> >one active version via "lilo" or "grub".   And that could be
> >considered a deficiency of the Linux OS.
>
> Current versions of ps look for System.map in
>
>       $PS_SYSTEM_MAP
>       /boot/System.map-`uname -r`
>       /boot/System.map
>       /lib/modules/`uname -r`/System.map
>       /usr/src/linux/System.map
>       /System.map
>
> Copy System.map to /lib/modules/`uname -r`/System.map after make
> modules_install, remove any old map files from /boot and / and you
> don't need any symlink or bootloader tricks.

I saw that in the man page for "ps".  I think that your idea makes sense.

However, I'm concerned about searching in "/usr/src/linux" for it.
Linus has taken great pains to point out that we shouldn't be building
our kernels in /usr/src/linux, it would seem that this is reenforcing a
mistake.


>
> The 2.5 kernel build asks if you want to install System.map and
> .config.  If you say yes then the default location for these files in
> 2.5 is /lib/modules/`uname -r`/{System.map,.config}.


I knew that I was trying to download the 2.5.x series for a good reason. ;-)
My bandwidth hasn't let me get one full download yet, but I've got
all the 2.4.x patches that I could need.

-- 
timothy.covell@ashavan.org.

Re: system.map

[skidley]

On Wed, 2 Jan 2002, Timothy Covell wrote:
 
> However, I'm concerned about searching in "/usr/src/linux" for it.
> Linus has taken great pains to point out that we shouldn't be building
> our kernels in /usr/src/linux, it would seem that this is reenforcing a
> mistake.
> 
I'm curious as to why kernels shouldn't be built in /usr/src/linux. Also
this may be a dumb question but if I have built my kernels in /usr/src and want to move them to /home for eg. will that screw up things? Installing some apps from source sometimes they search for the kernel source during configure. If a kernel was compiled and moved to a different dir will this matter? 

-- 
  . ---                                   .----.
  |o_o |                                 /_ 0  |      
  |:_/ |   Give Micro$oft the Bird!!!!   \_    |
 //   \ \  Use Linux!!!!                 /      \
(|     | )                              | )  | | | 
/'\_   _/`\                             | )  | | |   
\___)=(___/                             |_)  (_) |  
Chad Young                               \______/
Registered Linux User #195191           (_______|
@ http://counter.li.org
-----------------------------------------------------------------------
Linux localhost 2.4.18pre1 #2 Fri Dec 28 14:41:58 AST 2001 i686 unknown
  6:50pm  up  4:35,  4 users,  load average: 0.01, 0.00, 0.00

Re: system.map

[Timothy Covell]

On Wednesday 02 January 2002 17:01, skidley wrote:
> On Wed, 2 Jan 2002, Timothy Covell wrote:
> > However, I'm concerned about searching in "/usr/src/linux" for it.
> > Linus has taken great pains to point out that we shouldn't be building
> > our kernels in /usr/src/linux, it would seem that this is reenforcing a
> > mistake.
>
> I'm curious as to why kernels shouldn't be built in /usr/src/linux. Also
> this may be a dumb question but if I have built my kernels in /usr/src and
> want to move them to /home for eg. will that screw up things? Installing
> some apps from source sometimes they search for the kernel source during
> configure. If a kernel was compiled and moved to a different dir will this
> matter?

The issue was that libc include files could step on kernel include
files due to symlinks in /usr/include/linux to /usr/src/linux/include.
IIRC the issue is that include files must point to those with which
the libc was compiled for proper userland compilations.   

The latest File Hierarchy Standard states that for glibc based systems,
/usr/src can be whatever it wants but that for libc5 based systems,

6.1.7 /usr/include :
Header files included by C programs These symbolic links are required if a C 
or C++ compiler is installed and only for systems not based on glibc. 
/usr/include/asm -> /usr/src/linux/include/asm-<arch> 
/usr/include/linux -> /usr/src/linux/include/linux

Thus, practice dictated that it was safer to build the linux kernel somewhere 
other than /usr/src/linux.   Since the kernel is shipped with it's own 
include files, it works just fine building the kernel anywhere else; I am 
building under /home/kernel/linux-x.y.z.


-- 
timothy.covell@ashavan.org.

Re: system.map

[Albert D. Cahalan]

Keith Owens writes:

> Current versions of ps look for System.map in
>
>       $PS_SYSTEM_MAP
>       /boot/System.map-`uname -r`
>       /boot/System.map
>       /lib/modules/`uname -r`/System.map
>       /usr/src/linux/System.map
>       /System.map
>
> Copy System.map to /lib/modules/`uname -r`/System.map after make
> modules_install, remove any old map files from /boot and / and you
> don't need any symlink or bootloader tricks.
> 
> The 2.5 kernel build asks if you want to install System.map and
> .config.  If you say yes then the default location for these files in
> 2.5 is /lib/modules/`uname -r`/{System.map,.config}.

That's not a nice place. Besides the fact that System.map is
neither library nor module, /lib/modules is less likely to
exist than /boot is. It's a wee bit slower too.

The System.map file contains info related only to the main kernel
image, and nothing related to modules. So this is better:

/boot/System.map-2.4.18-pre1
/boot/vmlinuz-2.4.18-pre1
/boot/bzImage-2.4.18-pre1
/boot/config-2.4.18-pre1

(losing the foul '.' on the .config file)

Re: system.map

[Keith Owens]

On Wed, 2 Jan 2002 16:17:30 -0500 (EST), 
"Albert D. Cahalan" <acahalan@cs.uml.edu> wrote:
>That's not a nice place. Besides the fact that System.map is
>neither library nor module, /lib/modules is less likely to
>exist than /boot is. It's a wee bit slower too.

/boot is a hangover from old i386 systems that could not boot past
cylinder 1024 so you needed a special partition to hold the boot
images.  That restriction does not exist on any system less than 5
years old nor on most non-i386 machines, the requirement for a special
/boot is obsolete on most machines.

System.map is not required for booting, it is only used after init
starts, therefore it does not belong in /boot anyway.

IA64 requires boot files to be in /boot/efi which must be a VFAT style
partition.  Trust me, you don't want anything in /boot/efi unless you
have to.

For all those reasons, putting System.map and .config in /boot is the
wrong thing to do.  There is no point in creating yet another directory
to hold these files when /lib/modules/`uname -r` will do the job.  Even
on systems with no modules, /lib/modules can be created to hold the
kernel specific files.  I put my bootable kernels in /lib/modules as
well, then I have exactly one place to remove to get rid of an old
kernel.

If it makes you feel happier, think of /lib/modules as 'kernel specific
data'.  Pity about the name but it is hard coded into too many programs
to change it to /lib/kernel or /kernel.

>It's a wee bit slower too.

????

Re: system.map

[Nicholas Knight]

On Wednesday 02 January 2002 01:31 pm, Keith Owens wrote:
> On Wed, 2 Jan 2002 16:17:30 -0500 (EST),
>
> "Albert D. Cahalan" <acahalan@cs.uml.edu> wrote:
> >That's not a nice place. Besides the fact that System.map is
> >neither library nor module, /lib/modules is less likely to
> >exist than /boot is. It's a wee bit slower too.
>
> /boot is a hangover from old i386 systems that could not boot past
> cylinder 1024 so you needed a special partition to hold the boot
> images.  That restriction does not exist on any system less than 5
> years old nor on most non-i386 machines, the requirement for a
> special /boot is obsolete on most machines.
>
> System.map is not required for booting, it is only used after init
> starts, therefore it does not belong in /boot anyway.
>
> IA64 requires boot files to be in /boot/efi which must be a VFAT
> style partition.  Trust me, you don't want anything in /boot/efi
> unless you have to.
>
> For all those reasons, putting System.map and .config in /boot is the
> wrong thing to do.  There is no point in creating yet another

For what reasons? I see no valid reason for it being the "Wrong" thing 
to do. I wouldn't even call it QUESTIONABLE. Nor is it simply a 
"holdover". There are still systems in use whos BIOS simply *does not 
support* booting past the 1024th cyl.
1. Putting stuff in /boot is generaly the "standard" thing to do, 
generaly won't cause confusion among experienced users, and will make 
sense to new users; /lib/modules/* will make no sense whatsoever.

2. /boot is shorter than /lib/modules/`uname -r`, and no I'm not 
kidding. I like short pathnames, it's for this reason I prefer to 
deposit stuff in /usr instead of /usr/local when it's on my personal 
desktop system. I'll sometimes spend hours copying kernels around or 
troubleshooting. The last thing I want to do is type 
/lib/mod<tab>/2.4<tab><damn forgot, more than one 2..4 
kernel>.18<tab><damn forgot more than one -pre <pre-1>/bz<tab> when I 
could instead type /bo<tab>/kern<tab>2.4.18....
This of course assumes I'm using a shell with filename completion! That 
in itself is not always possible on an extremely broken system.

3. Given that neither system is inherently bad, what makes you 
qualified to say it's "wrong" ?

> directory to hold these files when /lib/modules/`uname -r` will do
> the job.  Even on systems with no modules, /lib/modules can be
> created to hold the kernel specific files.  I put my bootable kernels
> in /lib/modules as well, then I have exactly one place to remove to
> get rid of an old kernel.
>
> If it makes you feel happier, think of /lib/modules as 'kernel
> specific data'.  Pity about the name but it is hard coded into too
> many programs to change it to /lib/kernel or /kernel.
>
> >It's a wee bit slower too.
>
> ????

Re: system.map

[H. Peter Anvin]

Followup to:  <WHITEAiPyTxQplr0tEj00000aaa@white.pocketinet.com>
By author:    Nicholas Knight <nknight@pocketinet.com>
In newsgroup: linux.dev.kernel
> 
> For what reasons? I see no valid reason for it being the "Wrong" thing 
> to do. I wouldn't even call it QUESTIONABLE. Nor is it simply a 
> "holdover". There are still systems in use whos BIOS simply *does not 
> support* booting past the 1024th cyl.
> 
> 1. Putting stuff in /boot is generaly the "standard" thing to do, 
> generaly won't cause confusion among experienced users, and will make 
> sense to new users; /lib/modules/* will make no sense whatsoever.
> 

Now, you're on a system on which /boot is actually a flash ROM (yes,
such systems exist) or for other reasons very small.

Gunk in /boot is not appreciated.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: system.map

[Albert D. Cahalan]

Keith Owens writes:
> "Albert D. Cahalan" <acahalan@cs.uml.edu> wrote:

>> That's not a nice place. Besides the fact that System.map is
>> neither library nor module, /lib/modules is less likely to
>> exist than /boot is. It's a wee bit slower too.
>
> /boot is a hangover from old i386 systems that could not boot past
> cylinder 1024 so you needed a special partition to hold the boot
> images.  That restriction does not exist on any system less than 5
> years old nor on most non-i386 machines, the requirement for a special
> /boot is obsolete on most machines.

Who said anything about being special? I have a Mac with kernels
in /boot. It boots via OpenFirmware loading yaboot from an HFS
partition, then yaboot reading the ext2 root partition.

I suppose a separate boot partition would be good if I were to
use a Reiserfs root partition. I might as well mount this boot
partition on /boot and put all my kernels there, instead of
mounting it on /lib/modules.

> System.map is not required for booting, it is only used after init
> starts, therefore it does not belong in /boot anyway.

It's not about modules either. :-) If you can ignore the
name, I can too. So "/boot" means "kernel stuff".

> IA64 requires boot files to be in /boot/efi which must be a VFAT style
> partition.  Trust me, you don't want anything in /boot/efi unless you
> have to.

VFAT isn't the fastest, and isn't multi-user, but who cares?
It works perfectly fine for System.map files.

Eh, what goes in /boot that couldn't be on the VFAT partition?
I'm thinking the VFAT partition ought to be mounted at /boot.

> If it makes you feel happier, think of /lib/modules as 'kernel specific
> data'.  Pity about the name but it is hard coded into too many programs
> to change it to /lib/kernel or /kernel.

I could agree to use /kernel/2.4.18-pre1/* for all the misc. stuff
and /kernel/2.4.18-pre1/modules/* for the modules. So you add this
to the search path for your stuff, and make the 2.5 install prefer
this location if it exists. Who else would care? Then after all the
distributions have 2.6.xx kernels, drop /lib/modules from the tools.
Killing /boot could wait a bit longer perhaps, or maybe not.

>>It's a wee bit slower too.
>
> ????

2 dirs:  / /boot
4 dirs:  / /lib /lib/modules /lib/modules/2.4.18-pre1

So an inode and at least one block for each. You lose even
if you figure that / and /lib would be cached already.

Plus /boot comes earlier in the "ps" search path, so you pay
the cost of looking in /boot anyway.

Re: system.map

[Marcel J.E. Mol]

On Wed, Jan 02, 2002 at 05:23:53PM -0500, Albert D. Cahalan wrote:
> Keith Owens writes:
> 
> > System.map is not required for booting, it is only used after init
> > starts, therefore it does not belong in /boot anyway.
> 
> It's not about modules either. :-) If you can ignore the
> name, I can too. So "/boot" means "kernel stuff".
 
So I moved /lib/modules in /boot and symlinked /lib/modules -> /boot/modules.
Everything about kernels is then in /boot (partition). This allow me
to share /boot over all the distros I installed and enjoy one kernel
compilation on all distros...

-Marcel


-- 
     ======--------         Marcel J.E. Mol                MESA Consulting B.V.
    =======---------        ph. +31-(0)6-54724868          P.O. Box 112
    =======---------        marcel@mesa.nl                 2630 AC  Nootdorp
__==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____
 They couldn't think of a number,           Linux user 1148  --  counter.li.org
    so they gave me a name!  -- Rupert Hine  --  www.ruperthine.com

Re: system.map

[Sebastian Roth]

> Hi all

hello,

> Why sometimes I don't need to copy the system.map to
> /boot when I update the kernel
> and the system also can boot?

> Is it correct?

yes, this is correct. I think this System.map contains only some useful 
information about modules for the kernel. At my system works that too. But I 
think it's better when you copy this file to /boot. :-)

> Thank you


Bye,
Sebastian

Re: system.map

[Lionel Bouton]

Sebastian Roth wrote:

>>Hi all
>>
> 
> hello,
> 
> 
>>Why sometimes I don't need to copy the system.map to
>>/boot when I update the kernel
>>and the system also can boot?
>>
> 
>>Is it correct?
>>
> 
> yes, this is correct. I think this System.map contains only some useful 
> information about modules for the kernel.

 > [...]

"man klogd", "man ksymoops".

Short:
System.map is an ordered (by address) list of (kernel address, ?type?, 
and syscall name).
Module syscalls are dynamic by nature so there's a kernel interface for 
exporting symbols to user utilities needing their addresses (see 
/proc/ksyms).

You don't need System.map to boot. But user space apps like ps (can show 
the current syscall used by a process), klogd (for clean GPF reports), 
ksymoops (mainly as a cross-check with vmlinux symbols) use it and 
search it in numerous places : with or without `-uname -r` appended (at 
least in / /boot /usr/src/linux).

LB.

Re: system.map

[David Golden]

On Wednesday 02 January 2002 21:25, Lionel Bouton wrote:
it and
> search it in numerous places : with or without `-uname -r` appended (at
> least in / /boot /usr/src/linux).
>

:-( Pity it apparently doesn't search

/boot/`uname -r`/System.map

That way the /boot/kernelver/* scheme (see previous post) would work...

Re: system.map

[Nick LeRoy]

On Wednesday 02 January 2002 16:15, David Golden wrote:
> On Wednesday 02 January 2002 21:25, Lionel Bouton wrote:
> it and
>
> > search it in numerous places : with or without `-uname -r` appended (at
> > least in / /boot /usr/src/linux).
> >
> :-( Pity it apparently doesn't search
>
> /boot/`uname -r`/System.map
>
> That way the /boot/kernelver/* scheme (see previous post) would work...

That would be nice.  I used to have my own personal system and hacked version 
of klogd that had a /boot/kernels directory, but in it I still maintained the 
old (cumbersum) naming convention.  I *like* this idea.  A lot.

/boot/`uname -r`/{System.map,bzImage,.config}

So, what's it take to make it a "standard"?

-Nick

Re: system.map

[Lionel Bouton]

David Golden wrote:

> On Wednesday 02 January 2002 21:25, Lionel Bouton wrote:
> it and
> 
>>search it in numerous places : with or without `-uname -r` appended (at
>>least in / /boot /usr/src/linux).
>>
>>
> 
> :-( Pity it apparently doesn't search
> 
> /boot/`uname -r`/System.map
> 
> That way the /boot/kernelver/* scheme (see previous post) would work...
> 
> 


As these utilities already look in several locations (most `uname -r` 
dependent), a patch to make them look in /boot/`uname -r` too would 
probably be trivial.

rgrep -r "/usr/src/linux" utility-src
vi files_found
diff -r -u old-src new-src \
	| mail -s "Small cool patch" utility-maintainer

LB.