Re: multistrap rootfs with initramfs
Neil Williams wrote:
> On Fri, 30 Oct 2009 17:27:52 +1100
> "Brendan Simon (eTRIX)" <brendan.simon@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 ??
Reply to: