Need help running Librem 5 Qemu images

I would like to run Librem 5 PureOS on my laptop for experiments and development. I would like to have one VM with Byzantium and another with Crimson.

  1. I downloaded the latest Byzantium build from
    Image Build [Image Builds] [Jenkins]
  2. I unpacked devkit.img.xz to devkit.img .
  3. I compared the SHA256 checksums from the website and the local file and both were identical
  4. I installed the KVM/Qemu packages.
  5. I made a connection to a user session inside VirtManager.
  6. I created a VM with a virtual optical drive with the extracted image and gave it boot priority.
  7. I created a qcow2 image as local storage.
  8. I started the VM.

Unfortunately it doesn’t really boot. It tells me it tries to boot from the optical drive but failed, because it could not read from CDROM (code 0005). No bootable disk. No bootable device.

Did I construct the VM incorrect? Is the downloaded image supposed to be used for one-time-boot and installation or is it already an installed storage and I must be used as such in the VM? Which I tried and it did not boot either.

And my laptop as the host is x86-64 but the real Librem 5 is arm64 or aarm or whatever. Will the VM work as ARM from the inside so that I can build software in there without bending my host system to do so, or does the VM work as x86 from inside.

Thanks in advance.

6 Likes

You will need the aarch64/ARM64 supporting libraries and packages for Qemu. Make sure they are installed.

3 Likes

I installed the packages

  • qemu-efi-aarch64
  • qemu-efi-arm
  • qemu-system-arm

Now I can choose a architecture when constructing VMs. arm does not seem work. With aarch64 (which I think is the actual architecture of the Librem 5’s CPU) works a little bit better.

For Machine Type the default is virt and I don’t recognize that any other option from the list fits better.

Now I see it tries to boot. I can get into the BIOS but it still does not find something to boot from.

failed to load Boot0001 "UEFI QEMU QEMU CD-ROM" ... Not Found
failed to load Boot0002 "UEFI Misc Device" ... Not Found 

I disabled secure boot, but still no success.

2 Likes

Yes, aarch64 is the name of the CPU architecture for the Librem 5. Also called arm64 which I think is just another name for the same thing.

It’s a great idea to run those Librem 5 Qemu images, it could be extremely useful for testing, I would like to do that too. I don’t have any solutions for your problems at the moment though.

4 Likes

When I construct the VM the first thing I am asked for is how I would like to install the OS. I think I must select Import existing disk image instead of Local install media. When I do this the VM seems to boot. I see one physical CPU core busy. Still I don’t see any UI. Hence I don’t know what’s going on. Is there something going on like an installation? Is it idle? Virtual VM says CPU usage is at 50%. I gave the VM two cores.

And the other thing is that the image may still be x86. At least it looks like when reading this:
https://developer.puri.sm/Librem5/Development_Environment/Boards/qemu.html

As I said I would like to end up with a system where I can build for aarch64 but one things I want to do is investigating an issue where a program behaves differently on my common x86_64 Linux with XFCE on my laptop than on the Librem 5 with aarch64 and Phosh. So I an x86 Librem 5 image could be useful to exclude that the problem is the CPU architecture.

1 Like

The build site is a bit confusing. If you look on the left panel, there are lots of different builds. For example one could click and examine this build:

Image Builds » Image Build #19582 [Jenkins] [which have qemu-x86_64.img.xz and qemu-x86_64.qcow2 ]

What you should note is that appears to include a qemu qcow image of a build for x86_64 architecture (that you can run natively [kvm] run with qemu on your x86_64 desktop). That is what your URL references and should be easy to boot up using qemu on your x86 system. If I were you, that’s what I would do (x86_64 image on x86_64).

On the other hand, you appear to have downloaded the devkit build. But there are other builds, including one for “librem5r4.img.xz”.

https://arm01.puri.sm/job/Images/job/Image%20Build/19583/

If you look at the “build information” it says: plain librem5r4 byzantium image (current)

That appears to be built for arm64. And if you need more information, after you click on that URL … you can look at the console text by selecting “View as Plain Text” to see the console output of the build:

https://arm01.puri.sm/job/Images/job/Image%20Build/19583/consoleText

That’s informative … because you’ll see that it’s got the right architecture and correct device tree (search on dtb).

Booting arch64 images with qemu , I think, requires some extra steps. Here is some very spare information about these things: QEMU - Ubuntu Server documentation

4 Likes

Good info.

2 Likes

Yes what Jenkins shows seems to be different kinds of builds mixed. The build number in the lists does not tell what is build and to which target. I think that should be displayed more prominently. Some builds can be found by filtering.

So I managed to get a x86 VM running now by taking the qcow2 file and build the VM from that.

On the ARM builds there is no qcow2 file. There are .img files, but they doesn’t seem to work with QEMU without further steps. Are that ISO filesystem images?

2 Likes

2 Likes

In regard to ISO filesystem images … those are usually for “Live Install” CD images (that one would specify to qemu with the -cdrom parameter) and I don’t think Purism is producing those for the Librem5.

In regard to the .img files. Did you read the other link I sent? I believe you would need to use the associated efi.img files. Check on the documentation for the Debian package qemu-efi-aarch64 . Here’s a different link with similarly spare documentation. https://cdn.kernel.org/pub/linux/kernel/people/will/docs/qemu/qemu-arm64-howto.html

2 Likes

Yeah, sry. I was multitasking and my brain can’t comprehend. ^^ Still all in one list.

1 Like

Thx, I will have a look at it. Also interesting:
https://www.qemu.org/docs/master/system/target-arm.html

2 Likes

Yes. And I haven’t dug into it much. I only looked at it when I was trying to run a raspberry pi image. It’s why it might be easier to stick with the provided x86 qcow. It would certainly be faster since it uses kvm and is not a chipset emulation. That said, the x86 qcow would not provide you with an aarch64 environment for building. Aside: Of course one can cross-compile for aarch64, so you don’t need a aarch64 architecture to make aarch64 builds.

I’m not speaking from experience, it’s simply from reading docs I read about 5 years ago. In any case, here is what I would try:

  1. One might try to use -machine virt [I think this is the generic machine.].

  2. The image contains a dtb (device tree file) … and, so, it might work when combined with the “-machine virt” parameter and possibly with a “-dtb” parameter pointing to the dtb file extracted from the image.

  3. The above probably won’t work. But someone here ( Devicetree in QEMU — Das U-Boot unknown version documentation ) documents an example with dtb files. That’s what I would play with. Someone like dos could certainly tell you more if he has dealt with qemu on aarch64. I encourage you to read more before calling on dos for help.

  4. Also, the NXP iMX8MP plus is a different board (for qemu purposes the main difference would be a different GPU), but you could look into what they do NXP i.MX 8M Plus Evaluation Kit (imx8mp-evk) — QEMU documentation

4 Likes