Starting a riscv64 VM from an ArchLinux x86_64 host
by Andrej Podzimek
Hi Fedora developers!
I'm trying to start a Fedora riscv64 VM on an ArchLinux x86_64 host based on this wiki page: https://fedoraproject.org/wiki/Architectures/RISC-V/Installing I have a reasonably recent qemu and virt-manager:
```
qemu 6.0.0-3
qemu-arch-extra 6.0.0-3
libvirt 1:7.3.0-1
virt-manager 3.2.0-1
```
All virt-builder steps work perfectly fine and produce an image.
However, I cannot start an instance. I tried the image prepared with virt-builder, the manually downloaded image, the nightly image, direct kernel loading (configured in libvirt / virt-manager), but none of that worked.
For the nightly instances in particular, the wiki says one should extract "firmware" from /opensbi/... in the image. However, there is _no_ such directory in the image (and also no file called .elf). This information may be outdated.
When using the downloaded .elf file (as described in the "Download using virt-builder" section), I get this from qemu:
```
qemu-system-riscv64: Some ROM regions are overlapping
These ROM regions might have been loaded by direct user request or by default.
They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory.
Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses.
The following two regions overlap (in the memory address space):
/usr/bin/../share/qemu/opensbi-riscv64-generic-fw_dynamic.bin (addresses 0x0000000080000000 - 0x0000000080012558)
VirtualMachineMedia/Fedora-Developer-Rawhide-20200108.n.0-fw_payload-uboot-qemu-virt-smode.elf ELF program header segment 0 (addresses 0x0000000080000000 - 0x000000008000d0e0)
```
The qemu command line was:
```
qemu-system-riscv64 \
-nographic \
-machine virt \
-smp 8 \
-m 32G \
-kernel VirtualMachineMedia/Fedora-Developer-Rawhide-20200108.n.0-fw_payload-uboot-qemu-virt-smode.elf \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-device virtio-blk-device,drive=hd0\
-drive file=VirtualMachineMedia/Fedora-Developer-Rawhide-20210421.n.0-sda.raw,format=raw,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,hostfwd=tcp::10000-:22
```
Idea No. 1: Drop the "-kernel ..." argument. In that case I get an OpenSBI splash that looks like this: https://pastebin.com/5QKJqkRg Sadly, the VM is frozen and nothing else happens. There is no network communication either.
It looks like this^^^ configuration might start something, but fails to load a kernel properly (or the like). The nightly image appears to contain multiple bootloaders, but the wiki doesn't say how to run them.
Idea No. 2: Delete /usr/share/qemu/opensbi-riscv64-generic-fw_dynamic.bin to see if the conflict goes away. (For the record, the file is owned by qemu-arch-extra.) Well, qemu then says 'qemu-system-riscv64: Unable to load the RISC-V firmware "opensbi-riscv64-generic-fw_dynamic.bin"'.
Idea No. 3: Extract the kernel (vmlinuz-5.10.6-200.0.riscv64.fc33.riscv64) and initramdisk (initramfs-5.10.6-200.0.riscv64.fc33.riscv64.img) from the nightly image and load them "directly" (using virt-manager) like this: https://pastebin.com/36RVR75r
This^^^ failed the same way as all virt-manager experiments (with nightly / manually downloaded / built with virt-builder) images: A black console with a blinking cursor and nothing happens. No activity on the virtual bridge either.
Interestingly, each time qemu starts and freezes, host CPU utilization is about 200% (i.e., 2 cores worth of load, not 1 core, not 8 cores etc.). (The host machine is a Ryzen 3950X with 32 CPUs altogether and 128 GB RAM.)
What am I doing wrong (apart from not using Fedora as a host)?
Why am I getting a weird conflict with a system built-in OpenSBI? Could the built-in firmware be incompatible with the Fedora image?
Are there any up-to-date instructions on how to get the recent nightly images (without the /opensbi directory) working?
How can I debug why qemu / OpenSBI freezes? Does OpenSBI need a bit of configuration to boot the image?
I'll retry this on a Fedora VM if need be, but would also like to understand what the issue is on Arch. Also, I wanted to double-check that the riscv64 port actually works on current systems...
Just about any hint would help a lot. :-)
Cheers!
Andrej
2 years, 9 months
List of long term FTBFS packages to be retired in August
by Miro Hrončok
Dear maintainers.
Based on the current fail to build from source policy, the following packages
will be retired from Fedora 35 approximately one week before branching (August
2021).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fai...
The packages in rawhide were not successfully built at least since Fedora 32.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ft...
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
=============================================================================
cardpeek kalev Fedora 32
percona-xtrabackup slaanesh, slankes Fedora 32
proxyfuzz psklenar Fedora 32
sugar-view-slides callkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31
zram pbrobinson Fedora 32
The following packages require above mentioned packages:
Depending on: percona-xtrabackup (1), status change: 2020-11-22 (32 weeks ago)
holland (maintained by: immanetize, jeffreyness, survient)
holland-xtrabackup-1.2.4-2.fc35.noarch requires /usr/bin/xtrabackup
Affected (co)maintainers
callkalpa: sugar-view-slides
chimosky: sugar-view-slides
immanetize: percona-xtrabackup
jeffreyness: percona-xtrabackup
kalev: cardpeek
pbrobinson: sugar-view-slides, zram
psklenar: proxyfuzz
slaanesh: percona-xtrabackup
slankes: percona-xtrabackup
survient: percona-xtrabackup
tuxbrewr: sugar-view-slides
2 years, 9 months
Re: [Fedocal] Reminder meeting : Prioritized bugs and issues
by Ben Cotton
On Tue, Jun 29, 2021 at 7:00 AM <bcotton(a)redhat.com> wrote:
>
> You are kindly invited to the meeting:
> Prioritized bugs and issues on 2021-06-30 from 11:00:00 to 12:00:00 America/Indiana/Indianapolis
> At fedora-meeting-1(a)libera.chat
>
There are no nominated bugs and the two open bugs are being actively
nudged by yours truly. I'll cancel this meeting and we'll meet again
on 14 July.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 9 months
Soname bumps and a review swap
by Jerry James
Next week, I plan to build the following in Rawhide:
- antic 0.2.4
- e-antic 1.0.1 (soname bump)
- eclib 20210625 (soname bump)
- flint 2.7.1 (soname bump)
- normaliz 3.9.0
The following packages will be rebuilt due to the changes above:
- arb
- polymake
- pynac
- sagemath
- Singular
The eclib update may not be possible. I am still determining whether
the current sagemath release can handle that update. If not, eclib
will just be rebuilt for the flint soname bump, but remain at its
current version (20190909).
The new version of normaliz has a new dependency, hash-library:
https://bugzilla.redhat.com/show_bug.cgi?id=1979713
Would anyone like to swap reviews?
--
Jerry James
http://www.jamezone.org/
2 years, 9 months
How to (better) deal with library major API changes
by Richard Shaw
I'm still trying to figure out the best way to frame the problem and I
don't have a specific solution in mind, but there's got to be a better
solution for dealing with projects that make major API changes.
Pre-side-tag this was even more difficult:
1. Make sure the new version builds
2. Maybe do some testing with dependencies
3. Update the package and break Rawhide
4. Deal with the fallout
At least with side tags it buys us some time to port over packages that
don't build cleanly, but the longer these are open, the more likely other
people have touched them creating other issues.
I've actually started creating COPRs for this purpose and that helps check
things out "offline" from the main distro, but it's not a 100% solution.
What do we do with packages where SOME but not all of the dependent
packages support the new API?
Conservative option: Wait until they do and don't upgrade the package.
This is fine in the short term (3-6 months?) but many upstreams are less
than aggressive about updating dependencies and could potentially take a
year or more.
Middle of the road (but a lot of work) option:
1. Create a compat or SOVERSION appended package (requires new review)
2. Migrate the packages that won't build to it, build the new package and
working deps.
One big caveat is that in some cases it's all or nothing for the whole
"stack"
Contrived example:
OpenImageIO can build with OpenColorIO 2.0 but blender can't (has since
been fixed).
I can't rebuild OIIO with OCIO 2.0 and leave Blender at OCIO 1.X. Worse,
while it's a good thing I know about this dep chain, I'm unaware of any
systematic method to detect this so it completely relies on packager
knowledge, and we know how problematic that is with all the soname
breakages even though the guidelines are quite explicit there.
Aggressive option: Build it anyway and deal with the fallout the best we
can.
I don't actually think this is practical but included it for completeness.
Other recent examples:
OpenEXR 3 (ongoing saga)
vtk 9.0 (pretty much done, but was painful)
Thoughts?
Thanks,
Richard
2 years, 9 months
