Age | Commit message (Collapse) | Author |
|
|
|
We completely treat all 32bit arm as armhf now. Booting the rpi kernel
installed by debvm-create for armel will not work at all. The only sane
way to boot armel is to enable a multiarch kernel.
Refine the VMARCH guess from /bin/true using the file output for the
kernel image for the common cases of i386+amd64 and armel/armhf+arm64.
|
|
|
|
While this works for armel+armhf by sheer luck, debvm-run fails for
i386+amd64 as it selects qemu-system-i386.
|
|
|
|
Timeouts were hit on salsa-ci for arm64 occasionally. The armhf
autopkgtest also runs into this timeout.
|
|
|
|
|
|
|
|
This was never tried, but autopkgtests indicate that smp limits also
apply to the native case.
|
|
|
|
|
|
|
|
|
|
It's not as simple as disabling the rng when pci is unavailable. For
m68k, we can select -machine virt and then we can have a
virtio-rng-device. Thus make that part configurable.
|
|
While the host version only works on kvm, max means the same and also
works on tcg.
Signed-off-by: Johannes Schauer Marin Rodrigues <josch@debian.org>
Signed-off-by: Helmut Grohne <helmut@subdivi.de>
|
|
Fixes: aee1eb3d1c28 ("debvm-run: no need for true randomness -- use /dev/urandom to be faster")
|
|
marvell seems deprecated. Suggested by Jochen Sprickerhof.
|
|
|
|
Now that we pass accel=kvm:tcg, there is no difference anymore.
|
|
-enable-kvm is equivalent to -M accel=kvm, but we allow a fallback to
tcg in case kvm is not available thus shifting this test into qemu.
Reported-by: Bastian Blank <waldi@debian.org>
Reported-by: Johannes Schauer Marin Rodrigues <josch@debian.org>
|
|
This is a workaround for https://bugs.debian.org/1029309
|
|
Fixes: bfaa3d124fab ("debvm-run: on arm64 there is no default machine -- set one")
|
|
* ppc64el needs seabios for vgabios-stdvga.bin
* We need ipxe-qemu for -device virtio-net-pci,netdev=net0
|
|
When running on armhf natively, there also is no default machine, so we
should also pass -machine virt there. That likely affects all arms and
riscv64 as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
systemd-binfmt implements what we need here and that's what most users
will have, so only recommend binfmt-support when systemd is missing.
Reported-by: Jochen Sprickerhof <git@jochen.sprickerhof.de>
|
|
We really are using 1.3.0 features already.
|
|
|
|
|
|
Thus, don't do Debian releases that would be separate from upstream
releases.
|
|
Faq
See merge request helmutg/debvm!26
|
|
|
|
|
|
Reported-by: Jochen Sprickerhof <git@jochen.sprickerhof.de>
|
|
debvm-create: install only one kernel image
See merge request helmutg/debvm!27
|
|
On Debian, the linux images depend on linux-initramfs-tool, so this
isn't actually a change here. On Ubuntu, this dependency is missing, so
we actually add it. Unfortunately, initramfs-tools fails to install as
it cannot determine the root filesystem type.
Reported-by: Jochen Sprickerhof <git@jochen.sprickerhof.de>
|
|
The apt pattern ?or does not short-circuit. It installs any pattern
matching one of the arguments. On amd64, we thus get both the cloud and
the non-cloud variant.
There aren't that many good options to fix this, so the next best way is
using a hook and running apt again, which is suboptimal in terms of
repeated triggers, but likely the best we can do at present.
|
|
Cleanup
See merge request helmutg/debvm!25
|
|
|
|
|
|
Give an example of how to use it with ports and add a few
architecture-specific cases. Note that m68k and sparc64 do not actually
work, because they lack PCI.
|
|
When apt encounters a package that does not exist, but is referenced via
Recommends, Suggests, Breaks or otherwise, it errors out with a missing
installation candidate. This happens for linux-image-generic on buster.
To avoid this situation, we specifically ask apt to not consider virtual
packages whenever we use ?exact-name.
|
|
|
|
|