Prev: Relocating the .ICEauthority (Debian/GNOME)
Next: Wireshark - capture file analysis.
From: Tony Houghton on 7 Mar 2007 09:39
In <87hcsxjnph.fsf(a)hades.wkstn.nix>,
Nix <nix-razor-pit(a)esperi.org.uk> wrote:

> On 7 Mar 2007, Tony Houghton verbalised:
>
>> initramfs-utils makes it pretty easy to set up on Debian and Ubuntu too,
>> although I missed the --initrd option to make-kpkg and it looks like it
>> might not work for initramfs anyway. So I'll have to remember to run
>> update-initramfs each time I install a new kernel and I'm bound to
>> forget!
>
> If you build it into the kernel binary, you don't need to do that: the
> kernel build system assembles the initramfs and links it into the kernel
> image for you: it's impossible to forget because there's nothing to
> remember. (Generally such things are linked with a different C library
> from glibc, which is a bloated monster for this application: I use the
> latest SVN copy of uClibc and busybox, as busybox has a switch_root
> command which does the wipe-everything-on-the-rootfs-close-all-fds-
> chroot()-and-exec() dance you need to use to continue booting without
> wasting memory. Note that the rootfs is quite different from the
> filesystem that happens to house / after you've booted; wipe that and
> you'll soon regret it, of course ;} )

Don't you get a chicken & egg situation with your modules? You need them
in the image but you can't easily tell the build process where to find
them separately from their sources etc until they're already installed.

With initramfs-utils I don't need to concern myself with the details of
busybox or klibc. I think I'll just rely on that for now and post a
wish/bugrep for make-kpkg to support it.

--
TH * http://www.realh.co.uk
From: Nix on 7 Mar 2007 16:43
On 7 Mar 2007, Tony Houghton outgrape:

> In <87hcsxjnph.fsf(a)hades.wkstn.nix>,
> Nix <nix-razor-pit(a)esperi.org.uk> wrote:
[initramfs]
>> If you build it into the kernel binary, you don't need to do that: the
>> kernel build system assembles the initramfs and links it into the kernel
>> image for you: it's impossible to forget because there's nothing to
>> remember. (Generally such things are linked with a different C library
>> from glibc, which is a bloated monster for this application: I use the
>> latest SVN copy of uClibc and busybox, as busybox has a switch_root
>> command which does the wipe-everything-on-the-rootfs-close-all-fds-
>> chroot()-and-exec() dance you need to use to continue booting without
>> wasting memory. Note that the rootfs is quite different from the
>> filesystem that happens to house / after you've booted; wipe that and
>> you'll soon regret it, of course ;} )
>
> Don't you get a chicken & egg situation with your modules? You need them
> in the image but you can't easily tell the build process where to find
> them separately from their sources etc until they're already installed.

That's not something I've had to pay attention to: I don't use modular
kernels and I don't really see why anyone who isn't a distributor
bothers with them, either. There's no central record of the location of
..ko files: `make modules_istall' finds them by traversing the filesystem
(see scripts/Makefile.modinst).

So you could do it via, say,

make modules
cp usr/initramfs.in usr/initramfs
for name in $(find . -name '*.ko'); do
echo "file /lib/$(basename $name) $name 0644 0 0" >> usr/initramfs
done
make

and bob's your uncle.

You could alternatively arrange to copy or link all the files you need
in your initramfs into the usr/ subdirectory of the kernel tree, and
`make' will then assemble the initramfs out of the contents of that
directory and link it into your kernel image.

> With initramfs-utils I don't need to concern myself with the details of
> busybox or klibc.

You don't *need* to in any case. It just makes your kernel image /
initramfs image smaller (without affecting its in-memory size once it's
up and running).

The advantage of the linked-in-initramfs approach is that it Just Keeps
Working and that, just as in the days before modules, the kernel image
is self-contained: once you have a working image, that image will *keep*
working. You can't mess up some separate file and find that you've
busted your kernel, or upgrade your initrd and find that it's stopped
working with your older believed-stable kernel image... all of which
are sort of important if you need your initramfs to mount root!


(In my case, in addition to the LVM+RAID stuff and an init script that
parses fstab to find my root filesystem and fsck it, I've got an
emergency boot shell and a few hundred Kb's worth of core Unix tools in
there; enough to bring the system back up if my RAID array goes weird or
LVM gets mangled. I've even got vgcfgbackup/vgcfgrestore and a disk
sector editor, so that if it goes *really* pear-shaped I can edit the
LVM metadata on the disk directly --- whic is less frightening than it
sounds, because LVM2's metadata is plaintext. For a time I had the NBD
daemon on there too, and enough network tools to get the net far enough
up to mount part of my RAID array over the network after a drive
failure... this wasn't exactly robust, because if the remote machine
goes down, you lose that block device. Oops. But it served for a week
or two until I could get a new disk.)

--
`In the future, company names will be a 32-character hex string.'
--- Bruce Schneier on the shortage of company names
From: Geoffrey Clements on 8 Mar 2007 12:05
"Nix" <nix-razor-pit(a)esperi.org.uk> wrote in message
news:87wt1shgra.fsf(a)hades.wkstn.nix...
> On 7 Mar 2007, Tony Houghton outgrape:

[snip]

>
> I don't use modular
> kernels and I don't really see why anyone who isn't a distributor
> bothers with them, either.

Because I don't have to compile the kernel modules if I add new hardware or
decide to use a new iptables match module for instance. In fact when I'm
fooking around with iptables I really don't want the distraction of
compiling kernel modules at the same time (I run out of stack space in my
head, mind you that space is *very* limited).

I think my options are:
1. Put up with compiling kernel modules when needed (see above)
2. Compile all modules as embedded in the kernel - wasted space plus some
modules really want to be modular (I've had problems with some of the ALSA
modules being embedded in the kernel)
3. Use a distribution with a pre-compiled kernel
4. Use a modular kernel and compile all (or most) modules

The sweet-spot for me is option 4 but I accept that it will be different for
others.

--
Geoff


First  |  Prev  | 
Pages: 1 2
Prev: Relocating the .ICEauthority (Debian/GNOME)
Next: Wireshark - capture file analysis.