Month: June 2020

Creating an ARM64 Debian Image

As part of another project, I need to be able to build software for the PinePhone, and that means I need an ARM64 environment with as much oomph as possible (trying to compile stuff on the PinePhone = bad idea).

The solution is to run a Debian VM that, in turn, runs a Qemu ARM64 emulator with a Debian image.

Nearly every step that follows is taken verbatim from this guide by Blahcat, so all credit goes there.  The only reason I made my own post is because I had to change a couple lines in order to get the network working. Hopefully this brings you joy.

Get that VM going

I’m a VirtualBox guy, but you do you. You’ll also want the latest Debian ISO, which at the time of writing is Buster. I gave mine 4 cores, 4GB of RAM, and 20GB of storage.

Install Qemu

Terminal. sudo apt install qemu. Nuff said.

Download the Debian Bits

You need the initrd and kernel of the Debian installer. Blahcat’s links are outdated, so here’s the latest:


Make a disk. To hold stuff.

Blahcat recommends 20G, but that’s the size of my Debian VM. I haven’t managed to fill up 12G yet — but, as said before, you do you.

qemu-img create -f qcow2 disk.qcow2 12G

Invoke the Installer

This is where I depart the most from Blahcat. Every time I followed their instructions, the resulting image was unable to connect to the internet, even though it ran a blasted net installer. The solution, in my case, was to force the emulation of an ethernet adapter (in addition to the one that Qemu automatically creates). Some of the command that follows is likely malformed, redundant, or both, but by golly it worked.

qemu-system-aarch64 -smp 2 -M virt -cpu cortex-a57 -m 1G \
    -initrd initrd.gz \
    -kernel linux -append "root=/dev/ram console=ttyAMA0" \
    -global virtio-blk-device.scsi=off \
    -device virtio-scsi-device,id=scsi \
    -drive file=disk.qcow2,id=rootimg,cache=unsafe,if=none \
    -device scsi-hd,drive=rootimg \
    -device e1000,netdev=net0 \
    -net nic \
    -netdev user,hostfwd=tcp:,id=net0 \

During installation you’ll be asked to pick an Ethernet adapter; pick the Intel one and life is good.

Extract your fancy new kernel

Let it be known that I have no idea how half this stuff works, nor what nbd stands for. Essentially, you mount your new image, extract the kernel and initrd, and use them the next time you invoke the image.

sudo apt install nbd-client
sudo modprobe nbd max_part=8
sudo qemu-nbd --connect=/dev/nbd0 disk.qcow2
mkdir mnt
sudo mount /dev/nbd0p1 mnt
cp mnt/initrd.img-4.19.0-9-arm64 mnt/vmlinuz-4.19.0-9-arm64 .
sudo umount /dev/nbd0p1
sudo nbd-client -d /dev/nbd0


You should now be able to run your new, emulated system – and have internet access too!

qemu-system-aarch64 -smp 2 -M virt -cpu cortex-a57 -m 1G \
    -initrd initrd.img-4.19.0-9-arm64 \
    -kernel vmlinuz-4.19.0-9-arm64 \
    -append "root=/dev/sda2 console=ttyAMA0" \
    -global virtio-blk-device.scsi=off \
    -device virtio-scsi-device,id=scsi \
    -drive file=disk.qcow2,id=rootimg,cache=unsafe,if=none \
    -device scsi-hd,drive=rootimg \
    -device e1000,netdev=net0 \
    -net nic \
    -netdev user,hostfwd=tcp:,id=net0 \

Posted by Adam Labay, 0 comments

Extending onto a USB Monitor with Manjaro

Normally, my ASUS MB169B USB Monitor lives in my briefcase, to be used when I need two screens at a coffee shop or a client. But, given the new work-from-home reality, it’s found a new life as a dedicated spot for tiles showing email, calendar, and Slack…

…at least it does when I’m running Windows. When running Manjaro, the USB monitor has sat idle, unused, and sad.

That’s not to say that Manjaro doesn’t support the use of DisplayLink to attach USB monitors — it’s just that, like all things Arch Linux, you have to work for it; doubly so if you’re running an nVidia card.

So, here’s how I got mine working.

1. Install DisplayLink and EVDI drivers.

Do you need both? Beats me, but this is what I have and it works. Purists will do this via pacman but I’m lazy and used the GUI.

2. Install the nVidia drivers, even though they’re not very good.

This turned out to be the key step. Normally, I use modesetting as my graphics driver, mainly because it doesn’t suck. With the nVidia drivers, I get some annoying mouse flickering that I haven’t yet been able to address.

However, the USB monitor also uses modesetting, and with both on the same driver, xrandr returns the following when you try to link them up:

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  139 (RANDR)
  Minor opcode of failed request:  21 (RRSetCrtcConfig)
  Value in failed request:  0x0
  Serial number of failed request:  22
  Current serial number in output stream:  22

What does it mean? No idea.

How do we fix it? Bust out those crap-ass proprietary drivers.

Enter Manjaro Settings Manger, choose Hardware Configuration, and attain the following setup (the video-linux drivers may be optional, but they’re doing no harm so whatev):

3. Enable and configure the DisplayLink service

Per the instructions in the Arch Wiki, enable DisplayLink by typing in the terminal
sudo systemctl enable displaylink.service

Then, create a file at
with the contents

Section "OutputClass"
	Identifier "DisplayLink"
	MatchDriver "evdi"
	Driver "modesetting"
	Option  "AccelMethod" "none"

Note: It’s entirely possible that this step is obviated by use of the nVidia drivers, but I’m not taking chances.

4. Reboot

Just to make sure.

5. List the displays in xrandr

In the terminal, enter
xrandr --listproviders

With luck, you should see both displays, with their respective drivers:

Providers: number : 2
Provider 0: id: 0x1b8 cap: 0x1, Source Output crtcs: 4 outputs: 7 associated providers: 1 name:NVIDIA-0
Provider 1: id: 0x238 cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 1 name:modesetting

6. Connect the displays in xrandr

In the terminal, enter
xrandr --setprovideroutputsource 1 0

If you’re lucky, this will mirror your displays. Of course, that’s probably not what you want, so let’s get them extended.

7. Configure Manjaro to extend your displays

Open Display Settings and declare your primary monitor as such (I’ve found that the USB monitor tends to be marked as primary, initially).

Uncheck Mirror Displays for obvious reasons.

Choose a resolution for your USB monitor that makes sense (probably not the same as your big-ass desktop monitor).

8. Have a lovely beverage

Celebrate your success. Or let me know if it failed. I probably can’t help, but hey who knows.

Posted by Adam Labay, 2 comments

(Nearly) Successful Voice Calls on PinePhone with UBPorts

Update (3 July): Calls now work 100% of the time.

So, this tweet turned out to be a teensy bit premature:

I can get the PinePhone to ring other phones – which is still a new accomplishment – but no voice comes through. Alas.

But, since this remains a new development, here’s how it came about:

1. Flash the latest available Pinephone System Image

Go to and download the latest image. (NB: this is a new URL. Any builds from the old site won’t work since they lack the code to self-update.)

Use BalenaEtcher (or dd if you’re grizzled) to flash the image to your SD card.

2. Switch to the Dev channel

This is where it gets new. Gone are the days of flashing each day’s image and losing your stuff. Now, UBPorts can auto-update (w00t).

Navigate to Settings | Updates | Update Settings (the last being cleverly hidden at the bottom of the screen) and change your channel to Development.

Give the phone some time to think, and it should load the latest Ubuntu image (at the time of writing, the latest is version 54).

Nota Bene: These version numbers are not updated daily, and as such have no correspondence to the build numbers on the CI page.

3. Reboot and Update

Once the update has been downloaded you will need to reboot so that it can load. When you reboot, make sure that you’re still on the dev channel since sometimes it reverts.

4. Place a call (prayer never hurt)

If you’re like me, you’ll now have a 1:5 (up from 0:5) chance of being able to successfully dial out.

(The title to this post said “nearly” for a reason.)

5. Stay Tuned

At this rate an actual, working voice call can’t be far off, right?

Posted by Adam Labay, 0 comments