I was reading this wiki article and I noticed that it’s outdated and needs updating. I am using Qemu but it’s possible the other documentation needs updating too. In particular I noticed:
The machine type in the example is -machine virt, but the linked images are for SiFive HiFive Unmatched & Unleashed, so AFAIK this should be -machine sifive_u
The file name is not the same as the images, it currently starts with “focal”. This one is a fairly minor one to fix though as the filename will change as new versions are published.
When I try to boot the image after fixing the above problems, Qemu gives me the error of No 'virtio-bus' bus found for device 'virtio-net-device', so I guess there is something missing, maybe the requirements for -machine sifive_u are different from the requirements of -machine virt and simply swapping out the name isn’t enough.
Also, if I try to boot these images on -machine virt (which I don’t expect to work), this happens:
Retrieving file: /lib/firmware/5.11.0-1007-generic/device-tree/qemu-riscv.dtb
Failed to load '/lib/firmware/5.11.0-1007-generic/device-tree/qemu-riscv.dtb'
Skipping l0r for failure retrieving fdt
SCRIPT FAILED: continuing...
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk virtio-blk#8...
** Unrecognized filesystem type **
** Unrecognized filesystem type **
Found 6 disks
** Invalid partition 21 **
Cannot read EFI system partition
BootOrder not defined
EFI boot manager: Cannot load any image
Update: It seems that -machine virt is indeed correct. I got it to work, but the documentation still needs updating beyond this, because with my current configuration if I update the kernel then the OS stops booting. I also added ,hostfwd=tcp::2222-:22 to the network configuration so that I can SSH into my VM as the serial port is quite bad and only allows one session, so I would highly recommend placing this in the documentation too. The config I have that works with the exact kernel version the 20.04 image ships with is this:
Install the dependencies: sudo apt install qemu-system-misc opensbi u-boot-qemu qemu-utils
Optionally rename the image to something simpler.
Extract the image from step 0: xz -dk ubuntu.img.xz
Increase the size of the image qemu-img resize -f raw ubuntu.img +20G
Be aware, this can technically be changed later but it’s really annoying to do, I recommend setting the size now to whatever size you think you’ll need, I ended up running out of space and spent over an hour fiddling with fdisk and such.
Make a Bash script with this command (or just run it) to boot the VM:
Let it boot, this may take several minutes. Then log in.
Do not run sudo apt upgrade as changing the kernel or bootloader can brick the VM (in my experience).
By default it uses the serial port, but this is quite bad. Run sudo apt install openssh-server, open a terminal on your host, and run ssh -p 2222 ubuntu@localhost to SSH into your VM for a much better experience.
Install whatever you want as long as you don’t run upgrade. Like sudo apt install cmake gcc clang build-essential
With just the new u-boot-qemu_2021.10+dfsg-1_all.deb from Debian on my Ubuntu system (gladly it has no dependencies) the new images work again. I didn’t need any of the other above suggested changes.
So we either need to consider reverting whatever it is in the images or update u-boot-qemu throughout the releases - what do you think?
Ubuntu’s u-boot-qemu_2021.07+dfsg-0ubuntu8_all.deb also works fine. This situation is described in https://wiki.ubuntu.com/RISC-V: “Hirsute’s version of u-boot-qemu is required at the moment to boot hirsute images.” Just replace Hirsute by Jammy in the sentence.
I was just trying this and ran into the very same issue, so just to be clear, even though I’m running 20.04.4 and have downloaded a 20.04.4 (Unmatched RISC-V) image, I still need to upgrade u-boot-qemu to what seems to be a minimum of u-boot-qemu_2021.07+dfsg-0ubuntu8_all.deb, correct?
I am having slow IO issue to run the image on qemu.
dd if=/dev/zero of=zero.dat bs=512 count=204800
always tell me only 2MB/s speed, of to /run/zero.dat which is to RAM, also the same result.
Which I was unable to do apt upgrade, and it hang at update-initramfs, very slow.
