Converting Yocto Live USB Image to VirtualBox VM

Converting Yocto Live USB Image to VirtualBox VM

Rather than boot the Yocto Live USB Image natively, I prefer to use a VM. It's pretty straight forward to convert the current live image file, devkit-live-img-final.binblob.bz2, using VirtualBox's CLI, VBoxManage. Here are the steps I used in Win7:

1. Uncompress using tool of choice--I used WinZip.
2. Convert binblob file to .vdi or .vmdk using the command (change format option to 'VDI' as appropriate): 
     

> vboxmanage convertfromraw --format VMDK devkit-live-img-final.binblob E:devkit.vmdk

3. Create a new VM in VirtualBox and choose the option to create from an existing virtual disk and point to the file you created above.

That's it. I've tried to do the same in VMWare Workstation 10 with the .vmdk and I get a couple fatal boot errors and a hang. I tried exporting from VirtualBox as a .ova and I get the same type of hang.

17 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

Hi Michael,

This worked for me on my macbook pro and the performance is far better compared to booting from USB. 

Thank you.

I have booted up the host OS from Virtualbox successfully. and the target OS on Galileo also boot up successfully.

I got two questions for the host OS:

1. I can't find "ifconfig" command from the OS from the Yocto USB image. Is it missing? How to get it?

2. I have a network cable to connect my Galileo board to my host USB network adapter. From host, I can connect to the Target OS successfull. However from the Virtual box OS on my host, I can't connect to Target OS on Galileo. The default network on Virtual box connected to my wireless network. If I want to make Virtualbox OS to connect to the USB network, how can I make it?

Thank you.

-Yang

 

 

Bild des Benutzers Brendan Le Foll (Intel)
Best Reply

Quote:

yang-wang (Intel) wrote:

I have booted up the host OS from Virtualbox successfully. and the target OS on Galileo also boot up successfully.

I got two questions for the host OS:

1. I can't find "ifconfig" command from the OS from the Yocto USB image. Is it missing? How to get it?

2. I have a network cable to connect my Galileo board to my host USB network adapter. From host, I can connect to the Target OS successfull. However from the Virtual box OS on my host, I can't connect to Target OS on Galileo. The default network on Virtual box connected to my wireless network. If I want to make Virtualbox OS to connect to the USB network, how can I make it?

1. Should be on there. Either way you should use the new `ip` command instead of the deprecated `ifconfig`.But this is debian and so /sbin and /usr/sbin are not in the default user $PATH. Typically it's hiding under /sbin/ifconfig.

2. You can change this in the virtualbox VM settings. Your virtual eth should be bridged onto your chosen network adapter (name). See picture.

 

I used qemu-img on Linux (Ubuntu), then I can run image on VMware Player 6.  For example, 

$ qemu-img convert -f raw -O vmdk devkit-live-img-final.binblob devkit-live-img-final.binblob.vmdk

 

Bild des Benutzers matthias-hahn (Intel)

sorry, put my comment in wrong thread - see

http://software.intel.com/en-us/forums/topic/507539#comment-1783572

 

Hi, I'm a bit new to VMs and had a specific question. Is what you're doing here still running a live Debian session only on an abstract hardware layer? Is it possible to actually install the devkit (meaning the Debian OS + tools) in the vdi? I'm asking this because I'm having a hard time with permanent settings, specifically I can't get my display resolution right (I have a 1920x1080 16:9 display and all I get are 4:3 options) even installing guest-additions and googling around, perhaps because the X server is being configured on the fly at every boot by a daemon? Sorry if it doesn't make sense but if you can't install the devkit natively, at least I would want it in an OS image that I can instal in a VM, tweak and update.

Bild des Benutzers matthias-hahn (Intel)

On the image resolution pls find my answer on http://software.intel.com/en-us/blogs/2014/04/04/some-hints-on-yocto-bui... 

For the tweaking: you can actually modify the LiveImage. Just call

sudo su -
and you can e.g.
apt-get install
any available Debian package (like emacs - pretty much the first thing I did ;-) - but don't want to run into political discussions here although obviously emacs is better than ... :-))

Matthias,

thank you for your kind answers here and elsewhere. I was already operating as root and using apt-get, however my only concern is that apparently we're operating within a Live USB environment in a VM, which is slightly confusing for a VM novice like me. I wonder if all changes are persistent, or perhaps if it was better to offer a pre-configured VM which is not live. I even tried to install the Debian system within the VM using the installer, but it complains about a different kernel version taht should be used at boot, which is not the one you advise to use. By the way, I suspect the 3.10 is compiled with no SMP so it won't recognize more than 1 CPU in Virtualbox (I believe the choice is for extra compatibility...) In any case, if I manage to get the 16:9 non-VESA resolution correct with a working xorg.conf file and Virtualbox extra settings I will post the steps...

 

So I think I figured out the problem with the screen resolution. It has to do with the 3.10.29-devkit kernel, because if I boot with the 3.2 then everything is fine. I suspect that it has to do with the fact that the guest additions modules (which are apparently already installed in the image) are built against the 3.2 kernel. If you try to install the guest additions from within the Virtualbox menu (i.e. an ISO image is mounted as a DVD and a script is run, it complains it can't build properly...). I believe it's because there are no linux 3.10.29-devkit headers available. The same complaint is shown if you install and use the module-assistant pacjkage and run the m-a prepare command. I apologize if this doesn't make sense...I'm a total newbie at VMs...

i am just understand a little in converting image, so not familiar with VMS as well. but currently i am having the same problem, if there is a solution to this, please let me know. thank yo.

Bild des Benutzers matthias-hahn (Intel)

Quote:

fh i. wrote:

i am just understand a little in converting image, so not familiar with VMS as well. but currently i am having the same problem, if there is a solution to this, please let me know. thank yo.

which problem are you referring to?

BTW: "Image conversion" in this context doesn't refer to images in the context of your link (color images ...) but to disk images to start your OS from 

Bild des Benutzers matthias-hahn (Intel)

Quote:

Stefano Romano D. wrote:

So I think I figured out the problem with the screen resolution. It has to do with the 3.10.29-devkit kernel, because if I boot with the 3.2 then everything is fine. I suspect that it has to do with the fact that the guest additions modules (which are apparently already installed in the image) are built against the 3.2 kernel. If you try to install the guest additions from within the Virtualbox menu (i.e. an ISO image is mounted as a DVD and a script is run, it complains it can't build properly...). I believe it's because there are no linux 3.10.29-devkit headers available. The same complaint is shown if you install and use the module-assistant pacjkage and run the m-a prepare command. I apologize if this doesn't make sense...I'm a total newbie at VMs...

Good catch. Didn't look into the details and missed the error message due to missing headers when running VBoxLinuxAdditions.run. I now changed to debian 3.2.0-4-686-pae kernel which has the headers already installed. Resolution and what for me is even more important: Clipboard sharing between Host and VM now works fine.

BTW: I think you asked at some stage on Live Image vs "standard image". Actually, you have a real image. You would just typically use a different boot method when installing on disk. In this case we have a VFAT boot partition with syslinux running as bootloader. If you want to make changes to the bootloader within Debian VBox you'd have to remount /dev/sda1 as rw like

mount -o remount,rw /dev/sda1
The mount point of this partition is "/lib/live/mount/medium/". Any kernel (vmlinuz, initrd ...) you may want to use you'd have to copy over from /boot to /lib/live/mount/medium/live. The boot configuration is in /lib/live/mount/medium/syslinux/live.cfg, and  /lib/live/mount/medium/syslinux/syslinux.cfg resp.

 

 

Matthias,

tons of wisdom from you as usual. Very clear explanation about the boot process and difference between the live image and a "standard" one, the confusing part was that I was using the devkit guest in another Linux host, and as I said I'm not so familiar with VMs.

So why exactly do we have this recommended 3.10.29-devkit kernel in the first place, and why aren't the build tools available? Is it to support more hardware and devices when you live-boot? And if this is the case, why is it compiled without SMP multi-core support (by Intel, nonetheless!) so that you can't have more than one core/thread in the VM, like in the 3.2 current Debian-Wheezy 686 version, when virtually all systems are multi-core today? That simply doesn't make sense when we're operating a whole extra OS just to develop and compile. Why is it even branded as Long Term Support (that should be what LTS stands for...), when there is no trace of Intel repositories in the image, at least that I can find. I'm confused.

WARNING LONG POST AHEAD:

To be honest, if I had to make a suggestion to Intel in boosting this platform, I would advise on making things as simple and straightforward as possible for makers who don't have the skills (or don't want to become) Linux system administrators.

The Intel Galileo may become the ultimate educational platform to learn the basics and climb up in three essential areas of computing:

1) Input / Output (a domain that is very well covered by microcontrollers) and it has good support through emulation and external interfaces (although not perfect, especially for the routing on GPIOs);

2) Programming - practically everything is available on the platform at runtime (including Java VM) and of course compilers too, also given the X86 architecture;

3) Networking and System Administration - with a full Linux distribution you can't really ask for more, also given the expansion cards on pci-e. My only suggestion here is that Intel comes up with a drop-in Wireless expansion pack with a Wi-Fi / BLE combo that includes antennas and physical mounting, specifically for the Galileo, at a low price;

The best part is that everything is command-line and SSH, so you really get to learn the way you should, brick after brick.

The problem lies with the software, however, and the fault, IMHO originates in the (misisng?) current strategic focus on the platform. Intel wants to push its Quark line and it's fine. And yet, you can't target the Makers' community and embedded engineers with the same products and tools at the same time.

What happened in the beginning was that, probably due to time constraints, Intel came up with the Yocto recipe-based solution (perhaps due to the fact that there was already Atom support available). That path was unsustainable for makers, who weren't just required to become Linux experts, but even to compile their own distribution (and kernel) in a frankly exotic way, having to learn the whole bitbake/recipe process. That's fine for experts managing an embedded platform, but not for someone just tinkering with his homebrew projects. The Arduino IDE was almost unusable, in that compatibility with with pure Arduino reference and libraries was broken all over the place and you had to be in exception management all the time.

Now you guys come up with this 4GB+ devkit which is once again unnecessarily complex. The way you did it to me doesn't make sense at all. A USB image is a terrible choice IMHO, and a complete oxymoron for a developer toolchain (try out vs. use permanently and reliably...). If you want to make it cross-platform, it makes absolutely no sense to deliver a USB live image instead of a VM (even Microsoft gets it right when they provide their OSs for free for web testing). True that you provide instructions to convert it to a VM, but still... And you even have a multi-kernel boot option which I personally don't understand (why would you want to have multiple kernels, with broken "build-essentials" in the repositories, instead of a well maintained version that works in a VM, when you already have so many problems in getting the whole VM environment working properly). In the devkit, moreover, you go for the most complex (and possibly powerful) tool, Eclipse, which has a steep learning curve for the ordinary maker, while at the same time the professional embedded engineer has his - probably commercial - toolchain nicely custom installed and supported on his system, along with tons of dedicated and possibly proprietary software to debug, monitor and evolve his design.

Now the real challenge, dear Intel, is to go back to basics. You have to come up with a real-life focus group and a realistic user scenario, to deliver a user-friendly, usable and possibly groundbreaking software product. That's how the Arduino team did it with limited resources and less ambition, and it's not that hard. But it has to be simplified, and it's not difficult because all the backend free and open software is in place. All you have to do is come up with a simplified front-end that glues everything together nicely. If you want to make it cross-platform, Java is a much lighter option rather than something native on a full VM, also because you don't need fancy high level graphics/toolkits that might break it. Think an Intel-branded Arduino-style IDE with a simple editor which supports multiple languages (essentially C/C++, Python, Javascript and Java, possibly adding an Arduino-compatible layer for Processing) with GPIOs and ADC control, standard compiler support, a well thought-out and simple debugger (even visual, which could be an innovation for makers coming from the Arduino world, who like me, debug with Serial.println) and perhaps even an integrated and possibly curated forum/community/KB (could be an innovative interface, along with simplified man-style support). All this has to run smoothly on an inexpensive netbook-style machine running on batteries - not an I7 laptop - which is what you tipically carry at fablabs. Intel has to understand that, in the maker space, often less is more.

Unless, I suspect, you're waiting for Microsoft to come up with their Windows on Devices software platform. May not be by chance that the Galileo is showcased on their preview website. In that case, a Linux user like me shouldn't invest on this platform and simply go away.

And just to end my rant, your next hardware design, too, could be done differently, but this is another issue altogether. If you decide to go virtual like you did with the Galileo, then you might as well come up with a cool virtual separate MCU as well (which could enable better real-time too), instead of relying on problematic userspace sketch emulation. I'm sure the Quark can handle that easily, with well thought out extra circuitry (think ADC and GPIO). At this specific stage, I would argue that an Arduino Yun is a better tool for 99% of the makers' user cases, and as a learning platform, and the Galileo/Quark might be literally blown away by the Arduino Tre/ARM, which, like the Yun, is based on a simple serial bridge between the main CPU and a separate microcontroller. On top of that, from what I hear, its development tools will be web based and self-hosted, which, if done properly, is quite a giant leap forward. If necessary and possible, bring back to life an old MCU design, perhaps re-energized. Make the serial protocal available everywhere (on the pins, in the air with Bluetooth, with a dedicated USB dongle that ships in the kits).

I apologize for this very long post, which might not make sense in many ways because I'm just a hobbyst and a novice, but I just felt I could contribute my points to the community and to the headquarters at Intel.

Bild des Benutzers Bob Duffy (Intel)

Stefano you ROCK!  That is one thoughtful, and yes long forum comment.  Anyway, thanks for posting and know your information has gone back to a lot of folks inside the Intel walls. 

Intel is working on a number of solutions to support both the hobbyist and professional embedded developers.  Meanwhile keep the quality work and ideas coming

WARNING: ANOTHER BORING AND OFF-TOPIC POST IN THE WRONG PLACE

Bob,

I hope you don't take my criticism as Intel hate, it's exactly the opposite. I had very high hopes this fall, when Intel (through its CEO in person outing as a maker himself!) generously handed out thousands of Galileos at the European Maker Faire in my home city Rome. Six months later, yesterday I was helping out at the Arduino booth at this major developer event again here in Rome, and I hear people telling me their Galileos are locked away in their cupboards, while they're drooling for the upcoming Arduino Tre or any next big thing in devboards. This situation is hurting Intel's reputation. This plan into the makers space (and in IoT prototyping in general) isn't being executed properly. I suspect the problem ultimately lies in the fact that Intel is a great company, but is dominated by Genius Engineering Geeks*, who usually talk to other GEGs at their OEM customers. Makers are instead faulty and emotional human beings with a soft soul and heart. Intel, understandably, doesn't know how to make end-products for ordinary people, since it never has. Intel doesn't realize that, right before the "M" as in "Makers", there is an "L" as in "Learners". I know this for a fact because, right after the Rome Maker Faire, as a sign of gratitude for the Galileo generosity, I wrote to a few important guys at Intel I had met, with a great suggestion about a product, and never even got a reply. Please don't think I'm arrogant, because I can prove you why it was so good: it would cost zero to design and give away, it could be done in a week on a fun corporate team-building camp, it was a remake of something very successful that had been made way back then by America's greatest IT powerhouse ever and finally it was made of bits (as in information) and pieces of...cardboard!

http://en.wikipedia.org/wiki/CARDboard_Illustrative_Aid_to_Computation

Now is the time to change your mindset and pick up this giant historic opportunity to make your corporate name mean INTE-lligentL-earning, by helping your indirect customers evolve out of this current TwitBook passive zombie hysteria, and free themselves into full IT-awareness and citizenship.

Two issues really puzzle and frustrate me about Intel's path in this maker/accessible IoT embedded domain. The first one is that IMHO you've got the foundations wrong, and I'm afraid that building on top of these will only worsen the situation. I'm surprised that Intel isn't walking its talk on all that it has been preaching in this and other segments for all these years, and hasn't looked back at its great legacy and even at its mistakes. On top of that, I have a feeling you're not being creative, but rather intellectually lazy (like in the GHz-race times), at the exact time of another major IT revolution. You're not using what you have (i.e. the Quark chip) as a tool, but you're just copy/pasting it around: smells a lot like what Microsoft did with mobile. Two final words of advice. First, don't assign strategic guidance of this project to someone who has a PhD in kernel performance analysis in quantum computing and uses X64 native machine code to keep track of his family bills. Hand it to one of your (few, if any?) employees who can barely parse an array, schedule a couple of blinking LEDs and say "Hello World!" on a serial port, but is passionate about wasting his childhood on a ZX81 (Timex Sinclair 1000 in the US) or a VIC20. Also, think philosophically. When writing software, be inspired by the beauty of calligraphy, novels and art books. Hardware-wise, relate to charming or yummy natural wonders like roses and artichokes. Call your next board "Da Vinci" rather than "Einstein". If in doubt when designing electronic wizardry, let yourself be guided by these three "G"s: be technologically graceful, gentle and generous.

* I have used the word "Nerd" instead of "Geek" which is what I meant before editing this comment, when showing my envy for Intel wizards. Now I realize it could be felt as derogatory. I consider myself a nerd who unfortunately has never achieved geek status...(otherwise I would have applied for a job at Intel)

Hi Michael,

I'm quite a newbie in development under Linux, but I think Galileo could be a good starting point.

I created a VM under VirtualBox as indicated, and it started correctly, but when I try to launch Eclipse IDE, it immediatly close after the initial mask appears. Running the the Live USB image, the starts correctly and I can build and debug.

What's could be wrong with my Virtual Machine?

Thanks

Paolo

Melden Sie sich an, um einen Kommentar zu hinterlassen.