I'm now recompiling both xen0 and xenU with devfs not compiled in (I had tried booting xenU with devfs=nomount and it didn't make a difference).
One thing I did just notice is now that the xenU config is fixed for SCSI (make menuconfig would crash if you tried to access SCSI), I can actually go in there and enable or disable scsi in the kernel. I assume that even though xen0 is using the scsi device directly, and that i'm exporting /dev/sda7 to xenU, xenU shouldn't need any scsi block devices at all, is that correct? SCSI was enabled, i'm now trying it with SCSI not selected at all.
> devfs is alive and well in 2.6. there is a udev(?) scheme i think which accomplishes the same sort of thing via a different mechanism, but that is about the extent of my knowledge on it and is probably wrong anyway!!!
> it is the kernel failing to mount /dev/sda7, not userspace. It also fails if I specify root as 0807, so I guess it isn't a devfs issue on dom1. Dom0 also is using devfs, /dev/sda7 is a symlink to /dev/scsi/host0/bus0/target5/lun0/part7, which is in turn of the right major and minor number. Would xen be failing to work out the device numbers because of the symlink?
I've just done a simple test where I created a normal symlink
pointing to a device node and the control tools followed it fine.
I forget how devfs works, but is the major:minor of
/dev/scsi/host0/bus0/target5/lun0/part7 08:07 ? If so, I'd have
thought it would just work...
Could you do an experiment with a non devfs dom1 kernel just to
ascertain that the problem is actually with the tools or backend
driver in dom0 (or vice versa)?