Bootloader rootfs

[Werner Almesberger]

Andy Green wrote:
> one only pulls the graphical stuff one wants at the time
> from the filesystem.

Hah, multiple graphical modules. Seems that you have some big plans :-)

> Some bloat is OK if we don't have to pull everything to even get booted,
> ie, we use a rootfs.  I like uclibc because I used it before with good
> results, but we shouldn't consider it if it isn't used with our main
> packages.

Yeah, it's a reasonably easy choice if we find that glibc is getting
too heavy. The more such choices we have, the better.

> We should stop this alternate boot filesystem being a project of its own
> and just make it another (smaller) kind of buildhost rootfs you can get
> and modify at a package level,

That's actually my long-term vision for kboot. Right now, it's kind
of a mini-distribution, but it shouldn't be. I looked at OE back
then, but it would even build, despite numerous tries. Then I looked
briefly at RockLinux, but didn't have the time to do much with it.

Now, we have of course rather substantial OE support at our
disposition, so making OE build the right sort of packages is a
problem I can quite easily "outsource" :-)

> Good, so it means a decent sized (16MB?) rootfs for the alternate boot
> if I understood we synced up that far.

If you provide more space, I don't mind :) This discussion started
with "initramfs is bad because it's expensive to load something big".
So I explained that you can actually get a lot done in very little
space. But sure, if you find that you really need more space, it's
good to have provided for it.

I'd also caution against getting far too carried away with a kboot
environment. It shouldn't become a place where people choose to live.
Or else, all the factors that may destabilize the regular system also
start to appear there.

- Werner