[Pkg-uml-pkgs] [rootstrap] how to proceed?

[Mattia Dongili]

On Sun, May 14, 2006 at 10:22:55PM +0200, Stefano Melchior wrote:
> Dear all,
> I tried to investigate how rootstrap works and, despite of the fact I did
> know much about python language, I realized the principles of its idea.
> 
> At this moment it fails, above all, because the current method does not
> support anymore or in the proper way the definition on /dev/ubdn devices
> well on the host you attempt to mount/unmount the uml filesystem.
> It launches a linux (indeed the uml kernel) instance to configure the
> newly created filesystem.

The problem is basically that rootstrap mounts host's / as its own / and
/dev is missing proper device nodes (see link below).
Using udev won't probably solve /dev/ubd problems as it might conflict
with an existing udev running on the host (? not tried actually).

> The rest seems to work fine.
> I was wondering if:
> - it is reasonable to patch the current rootstrap to make it works on
>   /dev/ubdn device;

If it's needed to make rootstrap work then it is reasonable.

> - it is reasonable to make the package not to be dependant on
>   user-mode-linux and to make it create a filesystem by using only 
>   deboostrap, then you can automate the process of set the proper config
>   files up.

This is exactely what I was suggesting here:
http://lists.alioth.debian.org/pipermail/pkg-uml-devel/2006-January/000126.html
I think it's way easier generating the rootfs in a loop mounted image.
From the manpage though, I read the the big advantage in current
approach is that it's not necessary to run it as root. Hmmm... this
would be a big loss.

I'm wondering if it makes sense to generate a minimal initrd first using
host binaries and then let rootstrap use this to load the initial fs and
boostrap filesystem creation.
But probably once you have to setup an initrd you'd better setup the
full system...

BTW: I'll probably try to rewrite rootstrap in Perl one day, I hate not
being able to hack on it :)

Bye
-- 
mattia
:wq!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-uml-pkgs/attachments/20060515/14f37a7d/attachment.pgp