Oh, so the switch work now? I’m using the recommended setting from the last time I setup a board with when looking at the board with the USB port in front, both switches on the right side 
Will change the SD setting once I finished setup the rootfs
1 Like
Yup sounds sensible
Confirmed - this works. Thank you.
2 Likes
Gents,
If the switch is working now could you please check if it is now possible to from nvme ssd?
By boot from nvme ssd I mean boot from SPI Flash that will look for OS image at nvme ssd.
Thanks
Kernel needs to be somewhere not nvme, as u-boot still does not have pci-e support.
For now, I load kernel from sd with root= pointing to nvme. It’s not a terrible solution.
I could put the kernel at the end of the SPI, where there is enough storage, but I would still need the sd, as u-boot configuration is held there. There’s space reserved in SPI for u-boot env, but it is not being used currently.
Using the sd as a clutch until pci-e support is in place seems to be the better solution for now.
2 Likes
That is something WIP by the engineering team, some codes are in place, but we don’t have a commit date internally yet.
1 Like
@kira
I think you are missing the point if you think my problem with this is not knowing how to use apt install.
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.
4 Likes
@kira
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.
2 Likes
I appreciate the releases of
- the new image:
https://drive.google.com/drive/folders/1fBNI8kKIpwBfET1tCkfWgqsP0DM8X_yy
- 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.
2 Likes
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 +++
#
4 Likes
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.
3 Likes
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.
TL;DR
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/multi-user.target.wants/sshd.service → /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. 
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.
5 Likes
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.
6 Likes
I’ve added this to my seed box.
2 Likes