[Replying to a whole bunch of messages here...] Nathan Coulson wrote: > /usr on a seperate partition: In the past when I was more involved > in the bootscripts, I setup my system to ensure this feature worked > for the sole reason that it is part of the standard. I felt that if > there was no cost or complexity in using /usr on a seperate > partition, then there was no reason not to pursue it. If the > standards change, then we should change with them.
Interestingly, Fedora is trying to push everyone who does this to use an
initramfs to mount /usr. :-/
Zachary Kotlarek wrote:
> If you run really vanilla disk configuration, and don't have exotic
> hardware/software required to mount root (or make your
> keyboard/display/etc. work) you probably will never need an
> initramfs. But that seems like a big limitation to me, and I'm not
> sure what the downside to an initramfs is, other than you'd have to
> install cpio and run a script from time to time if you changed your
> early boot scripts.
You don't even need cpio, and in fact I strongly prefer not to (except
when debugging the output of the script). You can use a program whose
sources are distributed with the kernel, which takes in a pretty simple
text format description, and generates a cpio-format archive for you
(without having cpio installed).
That text-format description is *much* easier for me to debug when I'm
seeing issues with it, than even a shell script that builds a directory
tree and runs cpio against it. (And certainly easier to debug than a
binary that builds a directory tree.) Of course the mkinitramfs shell
script that I have basically just echos this format through the program
from the kernel, so there's some shell involved. But it does feel
easier to edit.
(See the hint I wrote up a while back. The version of most of the tools
is probably out of date, and the udev-rule-sed stuff that I was doing
may ot be needed anymore, but the sources for the initramfs generator
work this way.)
> Also note that, while it's not the method employed by popular
> distros, it's entirely possible to create an initramfs that doesn't
> need to be rebuilt every time you change your udev config or other
> such things,
It'll still need to be rebuilt with each kernel, though? Perhaps not if
you don't include any modules in the image, *and* you build all the
stuff into the kernel that's required for the rootfs. Hmm. That feels
like a very specific kernel setup, although we require something vaguely
similar ("no modules at all" is the suggestion) today.
(Some hardware or pseudo-hardware RAID cards will require external
firmware though. I don't know if those images depend on the kernel at
all or not. Perhaps not; if it depends on the kernel build, then it's
maybe built into the driver, not in /lib/firmware.)
> A well-designed initramfs is also an always-available rescue boot
> system, which is handy for the sort of people that write the own boot
> scripts.
Yeah, and in fact the Fedora wiki page talking about this change to put
everything into /usr says that an initramfs or a livecd are the only
ways to rescue a system anymore.
Nathan Coulson wrote:
> I really like that one I did a couple months ago. There was a kernel
> option for mounting something on /dev that came with entries
> (devtmpfs).
That's actually required now, with udev-176 or newer.
> Changing my opinion a bit, one feature that I have been missing is
> the ability to mount based on UUID instead of the partition.
Yep; run udev in the initramfs and you get /dev/disk/by-uuid/* mostly
for free. :-) I use a UUID to find the encrypted volume that, after
decryption, turns into the LVM PV, which holds a whole bunch of volumes
including the rootfs.
Nathan Coulson wrote:
> I still like the idea, that it "adds" to lfs, as opposed to being
> "required" though. (And by that, I mean leave assumptions out of the
> bootscripts that this was booted on a initramfs/initrd)
Absolutely. This is what made it possible to actually *do* the hint
that I put together a few years ago, without including networking
support: it didn't matter what groups or group resolution systems were
configured on the host; the initramfs system ignored all of them. (It
omits /etc/nsswitch.conf, and I think /etc/group, and definitely NIS,
and all or most of the glibc libnss_* libs.)
Everything in the initramfs ran as root anyway, so it's fine to not care
about groups in the udev config. The /dev that udevd builds is thrown
away when it does the run-init call, and it's all rebuilt in the final
system's bootscripts.
It would have been much more complicated (and required modifying the LFS
bootscripts) to try to port over the in-initramfs /dev to the final
system, let alone trying to keep udevd running while it happened (to
avoid losing uevents from poorly-timed hotplug operations). Keeping the
two setups separate is a *huge* win.
Zachary Kotlarek wrote:
> To be fair, GRUB 2 can read LVM.
I don't believe that's relevant here, actually. That only means that
it's possible to put the /boot files onto LVM, and read them from there
with grub2. You still need an initramfs to get the rootfs mounted;
grub2 will not do that for you. (The kernel won't let it.) And the
kernel doesn't handle rootfs-on-LVM on its own.
> But it does that by having it's own partition and loading LVM drivers
> from there
...Oh. So you'll still have a separate /boot. Meh. :-)
> -- it's functionally the same as using an initramfs to find the root
> FS.
grub doesn't care about the rootfs, it only looks for the kernel image
and (if configured) an initramfs file. :-)
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
