Re: Init.c, making it chroot




M. Warner Losh wrote:
Oliver Fromme <olli@xxxxxxxxxxxxxxxxx> writes:
: Thanks for the new patch, I'll try it as soon as possible.

I got a few minutes and tested it.

I don't have the proper environment to easily test this
out, but I think what I sent will work...

It does work indeed! With that patch, the chrooted system
boots fine into multi-user mode and I get a login prompt.

If you would like to look at my ISO (or anybody else who's
following this thread):

http://www.secnetix.de/tmp/init_chroot/

The ISO is 17 MB compressed (I removed some stuff to keep
it small). Actually it's pretty much a standard FreeBSD
base system. There's also an ls -alR listing on the URL
above.

The directory structure on it looks like this:

/boot
/ochroot
/ochroot/bin
/ochroot/boot
/ochroot/dev
/ochroot/etc
/ochroot/...

i.e. basically everything is located under /ochroot, except
for /boot which is hardlinked from /ochroot/boot (to save
space).

In particular, there is no /dev, so I still get this one
from the kernel:

Lookup of /dev for devfs, error: 2

But then init and everything starts up fine, so it doesn't
seem to cause any harm. That raises two questions:

1- Why does the kernel try to mount /dev at all? Why not
simply let init mount it in all cases, with ot without
init_chroot? Would make things simpler. There doesn't
seem to be a clear reason why the kernel needs to mount
it. (Or maybe there _are_ reasons, byt they don't
appear during my testing.)

2- Another solution would be to let init(8) autodetect
whether /dev needs to be mounted. However, that might
not be as trivial as it sounds.

By the way, testing the whole thing is easy. Just install
qemu from ports, then run this command:

qemu -monitor stdio -cdrom chroot-test.iso -boot d

Creating the ISO (with mkisofs) takes 5 seconds, and booting
it in qemu takes 10 seconds (even without the kqemu kernel
accelerator module), so the development and testing cycles
are very short. That's how I developed my CD/DVD boot
manager "eltoro"[1]. As soon as the ISO runs successfully
in qemu, I write it to a CD-RW and boot it on a real PC
for verification.

Best regards
Oliver


PS: [1] http://www.secnetix.de/products/eltoro/

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination
of their C programs."
-- Robert Firth
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: file system problem
    ... Patch your kernel sources an recompile with the options: ... See in dmesg how have been named the 3 Minix ... Create 3 directories to mount them: ...
    (comp.os.minix)
  • Re: Cant mount STABLE partition as read write!!!!!
    ... The recommendation was to patch the kernel. ... When you mount the partition read-only, do the files have weird dates? ...
    (comp.unix.solaris)
  • Re: Good fdisk Practices
    ... privileges, and if you have that, you can do 'mount /boot'. ... but a trojan trying to patch the kernel ... To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx ...
    (Debian-User)
  • [BUG]: Crash with CONFIG_FAIR_CGROUP_SCHED=y
    ... If we skip the 'mount' command, there is no crash. ... mounting just the cpu or just the ns subsystem does not ... Kernel 2.6.24-rc1 on an x86_64 ...
    (Linux-Kernel)
  • Re: RT patch acceptance
    ... judge the complexity of a design for that type of system. ... claim that you cannot judge the complexity of a kernel modification. ... Since the patch in question doesn't actually need that information to ... nanokernel's API up to date with additions to Linux's API that RT people ...
    (Linux-Kernel)