So with next release, boot configs need to be located on a 3rd FAT partition. Partition 1 and 2 are used for the two parts of U-Boot. I don’t get why so many manufacturers use such complicated multi-partitioning layout:
Usually U-Boot can be just read outside of any partitions on defined offsets, which minimises the risk that those are accidentally overwritten.
U-Boot supports Linux filesystems just fine (use load instead of fatload), no need to hardcode FAT usage and break clean DEB kernel packages. dpkg is not able to replace files on FAT partitions, so package upgrades and reinstalls are doomed to fail with this.
The VisionFive 2 has an SPI flash with bootloader, so it does not need any U-Boot on the OS images at all. I guess this is to align with images of VisionFive 1, but then again, why using partitions for U-Boot at all?
Looks like for clean Debian images, we need to create forks or hope for soon mainline/upstream U-Boot support .
I mentioned earlier a certain vital rust crate called ring wasn’t building. There has been progress on this, but it hasn’t been merged just yet. It’s still under review.
tonic(grpc-based) crate wasn’t able to build successfully without ring. tonic is an excellent crate for building microservices with.
One last tool that is also dependent on ring is sccache. sccache will not build nor install on the VF2 because of the very same build error on ring. Most rust users implicitly use sccache to make their incremental builds faster.
On the VF2 for the moment, you need to disable sccache on your “cargo build” by doing the following:
Ha, I just filed a bug on nextest which also failed on the (new) ring dependency. I hope VF2 makes RISC-V more common so we have fewer of these cases of missing support.
I’m not sure if anyone has mentioned this, but in the release notes for the Debian images, it mentions that we shouldn’t update the OS, since it messes up some of the configurations.
Note: Please avoid runningapt upgradeas it will override the existing customized mesa and linux-libc-dev versions provided.、
Please could somebody try this with podman and tell me if they succeed in building their image and running it successfully?
I added a bit of podman usage documentation to the readme and modified the build_rootfs to remove any use of fakeroot/sudo within the build_rootfs.sh script itself.
sudo isn’t allowed for mknod.
individual fakeroot commands within the script are insufficient to preserve the file user group permissions for the following commands within the script.
The correct solution is to use fakeroot to run the entire bash script which preserves the file user group permissions for the entire set of commands within that script.
Thanks for that, after trying everything else suggested above this finally fixes the issue and I can now update things. For anyone else reading this in 2024, the breakage changes over time so the original fixes stop working after a time, the one quoted above still works in early 2024.
It’s annoying to see the Debian folks have copied the X.509 braindamage of regarding signing keys as invalid after a certain amount of time, which makes it almost impossible to update older images without spending hours trying out a bunch of random tricks to completely bypass the security the signing is supposed to provide in the first place.
Damn posted too soon, it gets a bit further through the process but still ends with:
.