Re: Solved: Re: chroot issues with accessing /dev/ entries
Hi! On Sun, Apr 27, 2008 at 04:47:53PM +0200, Torsten wrote: OK, thank you, that got me onto the right track, now I think I know what the problem is: mount_mfs. /sbin/mount_mfs -s 9 swap /mnt Is there a way to have devices under that mountpoint? Of course, just mknod(8) them (each time after creating the mfs), Thanks everybody for your help. For whatever reason it did not work (for me) to just copy (pax) the /dev/* files from / to my ramdisk-mountpoint (/mnt). The files were there but always caused a failed to open error when used from within the chrooted environment. It also did not work to first chroot and then (within the chroot environment) create the files with mknod. The latter is clear: mknod is blocked even for root while chrooted. See the kernel sources, /usr/src/sys/kern/vfs_syscalls.c, function sys_mknod(): if ((error = suser(p, 0)) != 0) return (error); If you aren't root, forget it if (p-p_fd-fd_rdir) return (EINVAL); If you're inside a chroot, fail with error code EINVAL. What worked was first creating the files with mknod and then chroot. *nods* You can also use /dev/MAKEDEV for creating the devices. Kind regards, Hannah.
Re: chroot issues with accessing /dev/ entries
I am setting up an embedded system that's supposed to run from RAMDISK only. You really should not do this. The RAMDISK kernel uses the SMALL_KERNEL option, and this can have all sorts of unknown effects. I appreciate you comment, but it seems I'm missing something or there's a misunderstanding. I don't see the connection between using mount_mfs and the ramdisk kernel. I don't think I'm using a ramdisk kernel. I'm using a self compiled standard kernel, only I am creating a ramdisk with mount_mfs in my init-script, copy my stuff into that ramdisk and chroot to it. I don't see there's anything wrong with this? That's not what you said. You said run from RAMDISK only.
Re: chroot issues with accessing /dev/ entries
I am setting up an embedded system that's supposed to run from RAMDISK only. You really should not do this. The RAMDISK kernel uses the SMALL_KERNEL option, and this can have all sorts of unknown effects. I appreciate you comment, but it seems I'm missing something or there's a misunderstanding. I don't see the connection between using mount_mfs and the ramdisk kernel. I don't think I'm using a ramdisk kernel. I'm using a self compiled standard kernel, only I am creating a ramdisk with mount_mfs in my init-script, copy my stuff into that ramdisk and chroot to it. I don't see there's anything wrong with this?
Solved: Re: chroot issues with accessing /dev/ entries
OK, thank you, that got me onto the right track, now I think I know what the problem is: mount_mfs. /sbin/mount_mfs -s 9 swap /mnt Is there a way to have devices under that mountpoint? Of course, just mknod(8) them (each time after creating the mfs), Thanks everybody for your help. For whatever reason it did not work (for me) to just copy (pax) the /dev/* files from / to my ramdisk-mountpoint (/mnt). The files were there but always caused a failed to open error when used from within the chrooted environment. It also did not work to first chroot and then (within the chroot environment) create the files with mknod. What worked was first creating the files with mknod and then chroot. I don't know why this is so, but I'm happy with it.
chroot issues with accessing /dev/ entries
I am setting up an embedded system that's supposed to run from RAMDISK only. Therefore I create a ramdisk, copy everything into it and then chroot. I encounter problems when accessing pcap-libs (or devices in /dev generally) as soon as I actually chroot: # ls -l /dev/bpf0 crw--- 1 root wheel 23, 0 Sep 27 2006 /dev/bpf0 # ls -l /tmp/chroot/dev/bpf0 crw--- 1 root wheel 23, 0 Sep 28 2006 /tmp/chroot/dev/bpf0 # tcpdump tcpdump: listening on fxp0, link-type EN10MB [...] 60 packets received by filter 0 packets dropped by kernel # chroot /tmp/chroot/ /bin/ksh: No controlling tty (open /dev/tty: Device not configured) /bin/ksh: warning: won't have full job control # tcpdump tcpdump: Failed to open bpf device for fxp0: Device not configured tcpdump is just an example. Other programs access bpf0 (exactly) correctly when in the native system and fail to access bpf0 when in chrooted environment. What am I missing? And why is there this tty warning message? The tty device entry is in the chrooted /dev just like it is in the source system. Help will be appreciated! T.
Re: chroot issues with accessing /dev/ entries
On Sat, Apr 26, 2008 at 03:58:25PM +0200, Torsten wrote: # tcpdump tcpdump: Failed to open bpf device for fxp0: Device not configured Is /tmp mounted nodev? Look at mount(8). -ME
Re: chroot issues with accessing /dev/ entries
# tcpdump tcpdump: Failed to open bpf device for fxp0: Device not configured Is /tmp mounted nodev? OK, thank you, that got me onto the right track, now I think I know what the problem is: mount_mfs. This is how I set up the ramdisk: /sbin/mount_mfs -s 9 swap /mnt Is there a way to have devices under that mountpoint?
Re: chroot issues with accessing /dev/ entries
On Sat, Apr 26, 2008 at 05:51:22PM +0200, Torsten wrote: Is there a way to have devices under that mountpoint? If you mount it without nodev, refer to MAKEDEV(8). -ME
Re: chroot issues with accessing /dev/ entries
Hi! On Sat, Apr 26, 2008 at 05:51:22PM +0200, Torsten wrote: # tcpdump tcpdump: Failed to open bpf device for fxp0: Device not configured Is /tmp mounted nodev? OK, thank you, that got me onto the right track, now I think I know what the problem is: mount_mfs. This is how I set up the ramdisk: /sbin/mount_mfs -s 9 swap /mnt Is there a way to have devices under that mountpoint? Of course, just mknod(8) them (each time after creating the mfs), after having mounted the mfs without the nodev flag. Or use the -P flag to mount_mfs. Kind regards, Hannah.
Re: chroot issues with accessing /dev/ entries
I am setting up an embedded system that's supposed to run from RAMDISK only. You really should not do this. The RAMDISK kernel uses the SMALL_KERNEL option, and this can have all sorts of unknown effects. It is castrated Unix, for the purpose of installation. For now, what that option changes in the kernel is fairly limited. But if we start hitting more size constraints regarding the install media space, we the RAMDISK kernel will start violating Unix rules more.
