OLIMEX / OLINUXINO

OLINUXINO is Open Source / Open Hardware, low cost from EUR 24 Linux Industrial grade Single Board Computer capable to operate -25+85C
www.olimex.com
1.35k stars 757 forks source link

Olimage-guide: suggestions #96

Open ilario opened 1 year ago

ilario commented 1 year ago

Dear Olimex, I am following the Olimage-guide using a A64-OLinuXino-2Ge8G-IND with the A64-OLinuXino-bullseye-base-20230515-130040.img.7z image and I would suggest a few edits to the guide (and some other general issues, please point me to the right place for opening a ticket and I will open specific tickets there):

Thanks for your amazing products!!

ilario commented 1 year ago

Another comment: twice in the guide there is this text: "In some cases you might also need to copy the u-boot with: ~#u-boot-install". I would specify that this could be useful (is it strictly needed?) only if the u-boot-olinuxino package was updated.

DanKoloff commented 1 year ago

Thanks for the feedback. Most are good points I will look to implement, except the first one:

ilario commented 1 year ago
* using dd or gnome-disks is not recommended, users that know what they are doing don't need a guide on how to prepare an sd card for Linux, and this guide is meant for absolute beginners, so they should use BalenaEtcher or USBImager;

Yep, you are right, makes a lot of sense.

I should expand that part of the guide tho since it is good idea to also test each card with F3 or H2testw beforehand; big chunk of all problems come from poor cards or poorly prepared cards;

Wow, good idea! Also badblocks -sn or badblocks -sw could work for that (it could take very long time as it should do 4 passes, if a single one is enough, the -t random option could help).

More comments, again, please tell me if there are proper places for reporting these and I will copy them there:

Thanks!

ilario commented 1 year ago

This could be a security issue, and a fix should be suggested in the guide (or fixed in the OS image):

$ ssh olimex@192.168.1.110
The authenticity of host '192.168.1.110 (192.168.1.110)' can't be established.
ED25519 key fingerprint is SHA256:E3xaihOuLtWT27+wajrRq9CEqDx+jCVKgdvKOLZuLtk.
This host key is known by the following other names/addresses:
    ~/.ssh/known_hosts:25: 192.168.1.111
Are you sure you want to continue connecting (yes/no/[fingerprint])?

And this can be confirmed logging in to both devices and running:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

that for both devices gives:

256 SHA256:E3xaihOuLtWT27+wajrRq9CEqDx+jCVKgdvKOLZuLtk root@runner-gkasaxdh-project-10-concurrent-0 (ED25519)
DanKoloff commented 1 year ago

It is good piece of info for new users. Will mention that in the manual too. But it is user's responsibility to delete or re-generate SSH keys. I'd consider that in the same league as using default user root and password olimex without changing it.

ilario commented 1 year ago

It is good piece of info for new users. Will mention that in the manual too. But it is user's responsibility to delete or re-generate SSH keys. I'd consider that in the same league as using default user root and password olimex without changing it.

Mh, surely it has at least to be mentioned. I did not expect to have to do that. The only other similar situation I had was using OpenWrt, and its host key is generated at the first boot (the dropbear init script checks if the host key is valid and generates a valid one).

Just saw that on Raspbian there is a systemd service running only once and regenerating the host keys: https://github.com/RPi-Distro/raspberrypi-sys-mods/blob/master/debian/raspberrypi-sys-mods.regenerate_ssh_host_keys.service#L8. In my opinion, using this would be a valid solution also.