On Tue, Aug 18, 2009 at 11:57:13AM +0100, Matthew Booth
wrote:> I hit the following weirdness in guestfish:
>
> ><fs> ll /../proc/modules
> -r--r--r-- 1 root root 0 Aug 18 10:37 /sysroot/../proc/modules
>
> ><fs> cat /../proc/modules
> libguestfs: error: open: /../proc/modules: No such file or directory
>
> The underlying reason for this seems to be that ll uses sysroot_path to
> establish a path before operating on it, whereas cat uses CHROOT_IN and
> CHROOT_OUT to open() inside a chroot. It seems to me that wherever a
> path is used directly by a command, there should never be a reason to
> use chroot because the real path can always be worked out. The only
> place I see for using a chroot is in command and sh.
>
> Is it worth making a bulk CHROOT_IN and CHROOT_OUT removal patch?
No, because it would be the wrong thing to do.
First of all, the command "ll /../proc/modules" is undefined
behaviour. You probably meant to use this command:
debug ll /proc/modules
http://git.et.redhat.com/?p=libguestfs.git;a=commitdiff;h=24a6cf4533118e04367f7fcdc6eadaa4e2dfbc56
Of course, that won't work unless libguestfs was configured with debug
enabled (./configure --enable-debug-command), and that is intentional.
I can't see a reason why you'd want to see the list of kernel modules
installed in the appliance, but if there is a reason, it should be
exposed as a new command.
On the wider issue, as many commands as possible should be changed to
use chroot. However in cases where we have to run an external binary
in the appliance (as in 'll' which runs /bin/ls) we cannot use chroot,
because the binary isn't located in the chroot, so we have to prefix
paths with sysroot and hope for the best. This is a compromise, and
chroot would be more desirable if we were able to use it.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top