Neil Williams wrote: > On Fri, 30 Oct 2009 17:27:52 +1100 > "Brendan Simon (eTRIX)" <brendan.si...@etrix.com.au> wrote: > >> I'm looking at using multistrap to create a rootfs that can be passed >> to a linux build for an initramfs. > > The thought had crossed my mind a few times but I've no experience with > initramfs. > >> Is it feasible to create a linux image with an initramfs based on a >> multistrap rootfs ?? > > Sorry, I have no idea.
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 ?? An other alternative could be to have an early rc.d script that could run 'dpkg --configure -a' ?? >> 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 ?? Could there be some basic entries to start with, based on the known architecture ?? >> One issue is that I do prefer not to build as root, even via sudo. > > I've had my issues with that - famously requiring the complete > reinstallation of this laptop after one late night typo involving > cleaning up after a failed test script and the complete removal > of /etc/ - but with care, scripts can be written to avoid these > problems. It is the developers who take those risks. As these things > go, whether you are logged in as root or using sudo makes absolutely no > difference. Also, think of the case where you have a team of developers with accounts on the one machine (eg. a server). Building as root just isn't an option in a controlled environment like that. Users must be able to build final images as their own user. Ideally without sudo, but using sudo or fakeroot in controlled scripts is a typical workaround. >> Either fakeroot or initramfs control files are required to ensure the >> files have the correct permissions, uids and gids. > > emgrip uses fakeroot for these reasons, multistrap needs real or sudo > root to be able to work properly but you can run other commands under > fakeroot, once multistrap has finished. 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 ?? 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 ?? -- To UNSUBSCRIBE, email to debian-embedded-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
