Pmbootstrap: Launch a VM with qemu from pmbootstrap

[ollieparanoid]

@mmaret and @MartijnBraam worked on creating a Qemu device. It is somewhat working now (check out the cool screenshots).

As suggested by multiple people, it would be cool if we integrated that into pmbootstrap. Here is my suggestion:

pmbootstrap qemu [-h] [--arch ARCH] [--add PACKAGES] [--with-fde]

• When the command gets started, basically everything gets set up and the Qemu window pops up, booting pmOS
• Do install with no fde by default (so there is one less password to type in, maybe we should also pre-fill the user password for this case)
• Create/update the image before running with new packages (#95) (which makes this a dependency!)
• Use the qemu-system-x86_64 etc. binaries provided by the host Linux distribution (we could also use the ones from Alpine, but then we'd need to take care of passing through the X/Wayland session, which would be kind of ugly).
• --arch would either be x86_64 or armhf and default for the native architecture of the host Linux distribution. We'd have a mapping for x86_64 -> device-qemu-amd64 etc.

What does everyone think about this proposal?

[MartijnBraam]

Sounds good. I think the part about supplying a default password can be fixed by having a --password argument for install by which you can supply a plaintext password or a hash ready to be put in /etc/passwd or maybe supply your password hash inside the pmbootstrap config.

I've also had a quick look and we can probably add device-qemu-aarch64

[PabloCastellano]

I've started implementing this awesome feature.

However what I'd expect from the pmbootstrap qemu command is to start a qemu VM with pmOS as quick as possible. It means that I don't want it to install packages or generate a new system image if not strictly necessary.

This is what I would do:

• If the system image is not generated, then pmb qemu would ask you to do it (as flasher flash_system already does).
• If the image already exists, then just run qemu (you have previously added the packages you want to it and chosen if you didn't want fde).

What do you think about it?

[PabloCastellano]

It works fine for armhf (qemu runs). For x86_64 instead, device-qemu-amd64 needs the following variables which are undefined: deviceinfo_dtb and deviceinfo_kernel_cmdline.

[MartijnBraam]

-dtb doesn't apply to x86 platforms, you can just leave it from the qemu commandline.

[PabloCastellano]

Oops, thanks! Both cases run fine, however:

• armhf: It looks stuck at the loading splash screen (should weston show up?)
• x86_64: Cannot find the boot partition

[MartijnBraam]

both should boot to weston

My x86_64 command:

qemu-system-x86_64 \                         
    -kernel vmlinuz-postmarketos \
    -initrd initramfs-postmarketos \
    -m 1024 \
    -append "console=ttyS0 PMOS_NO_OUTPUT_REDIRECT" \
    -drive file=disk.img,format=raw -serial stdio

My armhf command:

qemu-system-arm \
    -kernel vmlinuz-postmarketos \
    -initrd initramfs-postmarketos \
    -M vexpress-a9 \
    -m 1024 \
    -sd qemu-vexpress.img \
    -append "console=ttyAMA0,38400n8 console=tty1 PMOS_NO_OUTPUT_REDIRECT" \
    -dtb vexpress-v2p-ca9.dtb

[ollieparanoid]

@PabloCastellano: Cool, that you're working on this o/

Yeah, the solution you have proposed is a lot simpler -- as I understand it, it would only have: pmbootstrap qemu without any arguments, right? (So the user must choose the right device beforehand in init and generate the system image, as you've said it). Sounds good to me!

[PabloCastellano]

Okay, I have a new version that I want you to test. I have rebased it from master to clean up my commits and because https://github.com/postmarketOS/pmbootstrap/pull/307 was needed.

The only things that don't work at the moment are

• the mouse pointer is not grabbed when you emulate arm
• i386 emulation (do we want to support it or should I remove it?)

How to test

First build the image you want to test (it's recommended to use --no-fde)

# choose qemu-vexpress for arm and qemu-amd64 for x86
pmbootstrap init
pmbootstrap install

Then run qemu

# Runs qemu in your host architecture
pmbootstrap qemu

# Runs qemu in a different architecture
pmbootstrap qemu --arch arm
pmbootstrap qemu --arch aarch64

Note that the image that is launched depends on the --arch parameter, not the configured one in init.

[MartijnBraam]

The amd64 default kernel command line is missing console=tty1 so you can enter the password on the tty while booting

[PabloCastellano]

Some really appreciated feedback from @PureTryOut and @MartijnBraam on Matrix:

• [x] cmdline for qemu-amd64 should be console=tty1 console=ttyS0 PMOS_NO_OUTPUT_REDIRECT
• [x] no network support - the e1000 drivers should to be enabled
• [x] add kvm support (it is possible to check if kvm is supported if /dev/kvm exists)
• [ ] run qemu inside chroot
• [x] add a /etc/network/interfaces file

[MartijnBraam]

running qemu inside the chroot will be difficult since it's a graphical application. running it outside will be fine for now I think since it's only one command away

[ollieparanoid]

I suggest removing i386 support. This would be additional maintenance for a use case, that no one currently has (and is unlikely to have in the future).

[PabloCastellano]

Since the functionality is already implemented and there have not been any more comments in the last days, I have submitted PR https://github.com/postmarketOS/pmbootstrap/pull/350 to fix this issue

[drebrez]

Last week I did some tests with the qemu.

Everything compiled fine out of the box but it didn't started correctly because in the generated image there wasn't any more free space. I created this PR #336 to solve that issue.
After solving the image size, everything booted up correctly.

Then I asked myself how to connect with ssh to the virtual machine and I solved it using some qemu port redirection.
This is the code I added in the generation of the qemu command:

command += ["-redir", "tcp:2222::22"]

And after that I was able to connect using ssh -p 2222 user@localhost

Is there a different way to handle the ssh connection to the vm?

[MartijnBraam]

It's either using the -redir or adding tap or tun networking to the qemu commandline, that will give the VM an address on your host network without a firewall. The downside is that you need to setup tap or tun networking on your host machine and enable IP forwarding.

[drebrez]

My suggestion is to add a default configuration to the pmbootstrap qemu command or add a parameter to let the user decide.
Maybe even simply add custom additional parameters that they get concatenated to the qemu command.

[ollieparanoid]

@MartijnBraam if we do it the tap/tun way, as a user I would like to have it set up fully automatically with pmbootstrap and teared down with pmbootstrap shutdown. But that is some more work, so I'd recommend doing that in a new PR.

In the meantime I would add -redir.

[PabloCastellano]

Okay, I've implemented the -redir argument (and pmbootstrap qemu -p PORT) and tested PR https://github.com/postmarketOS/pmbootstrap/pull/336 (good catches @drebrez!).

I also like the custom additional parameters but I'd leave it for another PR.

[PabloCastellano]

Fixed in PR https://github.com/postmarketOS/pmbootstrap/pull/350