DomU boot on Fedora 6 fails with 'no root found' error.

[K T Ligesh]

 I am trying to get Xen running on Fedora 6, which I thought would be easy, but I guess
not. I am using the standard image from jailtime.org and my domU configuration file is
below. I am using the same kernel of the host itself.

------------
 kernel     = '/boot/vmlinuz-2.6.19-1.2895.fc6xen'
 ramdisk    = '/boot/initrd-2.6.19-1.2895.fc6xen.img'
 memory     = 512
 name       = 'test.vm'
 vif        = ['vifname=vif-test0,  mac=aa:00:f6:f4:06:1a']
 vnc        = 0
 vncviewer  = 0
 serial     = 'pty'
 disk       = ['file:/home/test.vm//root.img,sda1,w',
'file:/home/test.vm//vm.swap,sda2,w']
 root = '/dev/sda1 ro'
 ------------------

-------------------
 Loading dm-zero.ko module
 Loading dm-snapshot.ko module
 Making device-mapper control node
 Scanning logical volumes
   Reading all physical volumes.  This may take a while...
     No volume groups found
	 Activating logical volumes
	   Volume group "VolGroup00" not found
	   Creating root device.
	   Mounting root filesystem.
	   mount: could not find filesystem '/dev/root'
	   Setting up other filesystems.
	   Setting up new root fs
	   setuproot: moving /dev failed: No such file or directory
	   no fstab.sys, mounting internal defaults
	   setuproot: error mounting /proc: No such file or directory
	   setuproot: error mounting /sys: No such file or directory
	   Switching to new root and running init.
	   unmounting old /dev
	   unmounting old /proc
	   unmounting old /sys
	   switchroot: mount failed: No such file or directory
	   Kernel panic - not syncing: Attempted to kill init!

--------------------------

The above is the error I got. It seems the initrd is searching for volGroup00, which is
how the '/' of the HOST is mounted, but I have explicitly given 'root ='
in the config file. So I am confused.  Is there anyone here who has experienced this
beforehand?

 Thanks in advance.

[Daniel P. Berrange]

On Wed, Jan 31, 2007 at 07:28:25PM +0530, Ligesh wrote:
>  
>   I am trying to get Xen running on Fedora 6, which I thought would be easy, but I guess
> not. I am using the standard image from jailtime.org and my domU configuration file is
> below. I am using the same kernel of the host itself.
>  
>  ------------
>   kernel     = '/boot/vmlinuz-2.6.19-1.2895.fc6xen'
>   ramdisk    = '/boot/initrd-2.6.19-1.2895.fc6xen.img'
>   memory     = 512
>   name       = 'test.vm'
>   vif        = ['vifname=vif-test0,  mac=aa:00:f6:f4:06:1a']
>   vnc        = 0
>   vncviewer  = 0
>   serial     = 'pty'
>   disk       = ['file:/home/test.vm//root.img,sda1,w',
> 'file:/home/test.vm//vm.swap,sda2,w']
>   root = '/dev/sda1 ro'
>   ------------------ 
Xen filesystem images should be kept in /xen (legacy location) or
/var/lib/xen/images (recommended location) otherwise SELinux will
deny the VM access to the files & the guest will be unable to
mount its filesystem. I suspect this could be what's causing your
VM to not find its root filesystem.

>  	   Volume group "VolGroup00" not found
>  	   mount: could not find filesystem '/dev/root' 


Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Atsushi SAKAI]

Hi,　Dan

　It seems to be initrd is not configured for DomU.
Is my guess wrong?
or currently initrd is shared by domU and Dom0 on FC6?

Thanks
Atsushi Sakai


"Daniel P. Berrange" <berrange(a)redhat.com&gt; wrote:

>  On Wed, Jan 31, 2007 at 07:28:25PM +0530, Ligesh wrote:
>  > 
>  >  I am trying to get Xen running on Fedora 6, which I thought would be easy, but I
> guess not. I am using the standard image from jailtime.org and my domU configuration file
> is below. I am using the same kernel of the host itself.
>  > 
>  > ------------
>  >  kernel     = '/boot/vmlinuz-2.6.19-1.2895.fc6xen'
>  >  ramdisk    = '/boot/initrd-2.6.19-1.2895.fc6xen.img'
>  >  memory     = 512
>  >  name       = 'test.vm'
>  >  vif        = ['vifname=vif-test0,  mac=aa:00:f6:f4:06:1a']
>  >  vnc        = 0
>  >  vncviewer  = 0
>  >  serial     = 'pty'
>  >  disk       = ['file:/home/test.vm//root.img,sda1,w',
> 'file:/home/test.vm//vm.swap,sda2,w']
>  >  root = '/dev/sda1 ro'
>  >  ------------------
>  
>  Xen filesystem images should be kept in /xen (legacy location) or
>  /var/lib/xen/images (recommended location) otherwise SELinux will
>  deny the VM access to the files & the guest will be unable to
>  mount its filesystem. I suspect this could be what's causing your
>  VM to not find its root filesystem.
>  
>  > 	   Volume group "VolGroup00" not found
>  > 	   mount: could not find filesystem '/dev/root'
>  
>  
>  
>  Dan.
>  -- 
>  |=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
>  |=-           Perl modules: http://search.cpan.org/~danberr/              -=|
>  |=-               Projects: http://freshmeat.net/~danielpb/               -=|
>  |=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 
>  
>  --
>  Fedora-xen mailing list
>  Fedora-xen(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-xen

[K T Ligesh]

On Wed, Jan 31, 2007 at 11:12:10PM +0900, Atsushi SAKAI wrote:
>  Hi,?$B!!Dan
>  
>  ?$B!!It seems to be initrd is not configured for DomU.
>  Is my guess wrong?
>  or currently initrd is shared by domU and Dom0 on FC6?
>   
 Yes, I think that's the issue. Do you need separate initrds for each ostemplate? How
do I create an initrd for a specific template? Does the initrd contain the fstab info?

 Thanks a lot.

[K T Ligesh]

 I found the problem. It is with the initrd. It contains the 'init' program which
seems to be trying to use LVM to do everything because host is configured on LVM, and
since the guest doesn't have lvm configured it fails. So from where do I get a simple
initrd image, that will not attempt to do acrobatics with the lvm?

 Thanks.

[K T Ligesh]

 I would say that the fedora xen is broken, since I don't think we can use it easily
to create a domU using pre-built templates. The initrd for the xen kernel seems to be
built to use features that are not at all available on the domU, and there are no simple
initrds available either. This is on 32 bit. On 64 bit, the initrd fails to even recognize
the xen vbd devices and fails miserably.

 Is there a tutorial on how to create domUs using pre-built templates from jailtime.org?

 Thanks.

I would agree it's broken as I've also been unable to get guests to work
"out of the box". I've found the problem to be a missing kernel module in
the initrd, required for disk access (xenblk.ko). If I build an initrd
with xenblk.ko included, guests boot fine.

I just make an initrd this command:

mkinitrd --with=xenblk.ko /boot/your_image_name.img your_kernelname

Just use the kernel name from uname -a

mkinitrd --with=xenblk.ko /boot/initrd_test.img 2.6.19-prepcifs_fix

[K T Ligesh]

On Wed, Jan 31, 2007 at 06:54:34AM -0800, master(a)bradleyland.com wrote:
>  I would agree it's broken as I've also been unable to get
> guests to work
>  "out of the box". I've found the problem to be a missing kernel module in
>  the initrd, required for disk access (xenblk.ko). If I build an initrd
>  with xenblk.ko included, guests boot fine.
>  
>  I just make an initrd this command:
>  
>  mkinitrd --with=xenblk.ko /boot/your_image_name.img your_kernelname
>  
>  Just use the kernel name from uname -a
>  
>  mkinitrd --with=xenblk.ko /boot/initrd_test.img 2.6.19-prepcifs_fix 
Thanks, but my problem is that the 'init' inside the initrd is runing lvm
commands, probably because it was built on a host that has LVM, and I need to remove these
lvm commands from the init inside the initrd. How do I do that? 

Your above solution would have solved my problem yesterday when I ran into this, but now I
have reimaged the server using LVM, and I am facing yet another problem.

thanks.

[K T Ligesh]

On Wed, Jan 31, 2007 at 09:13:35PM +0530, K T Ligesh wrote:
>  On Wed, Jan 31, 2007 at 06:54:34AM -0800, master(a)bradleyland.com
> wrote:
>  > I would agree it's broken as I've also been unable to get guests to work
>  > "out of the box". I've found the problem to be a missing kernel module
> in
>  > the initrd, required for disk access (xenblk.ko). If I build an initrd
>  > with xenblk.ko included, guests boot fine.
>  > 
>  > I just make an initrd this command:
>  > 
>  > mkinitrd --with=xenblk.ko /boot/your_image_name.img your_kernelname
>  > 
>  > Just use the kernel name from uname -a
>  > 
>  > mkinitrd --with=xenblk.ko /boot/initrd_test.img 2.6.19-prepcifs_fix
>   
 This is the actual error, the LVM errors turned out to be a red herring.

---------
XENBUS: Device with no driver: device/vbd/2049
XENBUS: Device with no driver: device/vbd/2050
XENBUS: Device with no driver: device/vif/0

--------

 You were actually right. It appears the LVm errors were non-critical and the critical
error is the lack of xen device drivers in the kernel or the initrd. I tried with
--with=xenblk.ko, but didn't work. I will try once more and report back.

 Thanks for the solution.

[K T Ligesh]

On Wed, Jan 31, 2007 at 06:54:34AM -0800, master(a)bradleyland.com wrote:
>  I would agree it's broken as I've also been unable to get
> guests to work
>  "out of the box". I've found the problem to be a missing kernel module in
>  the initrd, required for disk access (xenblk.ko). If I build an initrd
>  with xenblk.ko included, guests boot fine.
>  
>  I just make an initrd this command:
>  
>  mkinitrd --with=xenblk.ko /boot/your_image_name.img your_kernelname
>  
>  Just use the kernel name from uname -a
>  
>  mkinitrd --with=xenblk.ko /boot/initrd_test.img 2.6.19-prepcifs_fix 
 Did you get an image from jailtime.org work with the default fedora 2.6.19 kernel and
custom initrd? Then you are my hero. Could you be a bit more specific? Did you use the
fedora default 2.6.19-1.2895.fc6xen kernel?

 Thanks.

[K T Ligesh]

On Wed, Jan 31, 2007 at 06:54:34AM -0800, master(a)bradleyland.com wrote:
>  
>  mkinitrd --with=xenblk.ko /boot/your_image_name.img your_kernelname 
 This is actually not correct, and mkinitrd will fail silently and will not give any
error, leading to lot confusion. The actual command is:

 mkinitrd --with=xenblk /boot/img.name kernel-version

 And actually this works, but I am stuck due to some other error.

 Thanks a lot.

[K T Ligesh]

On Wed, Jan 31, 2007 at 02:01:20PM +0000, Daniel P. Berrange wrote:
>  On Wed, Jan 31, 2007 at 07:28:25PM +0530, Ligesh wrote:
>  
>  Xen filesystem images should be kept in /xen (legacy location) or
>  /var/lib/xen/images (recommended location) otherwise SELinux will
>  deny the VM access to the files & the guest will be unable to
>  mount its filesystem. I suspect this could be what's causing your
>  VM to not find its root filesystem.
>   
 I did a setenforce 0 and tried again but got the same error. Shouldn't that be enough
to disable selinux?

 Thanks.

[Bill Davidsen]

K T Ligesh wrote:
>  On Wed, Jan 31, 2007 at 02:01:20PM +0000, Daniel P. Berrange wrote:
>    
> > On Wed, Jan 31, 2007 at 07:28:25PM +0530, Ligesh wrote:
> >
> > Xen filesystem images should be kept in /xen (legacy location) or
> > /var/lib/xen/images (recommended location) otherwise SELinux will
> > deny the VM access to the files & the guest will be unable to
> > mount its filesystem. I suspect this could be what's causing your
> > VM to not find its root filesystem.
> >
> >     
>
>   I did a setenforce 0 and tried again but got the same error. Shouldn't that be
> enough to disable selinux?
>
>     
And at some point will xen and selinux be compatible? I have everything 
in the "right" place, but it still doesn't work.

-- 
bill davidsen <davidsen(a)tmr.com&gt;
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

[Daniel P. Berrange]

On Wed, Jan 31, 2007 at 01:40:58PM -0500, Bill Davidsen wrote:
>  K T Ligesh wrote:
>  >On Wed, Jan 31, 2007 at 02:01:20PM +0000, Daniel P. Berrange wrote:
>  >  
>  >>On Wed, Jan 31, 2007 at 07:28:25PM +0530, Ligesh wrote:
>  >>
>  >>Xen filesystem images should be kept in /xen (legacy location) or
>  >>/var/lib/xen/images (recommended location) otherwise SELinux will
>  >>deny the VM access to the files & the guest will be unable to
>  >>mount its filesystem. I suspect this could be what's causing your
>  >>VM to not find its root filesystem.
>  >>
>  >>    
>  >
>  > I did a setenforce 0 and tried again but got the same error. Shouldn't 
>  > that be enough to disable selinux?
>  >
>  >  
>  
>  And at some point will xen and selinux be compatible? I have everything 
>  in the "right" place, but it still doesn't work. 
Xen is already SELinux compatible if you have images in /var/lib/xen/images
If it is still not working, then it is most likely not an SELinux problem.
If it was, then you would see AVC denials in the system/audit logs describing
the problem

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[K T Ligesh]

 mkinitrd has a major issue. It doesn't give error if the module we specify in the
--with= doesn't exist. I gave mkintrd --with=gobble.kkk and it accepted it very
happily and proceeded to create a initrd. What kind of initrd does this create? In fact,
the initrd has no error checking whatsoever. The problem is that the xenblk.ko is not
there in the initrd. It should actually be compiled into the kernel, at least the xen
kernel. And I am completely confused why it isn't done so.

 Anyway, is there any place I can get a sane xen kernel for fc6? I checked the xensource,
but they have it only for fc5.

 Thanks.

[Daniel P. Berrange]

On Thu, Feb 01, 2007 at 12:22:28AM +0530, K T Ligesh wrote:
>  
>   mkinitrd has a major issue. It doesn't give error if the module we 
>  specify in the --with= doesn't exist. I gave mkintrd --with=gobble.kkk 
>  and it accepted it very happily and proceeded to create a initrd. 
>  What kind of initrd does this create? In fact, the initrd has no error 
>  checking whatsoever. The problem is that the xenblk.ko is not there 
>  in the initrd. It should actually be compiled into the kernel, at 
>  least the xen kernel. And I am completely confused why it isn't done so. 
The xenblk driver is perfectly capable of living as a kernel module. All
standard FC6 guest installs will have an initrd with xenblk as a module

  # cd /tmp
  # mkdir initrd
  # cd initrd
  # gunzip -c < /boot/initrd-2.6.18-1.2849.1dan2tbxen.img | cpio -idmv
  # find | grep xenblk
  ./lib/xenblk.ko

Dan
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[K T Ligesh]

On Wed, Jan 31, 2007 at 07:01:50PM +0000, Daniel P. Berrange wrote:
>  On Thu, Feb 01, 2007 at 12:22:28AM +0530, K T Ligesh wrote:
>  
>    # cd /tmp
>    # mkdir initrd
>    # cd initrd
>    # gunzip -c < /boot/initrd-2.6.18-1.2849.1dan2tbxen.img | cpio -idmv
>    # find | grep xenblk
>    ./lib/xenblk.ko
>   
 Nah. Its not there.  This is the content of the initrd that comes with fedora. What you
forget is that initrd seems to generated on the fly, because that's the only way it
could have had all those silly lvm commands. So that's the basic issue. Fedora
generates initrd dynamically, and that has no xenblk.ko inside. Let me see if the ones I
have manually created have them.

 -----------------------------

bin
bin/lvm
bin/insmod
bin/modprobe
bin/nash
etc
etc/lvm
etc/lvm/lvm.conf
lib
lib/dm-mod.ko
lib/scsi_mod.ko
lib/sd_mod.ko
lib/dm-snapshot.ko
lib/ehci-hcd.ko
lib/ohci-hcd.ko
lib/dm-mirror.ko
lib/dm-zero.ko
lib/jbd.ko
lib/uhci-hcd.ko
lib/sata_nv.ko
lib/libata.ko
lib/ext3.ko
------------------------------------

[K T Ligesh]

 Ok, I zeroed in on my problem. Even with --with=xenblk.ko, mkinitrd is not adding the
xenblk.ko to the initrd. And since mkinitrd seems to be lacking in any error messages, I
have no clue what the heck is happening there either. The xenblk.ko is present on the host
lib/modules though. I verified that. So anyway, the issue is with mkinitrd and its
inability to add xenblk.ko to the initrd.

 Any suggestions?

 Thanks.

[K T Ligesh]

 Ah, maybe I shouldn't give the .ko?

 So it should be --with=xenblk?

 Thanks.

[K T Ligesh]

On Thu, Feb 01, 2007 at 12:53:55AM +0530, K T Ligesh wrote:
>   Ah, maybe I shouldn't give the .ko?
>  
>   So it should be --with=xenblk?
>  
>   Thanks. 
 Yeah, that was the issue. You have to use xenblk and not xenblk.ko. SO that solved the
first part. I got the xenblk into the initrd.img which I think solves the major issue, but
all is still not well. I am getting this error now.

----------------
 insmod: error inserting '/lib/dm-snapshot.ko': -1 Required key not available
 Loading xenblk.ko module
 ksign: module signed with unknown public key
 - signature keyid: 8bdc589434dbc709 ver=3
 Module signed with unknown public key

=--------------------

Any ideas?

Thanks.

The problem comes about when you update the kernel with yum. In my
experience (like all good lessons, learned the hard way), the initrd is
created on the fly and does not include xenblk. You cannot just take the
initrd that ends up in the /boot directory and use it for your guest.
Doesn't work.

Now I know this, it's an easy matter to create a fresh initrd and include
the xenblk module. Maybe there's a smarter way to do this. If so, it
escapes me.

[Daniel P. Berrange]

On Wed, Jan 31, 2007 at 08:15:23PM -0800, master(a)bradleyland.com wrote:
>  The problem comes about when you update the kernel with yum. In my
>  experience (like all good lessons, learned the hard way), the initrd is
>  created on the fly and does not include xenblk. You cannot just take the
>  initrd that ends up in the /boot directory and use it for your guest.
>  Doesn't work.
>  
>  Now I know this, it's an easy matter to create a fresh initrd and include
>  the xenblk module. Maybe there's a smarter way to do this. If so, it
>  escapes me. 
The smarter way is to keep the kernel & initrd / RPM installed inside the
guest OS itself. So doing yum update in the host doesn't have any risk of
breaking your guests, and doing yum update inside the guest will ensure
that the automatically created initrd is correct wrt to that guest's
virtual hardware setup.

The reason the default initrd for kernel-xen in the host is not working
for the guest is that the initrd generated to be suitable for booting the 
host OS which has real hardware.  If you're keeping initrds for the guest
in the host filesystem, then you're always going to have to manually create
yourself a new initrd whenever kernel-xen in the host is upgraded.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[K T Ligesh]

On Thu, Feb 01, 2007 at 12:37:38PM +0000, Daniel P. Berrange wrote:
>  On Wed, Jan 31, 2007 at 08:15:23PM -0800, master(a)bradleyland.com
> wrote:
>  > The problem comes about when you update the kernel with yum. In my
>  > experience (like all good lessons, learned the hard way), the initrd is
>  > created on the fly and does not include xenblk. You cannot just take the
>  > initrd that ends up in the /boot directory and use it for your guest.
>  > Doesn't work.
>  > 
>  > Now I know this, it's an easy matter to create a fresh initrd and include
>  > the xenblk module. Maybe there's a smarter way to do this. If so, it
>  > escapes me.
>  
>  The smarter way is to keep the kernel & initrd / RPM installed inside the
>  guest OS itself. 
 This is not acceptable, since the guests are basically tar files that are unaware of the
existance of xen. They are pre-created ostemplates from jailtime.org and it is the duty of
the host to provide transparent virtualization. Also just think of the scale. It is always
better to get ONE host working properly rather than to makes sure that 200 guest
ostemplates are all kept in sync.

 thanks.

[K T Ligesh]

On Wed, Jan 31, 2007 at 01:40:58PM -0500, Bill Davidsen wrote:
>  
>  And at some point will xen and selinux be compatible? I have everything 
>  in the "right" place, but it still doesn't work.
>   
 Forget selinux. Just disable it. I mean, you think of security only after the bleeding
stops, your wounds have healed. (The bleeding that comes from banging your head on the
keyboard in frustration). Since this is xen only mailinglist, I think we can talk about
the situation with selinux disabled. 

 Anyway, won't a setenforce 0, completely disable the damn thing? At least it says so
as the output of the command.

 Thanks.

[Bill Davidsen]

K T Ligesh wrote:
>  On Wed, Jan 31, 2007 at 01:40:58PM -0500, Bill Davidsen wrote:
>    
> > And at some point will xen and selinux be compatible? I have everything 
> > in the "right" place, but it still doesn't work.
> >
> >     
>
>   Forget selinux. Just disable it. I mean, you think of security only after the bleeding
> stops, your wounds have healed. (The bleeding that comes from banging your head on the
> keyboard in frustration). Since this is xen only mailinglist, I think we can talk about
> the situation with selinux disabled. 
>     
I bet you have the same eye-level bloody dent in your wall that I do ;-)
>   Anyway, won't a setenforce 0, completely disable the damn thing?
> At least it says so as the output of the command. 
That's true, but I regard "turn off security" in the same light as "run

setuid root so you bypass all that permissions stuff." And at least some 
of the places I could use this require selinux. setenforce doesn't 
disable it, just sets it advisory, which means it still fails and tells 
you there's no such file as <whatever> when there is, just where it 
should be. Daniel keeps telling me it works for him, so it's some 
failure of understanding.

I'll write a detailed post later with exactly my xen experiences, right 
now I have to test and evaluate kvm for someone. I will test with 
selinux if it works without. There isn't a kvm list yet, but I won't 
burden this list with off-topic posts.

-- 
bill davidsen <davidsen(a)tmr.com&gt;
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

[Daniel P. Berrange]

On Wed, Jan 31, 2007 at 03:39:08PM -0500, Bill Davidsen wrote:
>  K T Ligesh wrote:
>  >On Wed, Jan 31, 2007 at 01:40:58PM -0500, Bill Davidsen wrote:
>  >  
>  >>And at some point will xen and selinux be compatible? I have everything 
>  >>in the "right" place, but it still doesn't work.
>  >>
>  >>    
>  >
>  > Forget selinux. Just disable it. I mean, you think of security only after 
>  > the bleeding stops, your wounds have healed. (The bleeding that comes 
>  > from banging your head on the keyboard in frustration). Since this is xen 
>  > only mailinglist, I think we can talk about the situation with selinux 
>  > disabled. 
>  I bet you have the same eye-level bloody dent in your wall that I do ;-)
>  > Anyway, won't a setenforce 0, completely disable the damn thing? At least 
>  > it says so as the output of the command.
>  
>  That's true, but I regard "turn off security" in the same light as
> "run 
>  setuid root so you bypass all that permissions stuff." And at least some 
>  of the places I could use this require selinux. setenforce doesn't 
>  disable it, just sets it advisory, which means it still fails and tells 
>  you there's no such file as <whatever> when there is, just where it 
>  should be. Daniel keeps telling me it works for him, so it's some 
>  failure of understanding. 
If you see 'AVC' denial messages in /var/log/messages or /var/log/audit/audit.log
when creating your Xen guest, do file them in BugZilla against Xen. If it
does turn out to be a SELinux policy problem, we can usually get very fast 
turn around on policy updates, because as you say - being able to run with
SELinux enabled is a very valuable security measure.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[K T Ligesh]

On Wed, Jan 31, 2007 at 03:39:08PM -0500, Bill Davidsen wrote:
>  K T Ligesh wrote:
>  >On Wed, Jan 31, 2007 at 01:40:58PM -0500, Bill Davidsen wrote:
>  >  
>  >>And at some point will xen and selinux be compatible? I have everything 
>  >>in the "right" place, but it still doesn't work.
>  >>
>  >>    
>  
>  That's true, but I regard "turn off security" in the same light as
> "run 
>  setuid root so you bypass all that permissions stuff." And at least some 
>  of the places I could use this require selinux. setenforce doesn't 
>  disable it, just sets it advisory, which means it still fails and tells 
>  you there's no such file as <whatever> when there is, just where it 
>  should be. Daniel keeps telling me it works for him, so it's some 
>  failure of understanding.
>   
 The initrd on fc6 is fucking broken. It doesn't have xenblk or xennet added. The
reason I think is that initrd is created dynamically and the code doesn't have the
--preload=xenblk. This is the actual command you have to run to get a proper initrd.

echo "/dev/sda1               /                       ext3    defaults 1 1" >
myfstab
mkinitrd -f --with=xennet --builtin=aic7xxx --builtin=serverworks --preload=xenblk
--omit-raid-modules --omit-lvm-modules --fstab=myfstab  /boot/xen-initrd.img
2.6.19-1.2895.fc6xen

 (Command courtesy of Jerry from xen-users, slightly modified by me).
 This will fix everything.

 Thanks.