On Mon, May 5, 2008 at 9:29 PM, snowcrash+openfiler <[EMAIL PROTECTED]> wrote: > 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? >
I think I just remember reading the code and then trying to run the commands that interface calls > > > 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. > This is beyond what I have experience with/remember. Is there someone more familiar with how openfiler actually works that can give some pointers/hints? _______________________________________________ Openfiler-users mailing list [email protected] https://lists.openfiler.com/mailman/listinfo/openfiler-users
