On Thu, Jan 15, 2009 at 11:12 AM, Rob OpenSuSE
2009/1/15 Jeff Mahoney <jeffm(a)suse.de>de>:
Rob OpenSuSE wrote:
> 2009/1/15 Matt Sealey <matt(a)genesi-usa.com>om>:
>> On Thu, Jan 15, 2009 at 8:53 AM, Rob OpenSuSE
>> <rob.opensuse.linux(a)googlemail.com> wrote:
end user benefits to mountable initrd's, and would have been
a much better workround for one bug, than what I actually had to do.
Actually you would have been just as stuck with squashfs. It's a
read-only file system. You can't loopback mount it and change it. In the
end, you end up having to do the same thing you'd have to do with cpio -
you just replace "zcat initrd | cpio -id" with "mount -o loop".
If it's RO and you can't alter it, then there wouldn't seem to be any
end user benefit apart from casual browsing, to overcome the "if it
ain't broke don't fix it". Just developer benefit through supporting
This is what led me to believe, SquashFS was permitting easier
modification, I think I misunderstood that.
Well, the extract-add-archive step is reduced to add. You don't need
to extract a squashfs archive to add anything to it - mksquashfs will
append files by default, although this can come at the cost of reduced
compression (since it just adds extra inodes, metadata and files at
the end of the current one).
So appending is basically "mksquashfs source/ destination.squashfs"
instead of "gunzip -c cpio.gz | cpio -idmv" then copying in new files
and "cpio -idmv | gzip -c >cpio.gz" kind of stuff.
Actually mounting the file is something done by Linuxrc or so during
the installer - in the current case, boot/arch/initrd32 or so is a
cpio.gz archive with several squashfs files contained in it. the
cpio.gz archive contains ONLY squashfs.ko and loop.ko - enough to
mount these squashfs files. One of the squashfs files is the
lib/modules directory (which has all the modules from the different
`uname -r`/kernel/* directories flattened into a single directory
which is linked into the current root /lib/modules/`uname-r` as
"initrd -> /mounts/00_lib/" or something similar. There are several
others in there which get mounted by some means or another by Linuxrc.
It's quirky, seems to me to be overly complex to be honest. I'm not
sure why you would want the modules seperate in another filesystem
(ease of updating? I dunno.. mkinstallinitrd does this by using a list
of interesting modules from installation-images/etc), but anyway. This
is another discussion. The point is squashfs gets used during the
installer, and from installation-images to build the installer, and is
part of the kernel-source default configuration (currently as a
module) on all architectures anyway through the usual patch process.
So it's in good use right now.
2009/1/14 Matt Sealey <matt(a)genesi-usa.com>om>:
Though mounting, copying to disk, and then re-building the formatted
file, is more like making iso files.
Not so. Rob, again, you've overcomplicated it by looking at it from
your skewed view of things, and not what I actually said or what is
"zcat initrd | cpio -id" and then
rebuilding, wasn't obvious enough to
get suggested when I had an issue with replacing the driver with
mkinintrd on a live system.
You can't replace a file in the initrd on a live filesystem that's
*mounted*. If you want to add files to the initrd, grab your kernel
module name, add it to the list in /etc/sysconfig/kernel
INITRD_MODULES like you said below, and run mkinitrd again (or if
you're being lazy, --force reinstall your kernel package).
It is still a nice to have, as udev generating
it's own module list,
to be combined with INITRD_MODULES, doesn't make the change
methodology clear to the sysadmin.
udev captures the modules "coldplugged" by the system (usually USB and
Firewire) and this gets added to the list in INITRD_MODULES for the
initrd. INITRD_MODULES is basically the list of modules that *has* to
be loaded to get to mount the disk that udev is on (plus anything else
you care to add). This is usually exactly your libata driver and your
root filesystem module (on my system, "pata_mpc52xx xfs", on my
Pegasos, "pata_via", on my VirtualBox systems, "ahci")
The "problem" with adding stuff to the initrd is, is not a problem at
all. Apart from the fact that INITRD_MODULES is generated during the
install? If it installed the wrong driver (via82cxxx for example) for
the disk then it glues that in there and it's not that easy to get it
to automatically fix it.
Matt Sealey <matt(a)genesi-usa.com>
Genesi, Manager, Developer Relations
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org