[Russell, it would be great if you could comment on this issue.]
Am Donnerstag, den 12.08.2010, 09:15 +0100 schrieb Ian Campbell:
> On Wed, 2010-08-11 at 20:56 +0200, Paul Menzel wrote:
> > Am Mittwoch, den 11.08.2010, 10:40 +0100 schrieb Ian Campbell:
> > > On Wed, 2010-08-11 at 00:05 +0200, Paul Menzel wrote:
> > > > $ grep vmlinuz /tmp/squeeze.cfg
> > > > kernel = "/tmp/vmlinuz"
> > > > $ sudo xm create /tmp/squeeze.cfg
> > > > Using config file "/tmp/squeeze.cfg".
> > > > Error: Kernel image does not exist: /tmp/vmlinuz
> > > >
> > > > Do you have any idea? This is with the daily Debian Installer files from
> > > > [2].
> > >
> > > Hrm. I assume /tmp/vmlinuz exists and is readable by the relevant user
> > > etc. Do the logs in /var/log/xen tell you anything?
>
> [snip logs]
>
> Thanks but unfortunately I am none the wiser :-(
>
> > I took a look where `VmError` originates from. I think, it turns out to
> > be in `/usr/lib/xen-3.2-1/lib/python/xen/xend/image.py`.
> >
> > if not os.path.isfile(self.kernel):
> > raise VmError('Kernel image does not exist: %s' % self.kernel)
> >
> > But testing this manually works.
> >
> > $ python
> > >>> import os
> > >>> os.path.isfile("/tmp/vmlinuz")
> > True
>
> Very strange.
I also tried the above script with `sudo python` and I got the same
result (»True«).
> It is likely that the process actually running is different to the user
> you used for this test so perhaps there is something about the
> permissions either on the files themselves or the /tmp directory or
> something?
>
> I presume this:
> $ ls -l /tmp/{vmlinuz,initrd.gz}
> -rw-r--r-- 1 user user 17859729 2010-08-10 10:05 /tmp/initrd.gz
> -rw-r--r-- 1 user user 2351776 2010-08-10 10:05 /tmp/vmlinuz
> is still true? But what about the perms on / and /tmp?
>
> It's unlikely but I suppose I have to ask: are you using xm on a
> different machine to the one running xend? (via either the XML/RPC or
> SXP/RPC mechanisms).
>
> It might be worth doing chmod root:root on the two files.
I already did that and it did not change anything. I am running the `xm`
command using `sudo` and they are all readable (`r`) so there should not
be any problem.
Looking at the attributes of `/boot/` and `/tmp/` using `ls -lZ` I get.
drwxr-xr-x 4 root root system_u:object_r:boot_t:s0 4096 2010-08-11 18:43 boot
drwxrwxrwt 9 root root system_u:object_r:tmp_t:s0 4096 2010-08-12 08:50 tmp
SELinux is running on my system. But I changed it into permissive mode
back then when debugging and that did not change anything either. But I
do not know much about SELinux, so I just blame it for now. :(
> > Then I tried it with a different Linux kernel image under `/boot/` and
> > this worked. So as a last attempt I copied `vmlinuz` from `/tmp/` to
> > `/boot/` and now it works as expected. Very strange! Do I need to file a
> > bug for this somewhere. Could you test that under Squeeze or Sid?
>
> I tried it under squeeze and it seems fine.
>
> # grep kernel /etc/xen/debian-x86_32p-1
> #kernel = "/boot/vmlinuz-x86_32p-xenU"
> #kernel = "/boot/vmlinuz-2.6.32-5-xen-amd64"
> kernel = "/tmp/vmlinuz-2.6.32-5-xen-amd64"
> #kernel = "/scratch/lenny/i386/vmlinuz"
> # ls -l /tmp/vmlinuz-2.6.32-5-xen-amd64
> -rw-r--r-- 1 root root 2467552 Aug 12 09:09 /tmp/vmlinuz-2.6.32-5-xen-amd64
Thank you for confirming this.
Thanks,
Paul
Attachment:
signature.asc
Description: This is a digitally signed message part