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
> 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
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.
--
[email protected].
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
[email protected]
http://www.nothing-on.tv
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?
--
[email protected].
Timothy Covell <[email protected]> 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
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
--
[email protected].
> 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 : [email protected] Work Mail : [email protected]
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
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
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.
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".)
--
[email protected].
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
--
[email protected].
On Wed, 2 Jan 2002 13:26:29 -0600,
Timothy Covell <[email protected]> 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}.
> 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
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
>
None of this sounds incredibly complicated, and, in fact, a scripting
language (e.g. perl) does quite nicely.
I wrote a little script that does the whole thing for me;
I can think of a bunch of improvements (like writing a new
/etc/lilo.conf file) that can be added with minimal effort:
I'm curious to know what the standard approach to this is.
What other scripts are out there?
#!/usr/bin/perl
# ----------------------------------------------------
# Program: kernel-install
# Description: This script installs a kernel after it
# has been built, since "make install"
# doesn't do it the way I like it.
# ----------------------------------------------------
$srcdir = "/usr/src/linux";
# Origin Files
$kernel = "$srcdir/arch/i386/boot/bzImage";
$map = "$srcdir/System.map";
$header = "$srcdir/include/linux/kernel.h";
# Destination Directory
$destdir= "/boot";
# Make sure all the files exist
if( !((-e $srcdir) && (-e $header) && (-e $kernel)) ) {
exit(-1);
}
# getversion will return $version
&getversion;
# Start copying stuff
system("cp $kernel $destdir/vmlinuz-$version");
system("cp $header $destdir/kernel.h-$version");
if( -e $map ) {
system("cp $map $destdir/System.map-$version");
}
# Remove existing softlinks
if( -e "$destdir/vmlinuz" ) {
unlink("$destdir/vmlinuz");
}
if( -e "$destdir/kernel.h" ) {
unlink("$destdir/kernel.h");
}
if( -e "$destdir/System.map") {
unlink("$destdir/System.map");
}
# Recreate links
symlink("$destdir/vmlinuz-$version","$destdir/vmlinuz");
symlink("$destdir/kernel.h-$version","$destdir/kernel.h");
if( -e $map ) {
symlink("$destdir/System.map-$version","$destdir/System.map");
}
# Run LILO
system("lilo");
# ----------------------------------------------------
# Subroutine: get_kernel_version
# Description: The kernel version for the kernel build
# can be found in the main Makefile.
# ----------------------------------------------------
sub getversion
{
$version = "";
local($makefile) = "$srcdir/Makefile";
if( !(-e $makefile) ) {
exit(-1);
}
open(MAKE,$makefile);
# We only need the first three lines
$i = 0;
local($line);
while( ($line = <MAKE>) && ($i++ < 4) ) {
# Grab the name value pairs by splitting line by =
(local($name), local($value)) = split(/=/, $line, 2);
# RegExp: Remove whitespace from value
$_ = $value;
s/^\s*(.*)\s*$/\1/;
# Add . between version & level, and level & sublevel
$version .= $1;
if( ($i==1) || ($i==2) ) {
$version .= ".";
}
}
close(MAKE);
}
>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
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)
On Wednesday 02 January 2002 14:54, Keith Owens wrote:
> On Wed, 2 Jan 2002 13:26:29 -0600,
>
> Timothy Covell <[email protected]> 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.
--
[email protected].
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.
On Wed, 2 Jan 2002 16:17:30 -0500 (EST),
"Albert D. Cahalan" <[email protected]> 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.
????
On Wed, 02 Jan 2002 16:14:58 -0500,
John Weber <[email protected]> wrote:
>I wrote a little script that does the whole thing for me;
>I can think of a bunch of improvements (like writing a new
>/etc/lilo.conf file) that can be added with minimal effort:
>
>I'm curious to know what the standard approach to this is.
>What other scripts are out there?
It is a lot easier in kbuild 2.5, I added clean support for install
scripts. kbuild 2.5 does most of the work, the install script can
concentrate on its own work instead of deducing the install information
itself.
Post-install script or command name
CONFIG_INSTALL_SCRIPT_NAME
If you perform some extra work after installing the kernel and
modules, specify the name of your script or command here. It will be
invoked after copying the kernel and modules to the target locations.
The CONFIG_INSTALL_* variables will be in the environment of your
script, as well as all variables exported by the top level Makefile,
including KERNELRELEASE, VERSION, PATCHLEVEL, SUBLEVEL, EXTRAVERSION,
USERVERSION, KBUILD_OBJTREE, KBUILD_SRCTREE_nnn.
If your boot loader needs to be run to pick up the new kernel
location, you can insert the loader command in this field. The
command or script must be executable. LILO users might find this to
be useful,
KBUILD_SRCTREE_000/scripts/lilo_new_kernel
It adds CONFIG_INSTALL_PREFIX_NAME/CONFIG_INSTALL_KERNEL_NAME to
/etc/lilo.conf with a label of KERNELRELEASE (truncated to 15
characters) then runs lilo.
Any words in the path that start with an upper case letter and
consist only of upper case letters, '_' and digits are replaced by
the value of the corresponding variable. This includes
KERNELRELEASE, VERSION, PATCHLEVEL, SUBLEVEL, EXTRAVERSION,
USERVERSION, KBUILD_SRCTREE_nnn.
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.
On Wednesday 02 January 2002 01:31 pm, Keith Owens wrote:
> On Wed, 2 Jan 2002 16:17:30 -0500 (EST),
>
> "Albert D. Cahalan" <[email protected]> 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.
>
> ????
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...
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
Keith Owens writes:
> "Albert D. Cahalan" <[email protected]> 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.
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.
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
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.
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.
--
[email protected].
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
=======--------- [email protected] 2630 AC Nootdorp
__==== http://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 -- http://www.ruperthine.com
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
In article <[email protected]>,
Timothy Covell <[email protected]> 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.
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.
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 [email protected]
> 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
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)
Followup to: <[email protected]>
By author: Nicholas Knight <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>