Defaulting to the native chroot isn't necessarily intuitive. Let's
require this be specified in full.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
With the new chroot type, we can now write fancy paths in the pythonic
way. Convert most of the codebase over, as well as adding various other
type hints.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
We use a custom verbose log level in pmbootstrap, unfortunately it isn't
possible to correctly type this due to some limitations in the logging
library [1], [2].
Given that our usecase is fairly simple, we can just wrap the module
with our own so we only have to tell mypy to ignore the error once
instead of at every callsite.
[1]: https://github.com/cryptax/droidlysis/issues/15
[2]: https://github.com/python/typing/discussions/980
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
According to the type hints for os.cpu_count(), it might return None...
To be safe, add a warning and a fallback in this case (though it seems
incredibly unlikely this would ever be hit)
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Introduce a new module: pmb.core to contain explicitly typed pmbootstrap
API. The first component being Suffix and SuffixType. This explicitly
defines what suffixes are possible, future changes should aim to further
constrain this API (e.g. by validating against available device
codenames or architectures for buildroot suffixes).
Additionally, migrate the entire codebase over to using pathlib.Path.
This is a relatively new part of the Python standard library that uses a
more object oriented model for path handling. It also uses strong type
hinting and has other features that make it much cleaner and easier to
work with than pure f-strings. The Chroot class overloads the "/"
operator the same way the Path object does, allowing one to write paths
relative to a given chroot as:
builddir = chroot / "home/pmos/build"
The Chroot class also has a string representation ("native", or
"rootfs_valve-jupiter"), and a .path property for directly accessing the
absolute path (as a Path object).
The general idea here is to encapsulate common patterns into type hinted
code, and gradually reduce the amount of assumptions made around the
codebase so that future changes are easier to implement.
As the chroot suffixes are now part of the Chroot class, we also
implement validation for them, this encodes the rules on suffix naming
and will cause a runtime exception if a suffix doesn't follow the rules.
Recent changes to qemu and Alpine packaging now require using the
virtio-vga-gl device and installing -gl packages to get virglrenderer
support.
Without this, wlroots fails to get an EGL context (among other problems
you'd expect by not having a useful GPU around...)
Reviewed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Tested-by: Oliver Smith <ollieparanoid@postmarketos.org>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20221210185021.3546-1-clayton@craftyguy.net%3E
On qemu-system-riscv64 the -nic option doesn't seem to work correctly.
qemu-system-riscv64: warning: requested NIC (anonymous, model virtio-net-pci) was not created (not supported by this machine?)
Using -netdev and -device provides the same functionality and also works
on riscv64.
Reviewed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20221029114536.100268-1-luca@z3ntu.xyz%3E
This makes QEMU trap signals like Ctrl-C and send it to the guest
instead of terminating QEMU.
To quit QEMU with this option you can use [Ctrl-A] [x]
or
[Ctrl-A] [c] and type 'quit' at the prompt.
This behavior is disabled by default, and can be enabled by setting a
new option in the pmbootstrap.cfg (using "pmbootstrap config
qemu_redir_stdio true")
Co-authored-by: Luca Weiss <luca@z3ntu.xyz>
It's been 3 months since we switched to new mkinitfs
and we are still fixing consequences.
linux-lts and linux-virt used by qemu-amd64 device package
install vmlinuz-lts (vmlinuz-virt). And qemu run cmdline
passed -kernel vmlinuz which makes it impossible to run
qemu without this change.
With this change proper kernel arg is passed to qemu.
Co-Authored-By: Oliver Smith <ollieparanoid@postmarketos.org>
Signed-off-by: Alexey Min <alexeymin@postmarketos.org>
Replace "args.arch_native" with the direct function call in order to
avoid passing "args" to all functions. This is a step to get rid of this
args-passed-to-all-functions pattern in pmbootstrap.
kernel is named /boot/vmlinuz now, looking at the filename will no
longer tell us what flavor it is. This now will look at
/usr/share/kernel, which has always contained the kernel 'flavor', and
since we currently only install 1 kernel these days, guarding this with
pmaports.cfg should be unnecessary. In the worst case (if there are
multiple kernel 'flavors' installed), it'll just grab the first one and
return it.
Qemu has been upgraded to 6.0.0 in Alpine edge. This version doesn't
only warn about -show-cursor, it refuses to start up with the option
set.
Fixes: issue 1995
Fix error when CPU count is more than 8 while emulating a non-native
platform:
qemu-system-aarch64: Number of SMP CPUs requested (12) exceeds max CPUs supported by machine 'mach-virt' (8)
Signed-off-by: Mark Hargreaves <clashclanacc2602@gmail.coM>
Replace "rootfs" with generic image, because the function will be used
for a second storage too. Refer to IMAGE_SIZE, as it is shown in the
help output.
Don't try to install the recently split up packages if the pmaports
branch is based on Alpine 3.12.
Fixes: 61845c93 ("pmb.run.qemu.install_depends: add new depends (MR 2007)")
For KVM the code is run pretty much natively on the host CPU, so all
CPU extensions available on the host CPU can be also used inside the VM.
To expose that information to the VM we should pass "-cpu host", so the
VM is aware of which CPU is in use.
For CPU emulation, QEMU uses a rather minimal CPU on x86_64 by default.
It does not have support for SSE3/4 etc, which may be required for some
applications to work properly (e.g. Android in Anbox). Add a --cpu flag
to make the emulated CPU configurable. Useful values are for example
--cpu max to emulate all implemented CPU features.
To test QEMU's CPU emulation it is useful to have a switch to disable
KVM, even when it is available (and potentially working fine).
Add --no-kvm for that purpose.
For some reason, the SDL display backend changes the video resolution
to 1024x768, while the GTK display keeps it at 640x480.
This is annoying, because at the moment we can only set one display
resolution for a device in postmarketOS (e.g. for the splash screen).
At the moment, the resolution for the splash screen is set to 640x480,
which therefore shows up too small with the default SDL display.
It seems like the display resolution can be only changed in the guest
directly. Linux has a video= kernel parameter that can be used to
implement this. (See: https://www.kernel.org/doc/html/latest/fb/modedb.html)
Let's set 1024x768 by default, but make it configurable through --video.
The QEMU 'tablet' input device reports absolute positions instead
of relative mouse pointer movements. This can be used to automatically
grab/release the mouse pointer when entering/leaving the QEMU window,
instead of having to release it with CTRL + ALT + G manually.
This is quite convenient and should be the default option normally,
but at least on my PC the mouse pointer is reported with some vertical
offset for some reason (you can't reach the top and it extends below
the QEMU window...). Let's add it as an optional --tablet option for now.
To ensure consistent behavior for QEMU on all architectures,
it is helpful to try to use the same hardware elements where possible.
A few examples of current inconsistent behavior:
- x86_64 uses a SCSI disk, while aarch64 uses virtio-blk
- x86_64 uses e1000 network, while aarch64 uses virtio-net-device
- x86_64 uses PS/2 mouse, while aarch64 uses usb-mouse
- only x86_64 prints serial output to console
At least the virtio components are usually independent of the selected
architecture, so we can use them for both architectures.
This commit makes most of the hardware configuration shared:
- Redirect serial output to stdio
- virtio-blk for the disk image
- virtio-gpu-pci (this was already implicit for both architectures)
- virtio-net-pci for the network interface
- virtio-mouse-pci/virtio-keyboard-pci as input devices
- intel-hda for audio
We also set -nodefaults to avoid setting up unneeded devices
especially for x86_64.
Now that we try to use the IP assigned by QEMU via DHCP,
the debug-shell is no longer working via telnet.
This is because the VM does not have any IP assigned when it is running.
We would need to start a DHCP client from the initfs to make it work.
busybox provides both udhcpc (client) and udhcpd (server) so this is
not a big problem. But the question is: Is it worth it?
The debug-shell will be only used for debugging, and NetworkManager
handles starting a proper DHCP client once the rootfs is mounted.
Meanwhile the debug-shell can be also accessed via serial output/input,
(available in the pmbootstrap stdout/stdin). So overall it does not
seem worth the effort. Let's just recommend using serial instead.
The current network setup has weird side effects.
Normally, QEMU would automatically make the guest set up necessary
IP routes through its integrated DHCP server.
When running QEMU through pmbootstrap they are missing.
First, we change the DHCP range in a way that could potentially
conflict with default IPs used for QEMU's own services:
QEMU has the default gateway at <network>.2, and DNS at <network>.3.
We set the DHCP range to start at <network>.1, and will therefore
potentially give out one of these addresses (QEMU's default starts at
<network>.15).
See: https://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29
In practice this does not cause immediate problems because there is
just one guest in the network, and it will get <network>.1, which is
not used by QEMU.
More problematic is that we start a DHCP server from postmarketOS
at the same time (normally used for the USB network) and there are
actually two DHCP servers running at the same time.
QEMU's user networking is local to the process, therefore it is not
possible to access the QEMU guest through its IP from the host.
That's why we have the port forwardings so you can access SSH at
localhost:2222 for example.
In practice the network interface in the QEMU guest is only used to
access the Internet. For that, we don't care which IP address we get,
we just want to get a working setup (IP + routes + DNS) automatically
through DHCP.
To make this work nicely we just need to stop trying to fit QEMU's
network setup into our usual setup for USB networking. When we remove
the custom DHCP option, and avoid starting a DHCP server from postmarketOS
(deviceinfo_disable_dhcpd) everything is suddenly working fine. :)
device-qemu-vexpress appears to be completely broken at the moment.
I was not able to make it show anything, get a log or even just get
any indication that it is actually doing something.
In general, it does also not fit well to the other QEMU ports.
The vexpress machine type in QEMU seems to be quite limited,
e.g. it has no PCIe bus and therefore it is impossible to configure it
with virtio-gpu. (Unlike already configured for x86_64 and aarch64).
I had some success with a setup similar to aarch64 with -M virt,highmem=off
but was unable to make it work in the end:
- Alpine's virt kernel was missing some options preventing boot completely
- Alpine's lts kernel was missing PCI support for virtio-gpu
- Even after adding the options the VM usually freezed after boot
Overall it does not quite seem worth the effort at the moment,
compared to how well x86_64 and aarch64 are working.
In any case, vexpress is too different (and broken) to continue maintaining it.
When using pmbootstrap, you usually select the device you want to work
on using 'pmbootstrap init', generate the rootfs and can then run more
commands in the context of the device.
The same needs to be done before using QEMU (to generate the rootfs).
But for some reason 'pmbootstrap qemu' requires setting the --arch
parameter when running QEMU for a foreign architecture, even when the
device is still selected in pmbootstrap.
Even more confusing is that setting "--arch arm" always selects
device-qemu-vexpress, but this is not immediately clear from the name.
Let's make this a lot more intuitive by making sure there is a QEMU
device selected when running 'pmbootstrap qemu'. We can then use the
device information to infer the architecture automatically.
At the moment, the --display argument is a bit complicated to use.
A common use would be to switch between the UIs (sdl, gtk, none)
or to enable the software rasterizer. Split the two use cases
to separate arguments to make it more intuitive.
So far we tried to configure virtio-gpu using "-vga virtio" only
when the target architecture matches the host architecture.
But that's actually not what it depends on.
virtio-gpu and virgl can be also used when emulating a foreign
architecture. In fact, we already force usage of virtio-gpu for
aarch64 through "-device virtio-gpu-pci".
However, the "-vga virtio" parameter does not exist on aarch64,
no matter if we run QEMU natively on aarch64 or emulate it on x86_64.
(Apparently, -vga is mainly about legacy VGA framebuffer stuff that
we don't necessarily need. This is quite visible since the display
stays uninitialized on aarch64 until the kernel driver loads,
whereas on x86_64 it is initialized by the BIOS...)
In other words, "-vga virtio" belongs to the parameters specific to x86_64.
Now that we have removed the setup question for the Mesa driver to use
(since it was ineffective), it would still be nice to have some way to
choose if you want to use virtio-gpu/virgl or not.
But actually virtio-gpu can be also used with swrast, without virgl.
This happens automatically when QEMU is started without GL support.
We already have a --display parameter for this, so it is possible to
force swrast by using "--display sdl" (instead of the default sdl,gl=on).
Overall this allows simplifying the QEMU package setup because there is
only a single GPU driver in use (virtio-gpu) instead of the 3 we had before
(virtio, qxl, bochs).
mesa-dri-swrast and mesa-dri-virtio are both provided by mesa-dri-gallium
now, so this option does not have much use anymore. With both selections,
exactly the same packages are installed.
The SPICE UI option tends to be broken (see #1836), and even when it is
working, it is not working particularly well. QXL requires special handling
in our QEMU packages, when now virtio-gpu (virgl) is working quite well overall.
Apparently it is possible to use virgl with SPICE; but only when using
a Unix socket instead of a TCP port. That again is a bit complicated
because we run QEMU outside the chroot and the SPICE client within.
Overall it does no longer seem to be worth the effort.
The default QEMU UI is working just fine (for the purposes of testing
postmarketOS at least).
