VisionFive 2 Debian Image Released

VisionFive 2 （English Forum)
111

Waiting for the next image, I wanted to ask what is the reason for not including a swap partition.

at least in my case after loading the image 69 correctly I don’t see the swap partition.

1 Like
112

Ignoring wear-and-tear issues on the device, having a SD card based swap is horrible due to it being very slow, for many SBC and desktop use-cases it’s better to have the system OOM (trigger an Out Of Memory event and kill the offending process) than bog the whole machine down to nothing as swapping overwhelms up the disk and memory resources.

For servers you absolutely do want some swap to provide a buffer and allow inactive processes to suspend into swap. My Pi3’s all have 1Gb of swap configured for this reason.

But the netbook I’m using now and my Pi4 desktop have no swap, The last oom on this 8gb netbook was when I had Chrome, KiCAD and Inkscape open, then tried to render a big model in OpenSCAD… ymmv.

edit: forgot to say that if you are setting up an NVMe from scratch, not expanding the / partition to the whole disk, and adding a small swap after it is a good idea.

1 Like
113

The problem with docker on the debian image is with iptables / netfliter ie firewall rules.
I’m not sure myself but I think the kernel is in sync with the user space tools.
Th work around is to get debian to use the old tools to configure the firewall.
update-alternatives --set iptables /usr/sbin/iptables-legacy

114

Lots of good info in this thread, thanks!

I can confirm that the apt GPG error is fixed if you update sources.list and take the 800+ updated packages, and: keep your existing u-boot config.

I’m having the “HDMI stopped working” bug that others posted about. Looks like the upgrade did not touch my lightdm.conf so it’s not that. Did anyone have any luck bringing HDMI back online after the update?

115

Try this: Experimental debian sid image , works like a charm e (even in 4K mode).

1 Like
116

Does anyone know the content of the 16 MiB partition 1? The official Debian images from StarFive contain it and the experimental images above create it as well, but as far as I can see leaves it empty: imagebuilder/gpt-partitions.txt at main · hexdump0815/imagebuilder · GitHub

Since the VisionFive 2 has an SPI bootloader, that first partition does not contain U-Boot, or at least it wouldn’t be required then, is it?

I’m trying to create own images, running the kernel builds from StarFive and leaving SPI bootloader untouched, resp. upgraded from official U-Boot builds. Does anyone know the requirements?

  • GPT partition table or does MBR work as well?
  • Do uEnv.txt and extlinux need to be located on a FAT partition, or does ext4 work as well?
  • I hope it works with a single ext4 partition, as FAT is not really supported by dpkg, causing issues on Debian when reinstalling/upgrading the kernel package.
1 Like
117

Right now it is empty to the best of my knowledge. The partition schema is mainly due to the current u-boot environment.

Not exactly, but the only real requirement for what you do is to have a UART connection. Everything else is quite harmless and has a good chance to work with minimal adjustments.

You find more details about your questions in https://u-boot.readthedocs.io/en/latest/develop/distro.html.

2 Likes
118

i tried to omit it when i created my experimental debian sid image and then it did not boot - my assumption was that it is maybe used to store the u-boot env, but i did not yet look into the u-boot source …

1 Like
119

I first tried an image with a single MBR ext4 partition, extlinux and the uEnv.txt below /boot directory, just like the images are shipped with, and with a content which worked fine on the official image as well. This did not boot.

Then I tried the same with a GPT partition scheme, and it did still not boot.

Left differences are that uEnv.txt and extlinux are on the first partition, instead of on the second one (since I omitted the 16 MiB partition), and that those are on an ext4 partition (instead of FAT). I’m hoping very much that FAT is no requirement, as this makes DEB packaging complicated and messy. Probably the official/default U-Boot on SPI checks for boot configs only on the second partition, or on a partition with a specific offset?

I’ll try it with an image with a single partition starting at 17 MiB offset, and if this does not work with the empty 16 MiB partition.

What makes things a little difficult is that I don’t have the SBC here, but a team member instead who has no UART adapter, so we have no way to see U-Boot logs currently. However, the LEDs tell quite much and our images setup network and spin up an SSH server automatically. UART adapter will be ordered now, which will surely reveal more details.

120

find below a procedure for your friend to access at least the u-boot env.

121

The most relevant part of the boot env for you is i think:

bootcmd=run load_vf2_env;run importbootenv;run load_distro_uenv;run boot2;run distro_bootcmd
bootcmd_distro=run fdt_loaddtb; run fdt_sizecheck; run set_fdt_distro; sysboot mmc ${fatbootpart} fat c0000000 ${bootdir}/${boot_syslinux_conf};
fatbootpart=1:2

I.e. partition 2 must be fat.

1 Like
122

Okay bad news, it does require a FAT partition and it gets much uglier with recent commits:

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 :disappointed:.

5 Likes
123

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:

export RUSTC_WRAPPER=

I hope this helps other VF2 rust users out there.

1 Like
124

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.

125

sudo apt install curl
soluce : curl https://www.ports.debian.org/archive_2022.key | apt-key add -

or

sudo /bin/busybox wget -O- https://www.ports.debian.org/archive_2022.key | apt-key add

Soluce :

gpg --keyserver pgp.mit.edu --recv-keys E852514F5DF312F6
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key E852514F5DF312F6: public key “Debian Ports Archive Automatic Signing Key (2022) ftpmaster@ports-master.debian.org” imported
gpg: Total number processed: 1
gpg: imported: 1

or
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys E852514F5DF312F6
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
Executing: /tmp/apt-key-gpghome.YxsDTq1fH7/gpg.1.sh --keyserver keyserver.ubuntu.com --recv-keys E852514F5DF312F6
gpg: key E852514F5DF312F6: “Debian Ports Archive Automatic Signing Key (2022) ftpmaster@ports-master.debian.org” not changed
gpg: Total number processed: 1
gpg: unchanged: 1

Looks like the ubuntu servers also contain the debian keys.

2 Likes
126

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 running apt upgrade as it will override the existing customized mesa and linux-libc-dev versions provided.、

2 Likes
127

… and today is Tuesday.

128

https://github.com/kng/visionfive2-docker/pulls

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.

./podman_shell.sh fakeroot /bin/bash build_rootfs.sh

129

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:

W: GPG error: debian-ports:/ 2022-06-16 19:48:33 - snapshot.debian.org unstable InRelease: The following signatures were invalid: EXPKEYSIG E852514F5DF312F6 Debian Ports Archive Automatic Signing Key (2022) ftpmaster@ports-master.debian.org

The result is that an apt-get upgrade produces no results.

1 Like
130

OK, I’ve found the fix, or at least bypass, edit the repo from the initial “debian-ports:/ 2022-06-16 19:48:33 - snapshot.debian.org unstable main” to the latest one present, “debian-ports:/ 2023-07-24 14:15:07 - snapshot.debian.org unstable main”, and you’ll get updates at least until mid-2023.

1 Like