Message 1 / 9 (didn't know forum would require breaking messages up - sorry!)

Hi everyone!

First of all, just to clarify - crazy: [✔✔] double-check!

The goal

My goal/motivation is simple enough: I'd like to sandbox GVM so it will run within other environments. Like, say, a chroot on Android, or in qemu-system-arm on x86. GVM beta 6 is the most recent (2010!!) official runtime 4.x+5.x OS release out there, and this is likely to remain forever the case. With this being the case, it strikes me as a little odd that it seems nobody's tried to see if the platform can be made a little more portable than was maybe intended.

As for "why?!" (or maybe "why now?") - I got a head-cold a few days ago, and needed a temporary/throwaway distraction to focus on. Haha, "temporary"... I'm over the cold now, but dug into this project a bit deeper than I anticipated I would, and now I'm itching to see it working.

GVM itself appears to run just fine on vanilla armel Debian, once I manually copy a few libraries in. It's gvmlauncher - the shell/springboard/installer system (!!!) - that's the mess. It does actually launch (outside of Hildon (!) - albeit with a mess of windows on the screen...) and then successfully connect to GVM, but it crashes as soon as I try and click anything that would open a file picker. This is where I'm stuck.

On the one hand, it's definitely worth considering to see if gvmlauncher can be thrown away and an alternative shell UI and launcher put together. The gvm<->gvmlauncher IPC mechanism looks simple enough for this to seem viable, but I only say this because I haven't been able to actually test everything that gvmlauncher does in situ as I don't have an N8x0/N900 device (and, if I'm brutally honest with myself, am probably not going to get too much use out of one either generally or for this specific task, as my end+only goal here is sandboxing).

On the other hand, looking at the nuanced side of things, reimplementing a new gvmlauncher feels vaguely reminiscent of of that one time a bunch of crazy hackers took the Windows 2000 and Windows NT source code leaks and compiled a working NTOSKRNL out of the pieces. Near unbelievably cool, but... eeeh. I'm certainly not reverse-engineering anything to that extent here, but still... I can't help but wonder if it would be better to, instead of touching any GVM-specific components, get just enough of Hildon running on top of vanilla armel linux that the result coincidentally happens to run GVM perfectly inside qemu-system-arm and on Android. This really seems like the best approach anyway because GVM itself will always need an X server.

TL;DR: I'm missing / looking for specific instructions on how to run the Hildon environment on armel Linux in Xephyr.


After 4-5 days of trying things that have all (!!) ended in failure, I am posting here and asking for help. I'll probably lurk in this thread in a bit and weigh in in a little while once I've had some time to deflate and catch up on other things, and can spend some time properly following up on people's suggestions.


The following is very long and is mostly about failure. It will be boring unless you are an engineering type good at scanning through thorough bug reports quickly.


What I've tried

Running GVM inside qemu-system-arm: works, with caveats noted above

Two days of searching finally found garnet-vm-1.0.6b-itos2009-armel.deb under a rock at http://dl.mobilestan.net/download.ph...JH8kXmZ2v&v=11. (Most of the going around in circles was not knowing what filename to look for. My thanks to the person who submitted the totally random and very google-friendly bug report at https://bugzilla.redhat.com/show_bug...iple&id=620326 )

.deb was manually extracted (ar x + tar xvf). gvmlauncher successfully gets application list if gvm is in /usr/bin/gvm/ (yes, the subdir gvm).

Environment used was constructed by converting Squeeze image at https://people.debian.org/~aurel32/qemu/armel/ to ext4 (by copying its contents into a new ext4-formatted qcow2 disk image (via qemu-nbd), then mounting the old disk image and cp -arv-ing everything over), copying the /lib/modules/ dir from the filesystem at https://people.debian.org/~aurel32/qemu/armhf/ into the newly created ext4 filesystem, and then then using the armhf kernel from Wheezy. This was needed because the Squeeze armel kernel was built for the versatilepb target, which emulates an ARMv6-series CPU, while the Wheezy armhf kernel was built for vexpress-a8, which emulates an ARMv7 CPU - important because the gvm binary was compiled for ARMv7. See also: https://reverseengineering.stackexch...r-and-quitting

apt-get inside Squeeze is old enough that it does not have any facilities (!) to disable GPG package signature verification, and package signatures on archive.debian.org expired a very long time ago. This caused a good day or two of complete disorientation. Thanks to whoever it was on #debian that suggested fakedate and was the inspiration behind:No apt configuration changes required at all. Technically it preserves your security, too - provided the correct signatures are exclusively out of date

(Insert standard disclaimers here about security being your responsibility...)

Anyway, yeah. This gets me running GVM... but not in an especially useful form.