[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: multistrap rootfs with initramfs

On Sat, 31 Oct 2009 23:33:58 +1100
"Brendan Simon (eTRIX)" <brendan.simon@etrix.com.au> wrote:

> initramfs (linux 2.6) is similar to initrd (linux 2.4) except that there
> is no concept of a block dev filesystem.  Basically the files are loaded
> right into the kernel VFS memory cache from an embedded cpio.tgz
> archive.  The advantages are that you don't have a files in a RAM disk
> _and_ also cached in kernel RAM, and that no drivers are needed to read
> the block device filesystem (eg. ext2).  Also you can have a proper
> 'init' instead of the /linuxrc hack.
> So if the inittab can be setup to run 'dpkg --configure -a', either
> every boot or by detecting the first boot, then telinit into the proper
> runlevel, then things could work well ??

'dpkg --configure -a' is idempotent so it could be run every time - it
would probably waste a second or two but the more packages get
installed, the longer dpkg will take to start up. I've heard of ways of
detecting first boot but I haven't tried any for real.

> An other alternative could be to have an early rc.d script that could
> run 'dpkg --configure -a' ??

Probably too late - that's the issue, the maintainer scripts have not
been run at all, not even preinst ones. For Grip 2.0, I'm going to be
testing things like this to see just how far things can go before the
unconfigured packages break things. By all means go ahead and test then
put the results on the Wiki.

> >> Is booting into a multistrap rootfs possible.
> > 
> > Yes. You do need to arrange for the configure scripts to be run
> > beforehand. The main thing that breaks (IIRC) is that ldconfig has not
> > been setup, so you have to take avoid executables using shared
> > libraries.
> Is this just setting entries in /etc/ld.so.conf ??

No, I don't think so but testing is needed to prove it one way or the
other. Issues with ldconfig not being run were simply the first error
that I hit when experimenting with Grip 1.0 - if only ldconfig is
handled, other errors may follow. It's a cascade problem.

> Could there be some basic entries to start with, based on the known
> architecture ??

Probably, it's worth a try. It depends how far the boot can get before
it fails with ldconfig type issues - if the boot really doesn't get far
enough to even call init then all bets are off. If it gets as far as
starting the calls to /etc/rc.d/* then things are very different. I'm
also not sure how much of this is hardware-dependent - or probably
bootloader specific / kernel version specific / architecture specific.
Most tests have been with armel which makes discussions about initramfs

> I notice with fakeroot that all files are owned by root, so when
> generating a cpio.tgz file (or accessing any of the files in general)
> they will all be owned by root.  Shouldn't some files be owned by other
> uids ?? 

Yes. Take a look at how existing Debian packages handle such things
because all of those are built with fakeroot.

> If multistrap creates files that are owned by uid!=0, does
> fakeroot honour that ??  If not, then maybe the best option is to
> somehow write directly into a tar or cpio file that will have the
> correct uids.  Maybe sudo into /tmp/<xxx>, unpack, tar/cpio, the exit is
> the way to go ??

IIRC fakeroot takes notice of the REAL_UID and knows about uid=0, so if
a file is neither of those, it should preserve it - that's what should
happen when building a Debian package. (fakeroot doesn't check whether
the UID selected is usable, that's left to the maintainer scripts to
sort out with adduser etc.)


Neil Williams

Attachment: pgpSWyH7hA0nH.pgp
Description: PGP signature

Reply to: