[Pkg-uml-devel] rootstrap problems

[Andreas Schuldei]

hi!

i am hacking on rootstrap here. for those unfamiliar with
rootstrap: it is a bunch of python and shell scripts to create a
new root filessytem image. it does that by running a uml and
mounting the host's / filesystem as / using hostfs. 


i try to do two things: fix the problem with

request_module: runaway loop modprobe net-pf-1
modprobe: FATAL: Could not load /lib/modules/2.6.12/modules.dep: No such file or directory

(since on debian the hostfs has the uml modules in
/usr/lib/uml/modules and the uml kernel expects them at
/lib/modules).

and i try to make rootstrap not depend on devfs. (currently
rootstrap still uses the devfs=mount option.)

I try to solve the first problem by adding a line
os.system("mount --bind /usr/lib/uml/modules /lib/modules") at
the beginning of the initialisation code in
/usr/lib/rootstrap/builder (which runs as an init replacement in
the uml).

I still get the above error when starting up, but that is because
I mount this AFTER the modprobe process got dispatched.  Later on
modprobe finds the module and it works and the error goes away.
It would be best to add the bind-mount command on the uml command
line, somehow. Does anyone know how that could work?

Alternatively one could try to set the enrivonment variable
MODPROBE_OPTIONS, redirecting modprobe to /usr/lib/uml/modules.
It is not clear to me what the variable should contain, though
and it would have the same startup problem. Or can i specify
environment vars on the uml commandline?

The second problem with devfs seems trickier. devfs used to
clobber /dev and a /dev/ubd/disc1 was garanteed to be present
(and used with mkfs and mount later on). If rootstrap uses the
host's /dev it can not rely on /dev/ubdX to be present, since
those devices are non-standard. Even when I create those in my
host's /dev/, I get oopses (which I did not have when using
devfs). 

such a oops looks like this: 

idr_remove called for id=3 which is not allocated.
a08ffa1c:  [<a00aa8a0>] sub_remove+0xc6/0xcf
a08ffa58:  [<a00aa8c7>] idr_remove+0x1e/0x84
a08ffa70:  [<a00b439f>] release_dev+0x567/0x580
a08ffadc:  [<a00b3b98>] init_dev+0x3d5/0x4f8
a08ffb20:  [<a00b4576>] tty_open+0x1be/0x30b
a08ffb2c:  [<a00aad62>] kobject_get+0x12/0x17
a08ffb38:  [<a0065320>] cdev_get+0x20/0x46
a08ffb48:  [<a00654cd>] exact_lock+0x9/0x10
a08ffb4c:  [<a00bcbad>] kobj_lookup+0xe9/0x135
a08ffb74:  [<a006544d>] chrdev_open+0xd7/0xf0
a08ffb94:  [<a005d5df>] dentry_open+0xbe/0x187
a08ffbb0:  [<a005d519>] filp_open+0x41/0x49
a08ffbcc:  [<a0018981>] strncpy_chunk_from_user+0x0/0x4f
a08ffbf0:  [<a005d6fb>] get_unused_fd+0x53/0x99
a08ffc04:  [<a005d7d9>] sys_open+0x32/0x68
a08ffc20:  [<a001830a>] execute_syscall_skas+0xde/0xe8
a08ffc98:  [<a0018327>] handle_syscall+0x13/0x24
a08ffcac:  [<a0017b05>] userspace+0x21e/0x25b
a08ffce0:  [<a00184e6>] force_flush_all_skas+0x1f/0x25
a08ffcfc:  [<a0018060>] fork_handler+0xb6/0xba
a08ffd5c:  [<a0125a11>] __kill+0x11/0x20

what exactly does this mean? how can i fix it?

since udev is a fat userspace program with lots of config etc i
dont expect using it will fix the problem. or would it? if so,
how?


-------------- 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-devel/attachments/20060111/ef46bae5/attachment.pgp