hi, > It still sounds familiar, maybe it was tap:aio vs. file:? > Although that doesn't seem like your problem since > you are using phy:
fwiw, i can reproduce this problem whether or not i load the boot volume (i.e., OpenFiler) as tap:aio from the rPath Xen .img, or from the phy: i create by dd'ing the .img to a LV. > Maybe the problem was fixed in a newer version of openfiler? afaict, the OF2.3beta is n/a as a Xen img -- just as an installable img and as a VMWare instance. i've tried to figure out enought abot 'conary' to upgrade from 2.2 -> 2.3 place, but, after blindly flailing about for awhile, that fails miserably :-/ > As I recall, there is a way to trace through manually with openfiler > manually with commands, can you perhaps point to any community-available docs? > maybe there are also log files on the openfiler server? in the logs, the only relevant stuff i can see is, May 3 21:36:46 openfiler kernel: EXT3 FS on xvda1, internal journal May 3 21:41:57 openfiler kernel: xvda: xvda1 May 3 21:41:57 openfiler kernel: xvdb: unknown partition table that doesn't look good :-/ re: partition table, that second drive, xvdb -- created as mentioned in my OP -- *can* be mounted in other DomU's, with no 'complaints' so, for some reason, OF is not 'happy' with the partition table. i note that OF believes that xvda1 & xvfb are of type "msdos" and "loop", respectively -- which strikes me as odd. _______________________________________________ Openfiler-users mailing list [email protected] https://lists.openfiler.com/mailman/listinfo/openfiler-users
