mkinitrd
emmel
mkinitrd with the wrong (read: none) parameters. Problem is that I'm
running with encrypted file systems, including root.
So I though I'd boot the system with some rescue system (tried
an old Knoppix, then used a Slack 12.2 DVD lying around), and rerun
mkinitrd with the right parameters. Except that it doesn't seem to work.
The kernel panics, telling me that the VFS couldn't access the root file
system...
Call it a hunch, but that might have something to do with the
error messages mkinitrd threw at me. Something about cp not knowing the
--parents parameter, which it should according to the man page.
Any suggestions welcome. I don't really want to have to
reinstall the system or anything, but at the moment I'm fresh out of
ideas. Help?
TIA
gabriel
I know that busybox's cp don't know the --parents option
$ cd /boot/initrd-tree/bin/
$ file cp
cp: symbolic link to `busybox'
$ ./cp --parents ~/todo ~/todo2
./cp: unrecognized option '--parents'
[...]
Can't help more than that.
emmel
Yeah... I got a bit suspicious after posting and checked the cp -
busybox. Which was rather disturbing, considering that I *had* done a
chroot before. Turns out mkinitrd got the idea and built its tree in my
root, messing up a good deal of my binaries. Trying to recover since
(deleting what shouldn't be there, judging from my other slack box and
reinstalling a lot of packages). At this point I at least get into
single user mode... Something's gone wrong with the device mapper...
Hm... By the looks of it mount it missing...
emmel
And installpkg and two reboots later (Can't that stupid mkinitrd call
lilo for me?) it works. Seriously, that script could do some work. A
failsafe for operating in the wrong directory and automatic executing of
lilo (if used) would be no end of good. BTW, does anyone know why
cryptsetup is a link to cryptsetup.static? Wasn't there some problem
with the static version?
gabriel
> lilo for me?) it works. Seriously, that script could do some work. A
> failsafe for operating in the wrong directory and automatic executing of
> lilo (if used) would be no end of good. BTW, does anyone know why
> cryptsetup is a link to cryptsetup.static? Wasn't there some problem
> with the static version?
cryptsetup is a link to cryptsetup.dynamic here. Seems that mkinitrd
screwed that too.
I suggest you to take a big look at the mkinitrd script ...
appzer0
> And installpkg and two reboots later (Can't that stupid mkinitrd call
> lilo for me?) it works. Seriously, that script could do some work. A
> failsafe for operating in the wrong directory and automatic executing of
> lilo (if used) would be no end of good. BTW, does anyone know why
> cryptsetup is a link to cryptsetup.static? Wasn't there some problem
> with the static version?
mkinitrd just does its job: make an initrd, nothing more. I suggest you
try the script in /usr/share/mkinitrd/mkinitrd_command_generator.sh to
generate a proper command. Obviously, lilo.conf must be updated to take
your initrd into acccount, then re-run it by 'lilo -v'.
One more point: I always delete the /boot/initrd-tree/ dir before
generating a new one, just in case.
Note: the mkinitrd_command_generator.sh is in the Slack13.0 'mkinitrd'
package, not in 12.2.
appzer0
emmel
It's the same on my other box, though. And there also is a
cryptsetup.dynamic.
emmel
> emmel a écrit :
>
>> And installpkg and two reboots later (Can't that stupid mkinitrd call
>> lilo for me?) it works. Seriously, that script could do some work. A
>> failsafe for operating in the wrong directory and automatic executing of
>> lilo (if used) would be no end of good. BTW, does anyone know why
>> cryptsetup is a link to cryptsetup.static? Wasn't there some problem
>> with the static version?
>
> mkinitrd just does its job: make an initrd, nothing more. I suggest you
> try the script in /usr/share/mkinitrd/mkinitrd_command_generator.sh to
> generate a proper command. Obviously, lilo.conf must be updated to take
> your initrd into acccount, then re-run it by 'lilo -v'.
Wasn't aware of that one... I'll have a look. I just got somewhat
freaked out when I had to restart the machine yet again, because I had
forgotten running lilo. Yet again. :-(
> One more point: I always delete the /boot/initrd-tree/ dir before
> generating a new one, just in case.
Well, that's what -c is /supposed/ to do.
> Note: the mkinitrd_command_generator.sh is in the Slack13.0 'mkinitrd'
> package, not in 12.2.
Not a problem for me, I'm actually running current. The only DVD I had
lying around was 12.2, though. And it was real fun to reinstall gzip and
tar when I got a tar error saying that gzip couldn't be found. Would
have been funny if it hadn't been so annoying. I'm just glad Slackware
packages are easily used manually.
emmel
> Thus appzer0 spoke:
>
>> emmel a écrit :
>>
>>> And installpkg and two reboots later (Can't that stupid mkinitrd call
>>> lilo for me?) it works. Seriously, that script could do some work. A
>>> failsafe for operating in the wrong directory and automatic executing of
>>> lilo (if used) would be no end of good. BTW, does anyone know why
>>> cryptsetup is a link to cryptsetup.static? Wasn't there some problem
>>> with the static version?
>>
>> mkinitrd just does its job: make an initrd, nothing more. I suggest you
>> try the script in /usr/share/mkinitrd/mkinitrd_command_generator.sh to
>> generate a proper command. Obviously, lilo.conf must be updated to take
>> your initrd into acccount, then re-run it by 'lilo -v'.
>
> Wasn't aware of that one... I'll have a look. I just got somewhat
> freaked out when I had to restart the machine yet again, because I had
> forgotten running lilo. Yet again. :-(
post scriptum: mkinitrd_command_generator.sh complained about a missing
lvdisplay, a missing /proc/mdstat and then basicly told me to use
'mkinitrd -c -k 2.6.30.5 -f ext3 -r root -C /dev/sda3 -o /boot/initrd.gz'.
Not very useful IMHO. Well, at least it got my crypto setup right.
Eric Hameleers
Why do you think it was not useful to you?
It did show you the exact command you need to use in order to create
your initrd. The script is not called "mkininit command generator" for
fun... it does what the name implies.
Eric
Chick Tower
> And installpkg and two reboots later (Can't that stupid mkinitrd call lilo
> for me?) it works.
No, it can't call lilo for you, because some of us use GRUB. Some
probably even use other boot managers.
--
Chick Tower
For e-mail: aols2 DOT sent DOT towerboy AT xoxy DOT net
emmel
> On Wed, 16 Sep 2009 17:54:59 +0000, emmel wrote:
>
>> And installpkg and two reboots later (Can't that stupid mkinitrd call lilo
>> for me?) it works.
>
> 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.
emmel
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.
Douglas Mayne
You can make your own initrd, which can function as a more complete
startup environment. The default Slackware initrd implementation is
very lean and minimalist. It is designed to start your system, when it
is not broken. The benefit of a larger initrd is that you can build it
with the fixup tools you might need already installed. I have a "hybrid"
initrd- it uses mainly official slackware packages, but with a few tools
still provided by the busybox toolset. Also, I manually removed some
documentation files (multi-language, IIRC), and that reduced the space
required somewhat.
Recently, I have verified that hibernate/resume is now working correctly,
when system state saved to encrypted swap. IMO, having the ability to
suspend/hibernate is an element for portable systems. Encryption is
also essential, IMO, and that was already working. Now the two are
working together!
The remainder of this post has some technical details...
My initrd, as built for Slackware 12.2 includes these official Slackware
packages:
aaa_base-12.2.0-noarch-1
aaa_elflibs-12.2.0-i486-1
aaa_terminfo-5.6-noarch-1
bash-3.1.017-i486-2
bzip2-1.0.5-i486-1
coreutils-6.12-i486-1
cpio-2.5-i486-3
cryptsetup-1.0.5-i486-4
device-mapper-1.02.28-i486-1
devs-2.3.1-noarch-25
dialog-1.1_20070930-i486-1
e2fsprogs-1.41.3-i486-1
elvis-2.2_0-i486-2
etc-12.2-noarch-1
findutils-4.2.31-i486-1
glibc-solibs-2.7-i486-17
gnupg-1.4.9-i486-1
grep-2.5.3-i486-1
gzip-1.3.12-i486-1
libgcrypt-1.4.0-i486-2
libgpg-error-1.6-i486-3
lvm2-2.02.40-i486-1
mdadm-2.6.4-i486-1
module-init-tools-3.5-i486-1
pkgtools-12.1.0-noarch-7
procps-3.2.7-i486-2
readline-5.2-i486-3
sed-4.1.5-i486-1
tar-1.16.1-i486-1
util-linux-ng-2.14.1-i486-1
which-2.16-i486-1
It includes the busybox toolset (as included with Slackware 12.2's
mkinitrd), provides these commands:
$ find . -type l -printf "%l\t%l\n"
./usr/bin/[[ ../../bin/busybox
./usr/bin/wget ../../bin/busybox
./usr/bin/unzip ../../bin/busybox
./usr/bin/unlzma ../../bin/busybox
./usr/bin/time ../../bin/busybox
./usr/bin/openvt ../../bin/busybox
./usr/bin/lzmacat ../../bin/busybox
./usr/bin/loadfont ../../bin/busybox
./usr/bin/killall ../../bin/busybox
./usr/bin/deallocvt ../../bin/busybox
./usr/bin/cmp ../../bin/busybox
./usr/bin/clear ../../bin/busybox
./usr/bin/chvt ../../bin/busybox
./usr/bin/ar ../../bin/busybox
./bin/pidof busybox
./bin/mktemp busybox
./bin/ping busybox
./bin/chattr busybox
./bin/dumpkmap busybox
./bin/lsattr busybox
./bin/pipe_progress busybox
./bin/usleep busybox
./sbin/watchdog ../bin/busybox
./sbin/syslogd ../bin/busybox
./sbin/switch_root ../bin/busybox
./sbin/route ../bin/busybox
./sbin/reboot ../bin/busybox
./sbin/poweroff ../bin/busybox
./sbin/loadkmap ../bin/busybox
./sbin/klogd ../bin/busybox
./sbin/init ../bin/busybox
./sbin/ifconfig ../bin/busybox
./sbin/halt ../bin/busybox
./sbin/freeramdisk ../bin/busybox
./linuxrc.busybox bin/busybox
And it includes the gzipped kernel modules associated with my kernel
(2.6.30.6):
$ du -sh lib/modules/2.6.30.6-smp-dm-m-1/
32M lib/modules/2.6.30.6-smp-dm-m-1/
And the total size of the initrd is 79M.
The other key component is the startup script, initrd. Here is my startup
script (Note the disclaimers to use at your own risk, per the provisions
of the General Public License, GPL):
<begin source code, file: init):
#!/bin/bash
#
# Project Name: dm-live
#
# Program Name: /init
# File Version: 0.0.1
# First Version: 2007-11-29
# Last Change: 2009-09
# : 2007-12-03
#
# Copyright (C) 2007 Douglas D. Mayne
#
# This program is licensed under the General Public License. See this file
# for terms and conditions: http://www.gnu.org/licenses/gpl.txt
#
# Purpose: The Linux kernel executes "init" as PID 1 at boot. This "init"
# is designed to be loaded into a ramfs where it will make final preparation
# for the real root filesystem. When the root filesystem is ready, this program
# will transfer control to the "real" init on the root filesystem. The startup
# environment for the initrd (as built by me) includes bash, various utilities,
# associated libraries, and all of the kernel modules (gzipped). This program
# in combination with the working environment will allow the user to setup a
# root file system which uses any of the device mapper kernel modules, etc.
#
# Misc. Notes:
# 1. The working environment can also be used as a standalone minimal
# working environment where various kernel module can be loaded and misc.
# system maintenance tasks can be performed: partitions formatted, disk
# images loaded, etc. To use this environment, append to grub's kernel
# specification with the parameter:
#
# rdinit=/bin/bash
#
# Or provide the parameter as appropriate for the bootloader you use,
# if you are not using the grub loader.
#
# 2. The working environment has the following hardware/platform
# requirements:
#
# Minimum CPU: i686
# Miniman RAM: 128M
#
# 3. I setup the working environment with this kernel and its associated
# modules as shown below:
#
# kernel-generic-smp-2.6.23.9_smp-i686-1.tgz 2007-11-28 (*)
# kernel-modules-2.6.23.9-i486-1.tgz 2007-11-28 (**)
#
# (*) The kernel is loaded by the bootloader. It is not a component
# of the initrd itself.
# (**) The kernel modules were gzipped and module dependancies regenerated
# prior to being moved to the initrd (/lib/modules/2.6.23.9-smp)
#
# End Misc. Notes.
#
# Begin Source Code and Comments --
#
# /init for initrd, using switch_root transfer mechanism
#
REF_DIR=dm-live
PATH=/sbin:/bin:/usr/bin:/usr/sbin:$PATH
export PATH
XDEBUG=0
REAL_INIT=sbin/init
MIN_INIT_MEM_FREE=73728
START_DATE=$( date +"%Y-%m-%d.%H%M%S")
KV=$(uname -r)
#Script to use: Load kernel modules
LKM=/${REF_DIR}/misc/man_modprobe.scr
KM=/modules.init
RKMD=lib/modules/${KV}
USER_VARS=/user.inp
[ -e $USER_VARS ] && . $USER_VARS
#
# Initial assumptions
#
# code construct below is a makeshift "try" block
# continue on loop below indicates an error, break is good
#
[ ${FLAG_CHOWN_INITRD:=0} -ne 0 ] && chown root.root -R /
for TRY1 in 0 1;do
[ $TRY1 -ne 0 ] && continue
#
# Includes
#
EF=0
for i in tmpfile yesno check_rw age_km devname_majmin;do
j=/${REF_DIR}/misc/${i}.bash
if [ ! -e "$j" ];then
echo "Error: $j is a required file and is not found."
echo "- exiting."
EF=1
else
. $j
fi
done
if [ $EF -ne 0 ];then
echo "Error: A required file is not found."
echo "- exiting."
continue
fi
#
# Allocate some temp files for working environment
#
for i in $(seq 0 10);do
T[${i}]=$(tmpfile)
EF=0
[ ! -e ${T[${i}]} ] && EF=1 && break
done
if [ $EF -ne 0 ];then
echo "Error: Temp files cannot be allocated."
echo "- exiting."
continue
else
LOG=${T[0]}
[ $XDEBUG -ne 0 ] && echo "Status: using temp log file: $LOG"
fi
break
done
if [ $TRY1 -ne 0 ];then
echo "Startup failed due to problem with environment."
[ $XDEBUG -ne 0 ] && /bin/bash
echo "Probably press CTL-ALT-DEL to avoid kernel panic."
read
exit 1
fi
#
# Main try loop
#
# code construct below is a makeshift "try" block
# continue on loop below indicates an error, break is good
#
for RV in 0 1;do
[ $RV -ne 0 ] && continue
echo "${START_DATE}: Welcome to dm-live, init by Douglas Mayne" >$LOG
echo "Status: This is version: $(cat ${REF_DIR}/VERSION)" >>$LOG
echo "Status: Using kernel $KV" >>$LOG
#
# Begin by mounting proc
#
[ ! -d /proc ] && mkdir /proc
mount -n proc /proc -t proc
[ ! -d /sys ] && mkdir /sys
mount -n sysfs /sys -t sysfs
echo 0x0100 > /proc/sys/kernel/real-root-dev
[ ! -d /tmpfs ] && mkdir /tmpfs
mount tmpfs /tmpfs -t tmpfs
# mount -n tmpfs /tmpfs -t tmpfs
mkdir tmpfs/rw_dev
mkdir tmpfs/rw_lp
mkdir tmpfs/ro_dev
mkdir tmpfs/ro_lp
mkdir tmpfs/root
#
# Load kernel modules
#
if [ -x $LKM ]; then
echo "Status: Loading kernel modules as specified in file, $KM" | tee -a $LOG
$LKM $KM
[ ${SLEEP_USB:=0} -ne 0 ] && sleep $SLEEP_USB
fi
#
# Make sure device mapper snapshot is loaded, reinit "local" /dev/mapper
#
modprobe dm-snapshot
rm -fr /dev/mapper && mkdir /dev/mapper && dmsetup mknodes
[ ! -e /dev/mapper/control ] && dmsetup ls >/dev/null
if [ -e /dev/mapper/control ];then
echo "Status: /device/mapper/control exists." >>$LOG
else
echo "Error: /device/mapper/control could not initialized. Exiting." | tee -a $LOG
continue
fi
#
# Low memory check
#
# Check memory and get value of available swap...
# swap may be used to increase tmpfs max allocation in future versions of this script
#
T6=${T[6]}
cat /proc/meminfo >$T6
MEM_TOTAL=$(cat $T6 | grep "MemTotal:" | sed -e 's/^.*: *//' -e 's/ kB$//')
INIT_MEM_FREE=$(cat $T6 | grep "MemFree:" | sed -e 's/^.*: *//' -e 's/ kB$//')
SWAP_TOTAL=$(cat $T6 | grep "SwapTotal:" | sed -e 's/^.*: *//' -e 's/ kB$//')
rm $T6
if [ $INIT_MEM_FREE -lt $MIN_INIT_MEM_FREE ];then
clear
head -3 <$LOG
echo "Warning: Your system reports current free memory: " $INIT_MEM_FREE
echo "- that amount is below the minimum tested."
yesno "Proceed anyway, yes or (no) ? " no
if [ $? -eq 0 ];then
echo "Status: User elects to abort startup (low memory)."
continue
else
echo "Status: User elects to continue startup (low memory)." | tee -a $T6
fi
fi
printf "Status: Initial free memory: %d kB\n" $INIT_MEM_FREE | tee -a $T6
# printf "Status: Kernel command line args: %s\n" $(cat /proc/cmdline) | tee -a $T6
#
# Parse kernel command line
#
for CLA in $(cat /proc/cmdline);do
case $CLA in
resume=*) RESUME_DEV=$(echo $CLA | cut -f2 -d=)
;;
esac
done
#
# First Message
#
clear
cat $T6 >>$LOG
cat $LOG
cat /${REF_DIR}/misc/MESSAGE.1
read -n1 -s
#
# hack in GPG based encryption : prelim
# hack script knows what to do to read encrypted messages which explain
# how to setup device mapper objects. If using encrypted root, then
# make sure that variable is set appropriately: ROOT_DEV=/dev/mapper/...
#
if [ $FLAG_USING_ENC -eq 1 ];then
./hack2
if [ $? -eq 0 ];then
printf "Status: Good result from hack script...\n" | tee -a $LOG
else
printf "Check some error entering passphrase, etc.\n"
printf "...dropping to a shell\n"
/bin/bash
fi
else
#
# Allow direct user manipulation of environment (using bash shell from here)
#
/bin/bash
fi
#
# Upon return, accept user input from file
#
[ -e $USER_VARS ] && . $USER_VARS
#
# Resume?
#
if [ ! -z $RESUME_DEV ];then
RD=$(devname_to_majmin $RESUME_DEV)
[ ! -z $RD ] && echo $RD >/sys/power/resume
fi
#
# Defaults
#
ROOT_FS=${ROOT_FS:=xfs}
ROOT_DEV=${ROOT_DEV:=/dev/mapper/top}
ROOT_FMP=${ROOT_FMP:=/tmpfs/root}
mount -o rw -t $ROOT_FS $ROOT_DEV $ROOT_FMP
if [ ! -r ${ROOT_FMP}/${REAL_INIT} ]; then
echo "Error: real init is not found. Exiting."
continue
else
check_rw $ROOT_FMP $REF_DIR $START_DATE
if [ $? -ne 0 ];then
echo "Error: real root filesystem is not RW. Exiting."
continue
fi
fi
#
# Wipe out device mapper at target, then reinitialize with current "local"
#
(cd ${ROOT_FMP}/dev && rm -fr mapper);
(cd /dev/ && tar -cpf - mapper) | (cd ${ROOT_FMP}/dev && tar -xvf -)
#
# Fixup real root's fstab: assume for now that user has already done this to his specs.
#
#
# Save kernel modules
#
yesno "Copy kernel modules to root, (yes) or no ? " yes
if [ $? -ne 0 ];then
[ -e ${ROOT_FMP}/${REF_DIR}/${RKMD} ] && rm -fr ${ROOT_FMP}/${REF_DIR}/${RKMD}
(cd / && tar -cpf - $RKMD) | (cd ${ROOT_FMP}/${REF_DIR} && tar -xvf -)
if [ -e ${ROOT_FMP}/${REF_DIR}/${RKMD} ];then
echo "Status: Saved kernel modules to new root: ${REF_DIR}/${RKMD}" | tee -a $LOG
else
echo "Status: Check some problem saving kernel modules to new root: ${REF_DIR}/${RKMD}" | tee -a $LOG
fi
if [ -e ${ROOT_FMP}/lib/modules ];then
[ -d ${ROOT_FMP}/${RKMD} ] && age_km ${ROOT_FMP}/${RKMD} ${T[6]}
[ -L ${ROOT_FMP}/${RKMD} ] && rm ${ROOT_FMP}/${RKMD}
if [ ! -e ${ROOT_FMP}/${RKMD} ];then
(cd ${ROOT_FMP}/lib/modules && ln -s /${REF_DIR}/${RKMD} $KV)
if [ $? -eq 0 ];then
echo "Status: Created symbolic link to kernel modules on new root." | tee -a $LOG
else
echo "Status: Check some problem creating symbolic link to kernel modules on new root." | tee -a $LOG
fi
fi
else
echo "Status: Check some problem on new root: /lib/modules does not exist" | tee -a $LOG
fi
else
echo "Status: User elects not to save kernel modules at new root." | tee -a $LOG
fi
#
# Make temp log the final log.
# Available at /initrd/tmp/startup.log when boot completes.
#
if [ ${FLAG_SAVE_STARTUP_LOGS:=1} -ne 0 ];then
LOGF=${ROOT_FMP}/${REF_DIR}/${START_DATE}/startup.log
mkdir -p $(dirname $LOGF)
mv $LOG $LOGF
DMESG=${ROOT_FMP}/${REF_DIR}/${START_DATE}/dmesg
dmesg >$DMESG
fi
if [ ${FLAG_SET_REF_PERM:=1} -ne 0 ];then
(cd ${ROOT_FMP}/${REF_DIR} && for i in $(find . -type d);do
chown root:root $i
chmod 755 $i
done)
fi
mount -o remount -o ro -t $ROOT_FS $ROOT_DEV $ROOT_FMP
umount /proc
umount /sys
#
# Remember: There is no need to clean up ourselves. The switch_root function
# deletes everything in ramfs just before the switch. This frees the memory
# buffers, etc.
#
exec switch_root $ROOT_FMP /${REAL_INIT} $@
done
#
# Never get here on good startup
#
if [ $RV -ne 0 ];then
echo "Startup failed..."
[ $XDEBUG -ne 0 ] && /bin/bash
echo "Probably press CTL-ALT-DEL to avoid kernel panic."
read
fi
exit $RV
<end source code>
--
Douglas Mayne
Eric Hameleers
> 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
emmel
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.
+Alan Hicks+
Hash: SHA1
On 2009-09-18, emmel <em...@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-----
emmel
>
> On 2009-09-18, emmel <em...@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.
Grant
...
>On 2009-09-18, emmel <em...@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@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 <gr...@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
emmel
> On Tue, 22 Sep 2009 17:54:23 +0000, +Alan Hicks+ <al...@lizella.netWORK> wrote:
>
> ...
>>On 2009-09-18, emmel <em...@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.
Grant
>Thus Grant spoke:
>
>> On Tue, 22 Sep 2009 17:54:23 +0000, +Alan Hicks+ <al...@lizella.netWORK> wrote:
>>
>> ...
>>>On 2009-09-18, emmel <em...@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.
That's right, slackware dosen't provide an installkernel script -- it's
only an optional kernel build feature. The biggies (Suse, etc) use it.
>
>> 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.
Oh I'm sure there's good use for initrd. I avoid it for simple systems.
Grant.
--
http://bugsplatter.id.au