Hi,
The following contains a good bit of guesswork and assumptions, so
please correct me if I'm wrong anywhere.
There's also some bits which may seem obvious, but I don't know what you
would find obvious and not - and besides, sometimes it's easy to miss
things that are obvious in hindsight, so I figured it best to include as
much as I could think of, even if you've already tried it.
On 11/08/2012 04:50 PM, Giacomo 'giotti' Mariani wrote:
Hello Radeck, everyone,
I successfully built QtMoko in chroot on a Squeeze VirtualBox machine
with target PC :-)
If I understand you correctly, your setup has three major parts:
(A) the host PC (actual physical PC), running some form of Linux
(B) a VirtualBox virtual computer, running Debian Squeeze
(C) a chroot used to build QtMoko
with (C) being inside of (B), (B) running on (A), and (B) being intended
solely for the purpose of building/running QtMoko, and nothing else.
(Btw, that's pretty much exactly how I would do it myself - I haven't,
yet, but probably will (even if only to try to scratch a few itches), so
I'm glad someone's working out the kinks. ;) )
Fairly complex setup, actually, so lots of places things can go wrong.
...but now I can't run it: what do you mean by
* Now switch to first console (CTRL+ALT+F1) and run it:
I'm assuming that your (B) is a minimal installation, not running any
graphical environment (aka X11 or X.org), just giving you a CLI console.
If so, the above bit should be ignored, as it would typically make your
host PC (A) switch to its console.
However, if you *are* running a GUI in the virtual box, I think the
easiest thing to do would be to turn it off and disable it, so it
doesn't get in the way.
(I don't actually think this is where you have problems, though.)
If I do it under chroot I get:
qtmoko-chroot:/opt$ qpe
QScreenLinuxFb::connect: No such file or directory
Error opening framebuffer device /dev/fb0
LinuxFb: driver cannot connect
Aborted
> Indeed, I miss /dev/fb0. Where can i get it?
Hm. No framebuffer device...
My first thought would be to check if /dev is actually bind mounted
properly, so that the out-of-chroot udev in (B) would take care of
generating /dev/fb0 for both (B) and (C).
I see that the script used to enter the chroot tries to take care of
that though, so it probably is (but it wouldn't hurt to check).
One way to check would be to see if /dev/fb0 exists on (B) even though
it doesn't in (C).
Assuming that's not the problem, my next thought is to check the
configuration of VirtualBox, checking that it is actually set up to
include a graphics card that Linux can run a graphical framebuffer on.
If it is, I think the next thing to do is to check the dmesg of (B) (if
the output of "dmesg" is too short, it can probably be found in
/var/log/messages prefixed with "kernel:"), looking for anything to do
with framebuffers, to see if that tells you why (B) doesn't have one.
If that doesn't give any clues either, well... then things are a bit
more complex. Maybe the right driver wasn't enabled when (B)'s kernel
was compiled, or something. Either way, probably harder to figure out
than we'd like. :/ So I hope something in the above helps.
The same happens if I do it outside chroot (connecting with ssh -Y):
Just a tiny note: the -Y is probably not necessary, as it just deals
with forwarding X11 connections - which are not in use here. It
shouldn't hurt, either, though - and should certainly not cause the
problem you're seeing.
Regards,
-Frode
_______________________________________________
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
