VisionFive 2 Debian Image 202302 Released

Still ancient 5.15? I guess I’ll give this a pass then. Is the intent to stay at 5.15 until everything is upstreamed?

1 Like

5.15 ancient?

This is the second Longterm version of the kernel on the list. it’s not that old in reality.
It’s not beause the first LTS is 6.1 that all 5.x kernel are “ancient” & “deprecated”. 5.15 is still maintained, latest release 5.15.96 was a couple of days ago.


Thank you for the link, i’m sure some people will find that useful, and I’m sorry for not properly explaining myself in my original post.

I think this change badly impacts people doing headless installs (or installs with non-working monitor combos.) since it puts you in a chicken-in-egg situation. Effectively mandating people to use a UART/FTDI connection to get access to a shell in order to install openssl. uurgh.

It sort of worries me that StarFive have done this, it’s not an improvement, it’s a regression.


I appreciate the releases of

  • the new image:

  • the new firmware:

But I believe the community would be better served if we could just do the usual apt-get update/upgrade to get the goodness rather than having to flash new firmware and flash a new sdcard.

Honestly this is very cumbersome and wastes much time for the users. Please consider finding another method where the apt-get update/upgrade actually take care of upgrading the firmware and respective packages.

I recall the Radxa Rock board being able to upgrade its firmware with special hooks to do that.
Then they provided their own repo which was set in the /etc/apt/sources.list holding their radxa specific packages.

I was hoping starfive were going to follow a similar pattern when delivering their firmware and packages.


It was probably me pointing this out that might have instigated the change.
If you look at the default openssh startup scripts, they will automatically generate new ssh keys if they are missing (“/usr/bin/ssh-keygen -A” does not overwrite any existing files, it exits cleanly without changing anything if they already exist). So all that really needed to happen was to delete the existing ssh keys (see first link above) before shutting down the fully tested OS to generate the primary image file.

# strace /usr/bin/ssh-keygen -A 2>&1 | tail -6
stat("/etc/ssh/ssh_host_rsa_key", {st_mode=S_IFREG|0600, st_size=1823, ...}) = 0
stat("/etc/ssh/ssh_host_dsa_key", {st_mode=S_IFREG|0600, st_size=1381, ...}) = 0
stat("/etc/ssh/ssh_host_ecdsa_key", {st_mode=S_IFREG|0600, st_size=505, ...}) = 0
stat("/etc/ssh/ssh_host_ed25519_key", {st_mode=S_IFREG|0600, st_size=399, ...}) = 0
exit_group(0)                           = ?
+++ exited with 0 +++

User could apt install it in xterm. We consider that it will be a potential security issue if we pre-install openssh-server. however, ssh hosts keys should be unique on every machine. so we decide to remove openssh from pre-build image. please advise if you have any suggestion.

1 Like

thanks for your suggestion. let’s think about how do we get this better.

BTW, actually, the new Debian image could boot it from TF card directly. so user dont have to worry about firmware updates. just put the bootmode to sd position before power up.

just in case the user need to update the firmware for new features or bug fixes. apt update is a good choice.


Thankyou for replying, It is a irritating problem I agree. I’ve had to solve this myself when building customised CentOS images for my (paranoid) customers. But that also means it’s a well discussed and ‘solved’ problem.


The most common approach is to have sshd enabled and running, but only for password login to the default user account, not root… And put that user in wheel, sudo or whatever group you configure to have root sudo access. As @mzs says you can strip out the machine keys before preparing the image if you must do this from a installed system.

But that leaves you with the ‘predictable username/password’ issue, which has plagued the Pi community in particular until their (recent) solution. Which is to use initial boot scripting to look for specific files in /boot and use those to configure the username/password (an encrypted/hashed password) and some other settings, since this is a FAT partition it’s really easy to mount after writing the image and then you just need a text editor.

But that is complex to set up, test and document so to begin I’d try something similar but much simpler.

Have ssh installed but disabled as the default. Have a early boot script that looks for the existence of a ‘.ssh’ file (no contents) in the /boot folder.

If present you delete the .ssh file and create the link /etc/systemd/system/ → /usr/lib/systemd/system/sshd.service to enable the service (at least, that works on Fedora and co; I need to double-check that Debian systemd does the same).

Eg; you make users explicity enable sshd by mounting the boot partition and touching that file after writing the image. But this is effectively trivial for users who are skilled enough to be doing headless installs in the first place. :wink:

And, of course, most systems have a full console on the Screen+Kbd from startup (and broader monitor support), so their command line is easier to access. I note the ‘Virtual Console’ line in the upcoming features, which will really help too.


In case anyone needs it, or wants to share, I created a torrent of the new SD-202302-minimal image. If someone wishes to add a seed, I will seed this as long as I am able.


I’ve added this to my seed box.


Whatever you do, please never make firmware updates automatic.

It should always be an explicit step, as the user might have custom firmware installed.

1 Like

$ sudo apt install ssh (metapackage)
does it all,

still getting debian keyring problems
The following signatures were invalid:
but does it matter ? is the snapshot ever updated or is it a fixed old repository ?
apt update is superfluous


It is what the name says, a snapshot and hence not updated. You’d need to switch to debian-ports sid/unstable to receive package upgrades.

But you really do need to know what you are doing if you do that. Like how to rollback from any packages you install that broke things you want to work or at least how to hold a few critical existing packages to prevent them from attempting to update.

1 Like

Painless? None of my Displays work with my VisionFive Board.
I rely on openssh server running at boot. If that is not working, i have
to fiddle around with a serial console and a second Computer. Why?

I beg you, please put and activate ssh service at default in your image.


In my 30 Years os Linux experience i can not remember that i had to rollback updates because of breakage.

There is the official Debian distribution (none exists for this risc-v hardware - yet - for that to happen it will need more up-streaming, but StarFive, in my mind, is doing everything the right way.). And there is the image above a buildroot OS with a Debootstrap pointing at a Debian package snapshot.

If you change where you are getting your packages from and upgrade say the kernel (currently only a custom longterm 5.15 has been patched to support the features of the JH7110 SoC, but patches are being pushed up-stream to 6.3 kernel and will probably be to the 6.4 kernel as well - see second link above) or upgrade anything to do with the graphics you will probably break things that most people typically want to work. But if you are running it headless (not using the GUI) and do not mind any or all of the features of this SoC being inaccessible, then you probably do not need to rollback.


I’m guessing that wasn’t in kernel and core development on brand new architectures…

We need patience, I’ve worked in a small and highly experienced team doing something similar (custom kernel + ‘just enough’ OS to support bleeding edge hardware) and it’s never pretty. Remember that this is a learning experience for StarFive too.

The time to start judging this against established distros is when the support rolls into those distros, Kernel 6.3/6.4 and beyond.

I’m kind of hoping that the roaring silence from Canonical lately means they are hard at work on this platform and going to delight us soon… ?


I have implemented some embedded Terminals on a Gentoo base.
Bootstrapped DEC Alph, SGI Octane and some Apple PPC on Gentoo base.
The best Way in Cace o breakage is to go further and update your Librarys instead of rollback.

1 Like