5:57 a.m.
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?
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
6:45 a.m.
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=24a6cf4533118e0...
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
6:51 a.m.
On Tue, Aug 18, 2009 at 12:45:02PM +0100, Richard W.M. Jones wrote:
First of all, the command "ll /../proc/modules" is
undefined
behaviour. You probably meant to use this command:
debug ll /proc/modules
I mean ...
debug sh "cat /proc/modules"
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
5577
days inactive
5577
days old
2 comments
2 participants
participants (2)
-
Matthew Booth -
Richard W.M. Jones