Prev: xterm vs. [m]rxvt (WAS: Re: Corporate creep in Linux?(mini-rantette))
Next: hugesmp.s and initrd.img
From: emmel on 19 Sep 2009 14:28
Thus Eric Hameleers spoke:

> emmel schreef:
>
>> Well, it's no help, because I seem to have an easier time remember
>> looking into the documentation than to run some script that suggests a
>> command that is potentially wrong, because it doesn't know weather or
>> not the driver for my root file system is actually built into the
>> kernel. Which doesn't mean that there aren't people who might find it
>> useful, but it isn't to me.
>
> The script should be smart enough to find out that you built the
> drivers into the kernel.
>
> Eric

I had another look, and actually it doesn't, only the other way round:

<quote>
# This script will now make a recommendation about the command to use
# in case you require an initrd image to boot a kernel that does not
# have support for your storage or root filesystem built in
# (such as the Slackware 'generic' kernels').
</quote>

Not as if that does any harm, though.
From: +Alan Hicks+ on 22 Sep 2009 13:54
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2009-09-18, emmel <emmel(a)invalid.invalid> wrote:
>> No, it can't call lilo for you, because some of us use GRUB. Some
>> probably even use other boot managers.
>
> Doesn't stop the kernel make script. And I haven't heard anyone
> complaining about that.

That's because no one uses that argument in the kernel's Makefile
anymore. I obviously can't speak for everyone, but I know that it's
been sometime since I heard of anyone using make in the kernel's source
directory to re-run lilo. For one, a lot of people don't use lilo
anymore, but for another, most things require initrds these days.

In fact, I wouldn't be surprised at all to learn that some, perhaps
even most distributions patch that option out of the Makefile to keep
their user's from foot-bulleting themselves.

Bottom line: A lot of people feel that Slackware's mkinitrd is a very
useful tool in it's own right exactly at is it. They also feel that
changing it to be some automagical tool for installing your boot loader
too is highly error-prone. You of course, may feel differently, and
that's your right; however, don't expect mkinitrd to become some
generic boot-loader-maker tool that does everything for you. As it is,
there are very many handy features that make it much easier to use,
such as the aforementioned generator script, as well as
mkinitrd.conf(5). The man pages are clear on how to use all this stuff,
so you should have very little difficulty setting up the generic
kernel, or a kernel of your own making (or the huge kernel with md,
luks, or lvm).

- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkq5D04ACgkQNj1TaGS9H5Jk+gCfbdKDtoi1jKL31OLWmt8YIPqU
G0YAoIsvt1HcUAtuh3s63ZqMZsMG79oo
=wEis
-----END PGP SIGNATURE-----
From: emmel on 22 Sep 2009 14:16
Thus +Alan Hicks+ spoke:

>
> On 2009-09-18, emmel <emmel(a)invalid.invalid> wrote:
>>> No, it can't call lilo for you, because some of us use GRUB. Some
>>> probably even use other boot managers.
>>
>> Doesn't stop the kernel make script. And I haven't heard anyone
>> complaining about that.
>
> That's because no one uses that argument in the kernel's Makefile
> anymore. I obviously can't speak for everyone, but I know that it's
> been sometime since I heard of anyone using make in the kernel's source
> directory to re-run lilo. For one, a lot of people don't use lilo
> anymore, but for another, most things require initrds these days.
>
> In fact, I wouldn't be surprised at all to learn that some, perhaps
> even most distributions patch that option out of the Makefile to keep
> their user's from foot-bulleting themselves.

It's in the vanilla kernel sources, though, and it gets run every time I
do a 'make install'.

> Bottom line: A lot of people feel that Slackware's mkinitrd is a very
> useful tool in it's own right exactly at is it. They also feel that
> changing it to be some automagical tool for installing your boot loader
> too is highly error-prone. You of course, may feel differently, and
> that's your right; however, don't expect mkinitrd to become some
> generic boot-loader-maker tool that does everything for you. As it is,
> there are very many handy features that make it much easier to use,
> such as the aforementioned generator script, as well as
> mkinitrd.conf(5). The man pages are clear on how to use all this stuff,
> so you should have very little difficulty setting up the generic
> kernel, or a kernel of your own making (or the huge kernel with md,
> luks, or lvm).

Actually, I was mostly sulking a bit because I had to reboot the machine
*yet* again, because I forgot to run lilo after mkinitrd. Yet again.
Anyway, I've never had any trouble with the kernel's 'make
install' even *when* I used grub. There's some sort of automatism in
there that does-the-right-thing™ (probably just checking for the
presence of a lilo.conf, but still), and that's why I did quote it as an
example.
From: Grant on 22 Sep 2009 18:05
On Tue, 22 Sep 2009 17:54:23 +0000, +Alan Hicks+ <alan(a)lizella.netWORK> wrote:

....
>On 2009-09-18, emmel <emmel(a)invalid.invalid> wrote:
>>> No, it can't call lilo for you, because some of us use GRUB. Some
>>> probably even use other boot managers.
>>
>> Doesn't stop the kernel make script. And I haven't heard anyone
>> complaining about that.
>
>That's because no one uses that argument in the kernel's Makefile
>anymore. I obviously can't speak for everyone, but I know that it's
>been sometime since I heard of anyone using make in the kernel's source
>directory to re-run lilo. For one, a lot of people don't use lilo
>anymore, but for another, most things require initrds these days.

I disagree here. The kernel's 'make install' calls out to
~/bin/installkernel or /sbin/installkernel.

I choose not to use initrd, can't see the point for custom kernels here.
>
>In fact, I wouldn't be surprised at all to learn that some, perhaps
>even most distributions patch that option out of the Makefile to keep
>their user's from foot-bulleting themselves.

Well, the installkernel script hook has been there for many years --
what does surprise me is so few bother to 'roll their own'.

For reference (I've used this script for many years), see the home
page for the kbuild-install* scripts that I use to automate compile &
install here:

grant(a)deltree:~$ cat /home/common/install/installkernel
#! /bin/bash
#
# installkernel -- last edit 2008-09-09
#
# installkernel
# ``````````````
# this script is called by linux-kernel's 'make install' option to copy
# the kernel files (bzImage, System.map, .config) to the /boot directory
# the script is used for both 2.4 and 2.6 series kernel installs
#
# Copyright (C) 2004-2008 Grant Coady <grant(a)bugsplatter.id.au>
#
# based on linux/arch/i386/boot/install.sh
# GPL v2 per linux/COPYING by reference
#
# installation
# `````````````
# the linux 'make install' looks for this script in two places,
# in this order:
#
# ~/bin/installkernel
# /sbin/installkernel
#
# copy installkernel to one of the above locations but don't overwrite
# any distribution copy of /sbin/installkernel
#
# limitations
# ````````````
# does not build initrd files -- I've never used them
#
# optional
# `````````
# if you use a backup kernel naming option in /etc/lilo.conf
# this script will backup the old kernel files of the same version if
# it finds the line 'bzImage-$(uname -r).old' in /etc/lilo.conf, for
# example:
#
# /etc/lilo.conf
# ...
# image = /boot/bzImage-2.6.26.5a
# label = 2.6.26.5a
#
# image = /boot/bzImage-2.6.26.5a.old
# label = 2.6.26.5a.old
# ...
#
# when installing bzImage-2.6.26.5a the script will rename existing kernel
# files to the *.old extension, in this case: bzImage-2.6.26.5a.old,
# config-2.6.26.5a.old and System.map-2.6.26.5a.old
#
# home site
# ``````````
# http://bugsplatter.id.au/bash/kernel/
#
# installing kernel to alternate target
# ``````````````````````````````````````
# Usually the root user invokes the script as `make install` and expects the
# kernel files to appear in /boot and the kernel modules in /lib/modules.
#
# To install the kernel files to an alternate directory, specify
# INSTALL_PATH; for example, install kernel to staging area:
#
# INSTALL_PATH=/staging/area/boot make install
#
# see also
# `````````
# kbuild-install and kbuild-install-local scripts from the home page above,
# these scripts are what I use to build kernels for some years now
#
# Changelog
# ``````````
# 2008-09-09
# rewrite the above commentary

ME=installkernel
VERSION="2007-01-17"

echo -e "\n$ME:\nGrant's installkernel script, $VERSION"
DEBUG=
[ $DEBUG ] && echo "
* Arguments:
kernel version: $1
kernel image file: $2
kernel map file: $3
default install path: $4
"
BOOT_DIR="/boot" # default INSTALL_PATH, when $4 is empty

# check we have a valid kernel target directory
if [ -n "$4" ] && [ "$4" != "$BOOT_DIR" ]
then
if [ -d $4 ]
then
BOOT_DIR=$4
else
echo -e "\n\n$ME: fatal: missing kernel target directory:"
echo -e "\t$4"
exit 1
fi
fi

# where to find .config, based on kernel series
if [ -f '.config' ]
then
echo "* 2.6 kernel"
DOT_CONFIG=".config"
else
echo "* 2.4 kernel"
DOT_CONFIG="../../../.config"
fi

# create kernel file names with version --> $(uname -r)
CONFIG="$BOOT_DIR/config-$1"
KERNEL="$BOOT_DIR/bzImage-$1"
SYSMAP="$BOOT_DIR/System.map-$1"

echo "* Destination files:
config: $CONFIG
kernel: $KERNEL
System.map: $SYSMAP
"

# perhaps backup prior kernel files, if lilo.conf has matching .old stanza
if grep -q "bzImage-$1.old" /etc/lilo.conf
then
echo "* Moving old kernel files to $BOOT_DIR/*.old"
[ -f $CONFIG ] && mv $CONFIG "$CONFIG.old"
[ -f $KERNEL ] && mv $KERNEL "$KERNEL.old"
[ -f $SYSMAP ] && mv $SYSMAP "$SYSMAP.old"
fi

# write new kernel
echo -e "\n* Writing new kernel files to $BOOT_DIR"
cp $DOT_CONFIG $CONFIG
cat $2 > $KERNEL
cp $3 $SYSMAP

#end

Grant.
--
http://bugsplatter.id.au
From: emmel on 23 Sep 2009 03:12
Thus Grant spoke:

> On Tue, 22 Sep 2009 17:54:23 +0000, +Alan Hicks+ <alan(a)lizella.netWORK> wrote:
>
> ...
>>On 2009-09-18, emmel <emmel(a)invalid.invalid> wrote:
>>>> No, it can't call lilo for you, because some of us use GRUB. Some
>>>> probably even use other boot managers.
>>>
>>> Doesn't stop the kernel make script. And I haven't heard anyone
>>> complaining about that.
>>
>>That's because no one uses that argument in the kernel's Makefile
>>anymore. I obviously can't speak for everyone, but I know that it's
>>been sometime since I heard of anyone using make in the kernel's source
>>directory to re-run lilo. For one, a lot of people don't use lilo
>>anymore, but for another, most things require initrds these days.
>
> I disagree here. The kernel's 'make install' calls out to
> ~/bin/installkernel or /sbin/installkernel.

It does? Doesn't seem to even exist on my box.

> I choose not to use initrd, can't see the point for custom kernels here.

Well, I need initrd for encrypted root and custom kernels are something
of a habit for me. Although it was the only way to make my laptop's
hardware behave before it was as old as it is now.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: xterm vs. [m]rxvt (WAS: Re: Corporate creep in Linux?(mini-rantette))
Next: hugesmp.s and initrd.img