-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Dan Nicholson wrote:
> Nice to see this come to light. It's needed, not just for LVM, but
> for the general problem of "I want to make a generic modular kernel".
True. The current book doesn't really support modular kernels, but
that's not necessarily a good reason to keep it that way, either. :-)
(Though there may well be other reasons, especially if the reader hasn't
done much with modules before.)
> ldd is fine, IMO.
Yeah, it's not so much ldd that I don't like, it's all the extra stuff
going on around it. But:
> One suggestion for the loop of finding libraries. awk does everything
> you need in one shot:
>
> $ ldd /sbin/modprobe | awk '/=> \//{print $3}'
Yikes, that is a *LOT* simpler. Thanks! :-) (It doesn't grab the
dynamic loader, but that should be fairly easy: ldd | tail | awk. Or
hardcode it, but it's a different file for 64-bit.) That's r14. ;-)
> This is what I'm using in my very unscientific experience (much of
> which came from the Fedora mayflower script for their LiveCD):
That looks similar to what the LFS livecd's Makefile does, too.
Although the livecd grabs
.../drivers/{ata,base,block,cdrom,ide,message,scsi,pcmcia,usb/{core,host,storage,input}},
a whole bunch of specific FSes, and all of .../kernel/lib. (Not
.../kernel/input though.)
> The input stuff is there so I can drop to a shell, but you're not
> doing that.
Not here, but I had a lot of simple "bash" calls in there while I was
testing it out. So it's probably still a good idea to include them,
especially if we tell the user "you may need to do some debugging".
Hopefully that won't be needed, but it can't hurt much to include them,
IMO.
> Another thought is to allow something like /etc/sysconfig/boot to
> allow people to specify the specific modules they want.
Would that work before the rootfs is mounted?
Oh, I think I see -- you'd read that while mkinitramfs was running.
That's probably a good idea (or have an option for the module list, but
a sysconfig file is probably better since it'd be a pain to specify all
these names every time you run the script). For that matter, maybe it
should be an /etc/mkinitramfs.conf file; I think I've seen similar files
in other distros. Syntax would be simple to process: it'd just be
sourced from the mkinitramfs script like our current sysconfig files are
from the bootscripts.
> In my experience, you can leave out most of the rules since we'll run
> udevd again in the real init and it will set up all our groups, etc.
Well, I wanted enough to do at least the persistent-storage symlinks, to
allow root=/dev/disk/by-uuid/* and friends, and perhaps also persistent
input. (Persistent net may be needed if somebody wants to do NFS, but
I'm ignoring NFS for now. More so because the persistent net stuff
generates rules on-demand, and it's hard to sync those between the root
FS and the initramfs.) 26-modprobe.rules is also required, to load
(e.g.) SCSI or usb-storage drivers.
But it does look like a lot of 25-lfs.rules likely isn't needed. I
probably need to rethink that part of the script.
> klibc's mount also doesn't like the "defaults" option. This is a
> problem for me because I embed fstab into the initramfs to assist in
> guessing the root partition, and I often have "defaults" as the
> options for my partitions.
Well, "mount -t <type> $root /.root" gets me up and running. :-P
I'm not sure what to do in general here. I wonder if a ROOTFLAGS option
in the config file would work for that, instead of including fstab? Of
course it'd have to be kept up to date, but if we include fstab, the
user would have to re-create the initramfs when fstab's root options
change anyway. (Actually that applies to any files that we include: if
they change on the root FS, the user needs to regenerate the initramfs.
The list of dependencies probably needs to be specified somewhere.)
> I'm inclined to punt for 6.3
That's fine by me. I think 6.3 would probably be way too soon for
anything that we can put together now anyway.
> Allow the output file to be specified.
Good one. :-) r15.
> Possibly require -f|--force if it will overwrite an existing file.
I'd be more inclined to have it work like rm/cp in that case: only
require -f if -i was specified and the file exists. OTOH, common usage
is probably going to be making a new initramfs for a newly-compiled
kernel, so it won't really matter, and so it probably makes sense to
make it safer by default.
This'll be r16 (but tomorrow).
> I still believe we could easily add cpio to LFS, and it may be more
> desirable than gen_init_cpio.
cpio probably makes more sense if the script is going to build a tree
somewhere (probably in the same /tmp directory that I'm using to process
udev rules) and then make that into a cpio archive. I wanted to avoid
temporary files completely, but that's already not happening because of
udev. (I suppose there's a fairly easy fix to that, too: include
/etc/group, a bare-minimum /etc/nsswitch.conf containing "group=files",
and /lib*/libnss_files.so.*. Or drop any udev files with GROUP in
them.)
> Oh, a bit more food for thought on existing initramfs solutions, this
> is what Jürg is using on paldo. He says he hasn't needed to change it
> in a long time.
>
> http://www.paldo.org/paldo/sources/linux-2.6/initramfs-init-20070426-2
Interesting. Looks like it uses more of the klibc tools, but that's not
a huge deal. It also does a lot of squashfs stuff that's probably
completely unnecessary for us, but hey whatever.
It's also a lot farther ahead in terms of dm-raid support, but then,
that's to be expected, since (a) it's not brand-new, and (b) its author
probably uses dm-raid. ;-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGd0NuS5vET1Wea5wRA0gLAKCJhBYqVW9tPFjnQL3UDXdWjAcUCgCeJZo8
rwexv1guMUbUeaRj3UZj31s=
=+qp5
-----END PGP SIGNATURE-----
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
