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 pointless. > 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 ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpj3yCZh9IE1.pgp
Description: PGP signature