This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] almost working

I am once again able to boot a xenU kernel after removing all traces of devfs. *yay*
can't say for sure if it was devfs though as i did a bk pull just before I sent my last email...
having booted my new domain, 'xm list' in dom0 hung for ages with 100% cpu time until I hit ctrl-C. trying it again worked fine though.
halting the new domain from the console causes it to disappear from 'xm list' correctly, but it won't restart properly, and then 'xm destroy, won't remove it from 'xm list'.
lastly, is there a plan to be able to export a filesystem rather than just block devices, like 'hostfs' under uml? It would make copying modules over a bit easier!
keep up the good work!

From: James Harper
Sent: Fri 2/07/2004 12:58 PM
To: Ian Pratt
Cc: Keir Fraser; xen-devel@xxxxxxxxxxxxxxxxxxxxx; Ian.Pratt@xxxxxxxxxxxx
Subject: RE: [Xen-devel] can't mount root... devfs???

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.

From: Ian Pratt
Sent: Thu 1/07/2004 9:14 AM
To: James Harper
Cc: Keir Fraser; xen-devel@xxxxxxxxxxxxxxxxxxxxx; Ian.Pratt@xxxxxxxxxxxx
Subject: Re: [Xen-devel] can't mount root... devfs???

> 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)?