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?
signature.asc
Description: Digital signature
