rpi-distro / raspberrypi-sys-mods Goto Github PK

1. I have wrote a Raspberry Pi OS (64-bit) from https://downloads.raspberrypi.org/raspios_lite_arm64/images/raspios_lite_arm64-2022-09-07/2022-09-06-raspios-bullseye-arm64-lite.img.xz to SDcard.
2. I have created /boot/config.toml configuration.
3. I started RPi and /usr/lib/raspberrypi-sys-mods/firstboot was executed.
4. There is an error in /var/log/firstboot.log:

  File "/usr/lib/raspberrypi-sys-mods/init_config", line 12, in <module>
    import toml
ModuleNotFoundError: No module named 'toml'

5. toml package is really missing in folder /lib/python3.9/.

So I suggest to install package python3-toml as part of the Raspios lite.

Following 4.19.40 and newer and improved driver, maybe one can remove related blacklist?

FIRSTBOOT does some partition checks, in particular that the root partition is the last partition and is on the same device as the boot partition. I assume these are to prevent needlessly resizing the root partition for NOOBS/PINN. However, this causes firstboot to exit completely and it does not do any of the other tasks such as ssh key generation or OS customisations. I think it should just prevent the partition resizing, but continue with the other tasks, or am I missing something?

(whilst OS customisations would not be applicable from rpi-imager, these files could be produced from other tools.)

Hi,

According to the official blog there is following statement:

Over half of the seven million Raspberry Pi units we sell each year go into industrial and commercial applications, from digital signage to thin clients to process automation.

Most industrial applications use the os lite version with no desktop interface at all and are behind a firewall that monitor the connections. When an OS pushes a package update and without user permission, install some trusted keys and create new hits on the firewall that require an ITSEC investigation, well, this has nothing to do with the industrial domain. Basically CM4 module remains out of scope in my opinion and the only way to recover the lost trust is to have an LTS version with the guarantee that no bloatware will be added. Connections management is a must for today security standards, security devices trigger an alert or totally block a device if unexpected traffic is detected as the device will be considered compromised.
Things are even worse because I had not seen any acknowledgement that this was a bad decision, but instead comments to previous issues are blocked and some of them are even deleted.

PS. I know I can delete these two files, but imagine you need to do this on dozens devices.

Thanks for this very useful package.

I noticed that cmdline.txt serial interface replacements may not catch situations where both console=ttyAMA0 and kgdboc=ttyAMA0 exist.
Is it intended?
Should only the first one be replaced, and not kgdboc?
Thanks for your thoughts.

PS: also unsure why whois dependency is required

If the user disables wifi in config.txt before setting the country they will still see the message "Wi-fi is disabled because the country is not set." on logging in. However, they will be unable to set the country using raspi-config, because it will detect that the wifi is disabled by the user and refuse to set the country.

Recently pushed commit 655cad5 adds Microsoft repo to /etc/apt/sources.list.d, as well as /etc/apt/trusted.gpg.d/microsoft.gpg. Why is this actually needed?

From the latest Raspberry Pi OS Lite image, the content of /boot/cmdline.txt before running firstboot is:

console=serial0,115200 console=tty1 root=PARTUUID=544c6228-02 rootfstype=ext4 fsck.repair=yes rootwait quiet init=/usr/lib/raspberrypi-sys-mods/firstboot

If I am not wrong (according to this) the string quiet is removed only if the string splash is found. However, given the file mentioned above quiet appears to be removed anyway, infact after first reboot the content of cmdline.txt becomes this:

console=serial0,115200 console=tty1 root=PARTUUID=544c6228-02 rootfstype=ext4 fsck.repair=yes rootwait

Knowing that the exit status of grep is 0 when a match is found and that such value is interpreted as a success in an if statement, shouldn't the negation be removed from the following line?

What am I missing?

The call to fix_partuuid here ->

Could you possibly wrap this call within an "If Not 'NOOBS'" condition?

cc: @XECDesign

Hello
I have headless pi and do not want vscode or any Microsoft products.
How can I remove it?
Thanks

There appears to be a bug in the assignment of the primary and secondary serial ports in bookworm.

It looks like a problem in:

raspberrypi-sys-mods: /etc/udev/rules.d/99-com.rules

When bluetooth is disabled in config.txt as:

dtoverlay=disable-bt

I would expect that

/dev/serial0 -> ttyAMA0
/dev/serial1 -> ttyS0

and this is what bullseye does, correctly, but instead with bookworm we see:

/dev/serial1 -> ttyAMA0

and /dev/serial0 is not symlinked at all.

This is contrary to the advice here:

https://www.raspberrypi.com/documentation/computers/configuration.html#primary-and-secondary-uart

and looks like a bug in bookworm :)

In my humble opinion, the file /etc/sudoers.d/010_pi-nopasswd should be removed or changed. Since the last release, the pi user is no longer a default user (ref: raspberry-pi-bullseye-update-april-2022).

Maybe I didn't got it, how it should work then I would appreciate any explanation.

Hi,

is there a specific reason, why there is no LICENSE, COPYING or similar declaration (lone SPDX-License-Identifiers in each file probably do not suffice) stating under what license the content of this repository is published at github?
As i understand law, the current form of publication makes it open source but not free open source, meaning that any modifications i might make are in almost all cases prohibited to be shared with others.

So that's the question: why are the current state of affairs as they are?

best regards,
Max

The abovementioned file contains an echo statement which is apparently not adequate in a sysctl.conf file. Consequently, starting systemd-sysctl.service via "systemctl start" produces an error message. The second line in the file should probably read

vm.min_free_kbytes = 16384

On a further note, this settings conflicts with "vm.min_free_kbytes = 8192" found in /etc/sysctl.d/99-sysctl.conf under "rpi tweaks".

In the Debian-maintained Buster package for RPi.GPIO, the package maintainer has included the udev rules in the 'rpi.gpio' debian package. It uses the 'dialout' group rather than the 'gpio' group. Could there be a conflict with 'raspberrypi-sys-mods/etc.armhf/udev/rules.d/99-com.rules'? It suspect it will cause a lot of confusion with end users following existing guides found around the web. A good example would be when the user has added the 'www-data' user to the 'gpio' group so that website scripts can use gpio.

A little example:

# Automatically added by dh_systemd_start/13.3.4
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
        if [ -d /run/systemd/system ]; then
                systemctl --system daemon-reload >/dev/null || true
                if [ -n "$2" ]; then
                        deb-systemd-invoke try-restart 'apply_noobs_os_config.service' 'regenerate_ssh_host_keys.service' 'rpi-display-backlight.service' 'sshswitch.service' >/dev/null || true
                fi
        fi
fi
# End automatically added section
# Automatically added by dh_systemd_start/13.3.4
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
        if [ -d /run/systemd/system ]; then
                systemctl --system daemon-reload >/dev/null || true
                if [ -n "$2" ]; then
                        deb-systemd-invoke try-restart 'apply_noobs_os_config.service' 'regenerate_ssh_host_keys.service' 'rpi-display-backlight.service' 'sshswitch.service' >/dev/null || true
                fi
        fi
fi
# End automatically added section
# Automatically added by dh_systemd_start/13.3.4
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
        if [ -d /run/systemd/system ]; then
                systemctl --system daemon-reload >/dev/null || true
                if [ -n "$2" ]; then
                        deb-systemd-invoke try-restart 'apply_noobs_os_config.service' 'regenerate_ssh_host_keys.service' 'rpi-display-backlight.service' 'sshswitch.service' >/dev/null || true
                fi
        fi
fi
# End automatically added section
# Automatically added by dh_systemd_start/13.3.4
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
        if [ -d /run/systemd/system ]; then
                systemctl --system daemon-reload >/dev/null || true
                if [ -n "$2" ]; then
                        deb-systemd-invoke try-restart 'apply_noobs_os_config.service' 'regenerate_ssh_host_keys.service' 'rpi-display-backlight.service' 'sshswitch.service' >/dev/null || true
                fi
        fi
fi
# End automatically added section

Every service has at least four entries of one type, but then also there are additional practically identical but differently formatted blocks for the same services. Something went wrong with the debhelper execution it seems, but since I don't use debhelper, I cannot say what 😉.

I don't use vscode. I will NEVER use vscode. I run my raspberry pi headless as a DNS filter for an education environment. (Where we use libreoffice.) I only access RPi via ssh over openVPN.

How do I instruct apt to remove vscode.list and other trojans, such as /etc/apt/trusted.gpg.d/microsoft.gpg (that seem to have appeared on my devices without my request)? [Seem ironic to have a corporation's key inserted into "trusted" when this just confirms that they can't be - double irony for me reporting here on github.]

I would also like to know the best way to prevent ANY Microsoft files being inserted into /etc on my linux operating system. (Feels worse than a root-kit.) While I sensibly and calmly investigate the potential impact of migrating to either archlinuxarm or FreeBSD.

root@raspberrypi:/home/pi# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up raspberrypi-sys-mods (20161018+1) ...
/var/lib/dpkg/info/raspberrypi-sys-mods.postinst: 49: /var/lib/dpkg/info/raspberrypi-sys-mods.postinst: Syntax error: ";;" unexpected (expecting "fi")
dpkg: error processing package raspberrypi-sys-mods (--configure):
subprocess installed post-installation script returned error exit status 2
Errors were encountered while processing:
raspberrypi-sys-mods
E: Sub-process /usr/bin/dpkg returned an error code (1)

Would it make sense / be possible to change etc.armhf to just be etc so that it is installed on both armhf & arm64? Or alternatively just create a separate etc.arm64 subtree alongside the etc.armhf subtree for the files that work just fine on arm64?

For instance the etc.armhf/udev/rules.d/99-com.rules file definitely works on arm64, and is required to setup the serial device node so that the Bluetooth uart device scripts work in arm64 installed on the 3b+.

I just executed an sudo apt update followed by sudo apt dist-upgrade on my Raspberry Pi 3 Model B Plus Rev 1.3 running Raspbian GNU/Linux 11 (bullseye)

The upgrade failed with the following error message:

Setting up raspberrypi-sys-mods (20220110+1) ...
Fixing previous dhcpcd wait.conf drop-in to prevent double logging...
/var/lib/dpkg/info/raspberrypi-sys-mods.postinst: 27: sed: Exec format error
dpkg: error processing package raspberrypi-sys-mods (--configure):
 installed raspberrypi-sys-mods package post-installation script subprocess returned error exit status 126
Errors were encountered while processing:
 raspberrypi-sys-mods
E: Sub-process /usr/bin/dpkg returned an error code (1)

Checking /var/lib/dpkg/info/raspberrypi-sys-mods.postinst:27 I found that the script tries to replace something in the /etc/systemd/system/dhcpcd.service.d/wait.conf which contains the following content on my device:

[Service]
ExecStart=/usr/sbin/dhcpcd -w

Is my wait.conf messed up or is something wrong with the script?

HW: RaspberryPi 4B
OS: Raspberry Pi OS Lite 64bit, otherwise up-to-date Bullseye

raspberrypi-sys-mods (20220901) installs fine on more conventional systems running from SD and USB-drives but fails on my systems that network boot from a NFS share.

Error message:

<snip>
Setting up libc-devtools (2.31-13+rpt2+rpi1+deb11u4) ...
Setting up raspberrypi-sys-mods (20220901) ...
Checking if boot partition needs 'flush' option...
dpkg: error processing package raspberrypi-sys-mods (--configure):
 installed raspberrypi-sys-mods package post-installation script subprocess returned error exit status 1
Setting up raspberrypi-net-mods (1.3.4) ...
Modified /etc/network/interfaces detected. Leaving unchanged and writing new file as interfaces.new.
Setting up libcamera-apps-lite (0~git20220830+1bf0cca-1) ...
Setting up libc6-dev:arm64 (2.31-13+rpt2+rpi1+deb11u4) ...
Setting up console-setup-linux (1.205+rpt1) ...
Setting up console-setup (1.205+rpt1) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for libc-bin (2.31-13+rpt2+rpi1+deb11u4) ...
Errors were encountered while processing:
 raspberrypi-sys-mods
E: Sub-process /usr/bin/dpkg returned an error code (1)
> 

This is what the fstab looks like on one of the failing devices:

> cat /etc/fstab
proc            /proc           proc    defaults          0       0
#PARTUUID=6c872c37-01  /boot           vfat    defaults,flush    0       2
#PARTUUID=6c872c37-02  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that
# PXE/TFTP boot
[obfuscated ip]:/srv/nfsroot/tftpboot/[obfuscated serialnr]  /boot           nfs    defaults          0       0
[obfuscated ip]:/srv/nfsroot/pxeroot/tank     /               nfs    defaults,noatime  0       0

Hi,
My dev box received an update of raspberrypi-sys-mods numbered 20210125 from raspberrypi.org

signed by — Serge Schneider Mon, 25 Jan 2021 16:03:24 +0000

But I don't find it anywhere in :

https://github.com/RPi-Distro/raspberrypi-sys-mods/blob/master/debian/changelog

Im confused, is this voluntary ?

/etc/profile.d/sshpasswd.sh assumes that any user logging in via SSH is allowed to run the command

sudo -n grep -E '^pi:' /etc/shadow

That assumption is just plain wrong.

with installed raspberrypi-sys-mods the error message "-bash: gettext.sh: Datei oder Verzeichnis nicht gefunden" comes up after successful login.

("Datei oder Verzeichnis nicht gefunden" translated to english: File or directory not found )

tracked the message down to /etc/profile.d/wifi-country.sh where in line 4
the file gettext.sh is sourced:

(
        export TEXTDOMAIN=wifi-country

        . gettext.sh

For the last few drops I have noticed that each time raspberrypi-sys-mods gets an upgrade as part of a system apt-get upgrade, the RPF touchscreen goes black. I have also experienced that over HDMI feeding up a lapdock (standard HDMI displays are unaffected).

Today I went back to an earlier Raspbian image just to test the theory that raspberrypi-sys-mod was the culprit, and confirmed it is. In fact I can produce the problem on demand like so:

sudo apt-get remove raspberrypi-sys-mod
sudo apt-get install raspberrypi-sys-mod

Why not replace microsofts repository by the vscodium repo since this is probably done for cash, since its pushed onto people without an obvious warning. There were obvious other free options but they chose not too? Why?

https://vscodium.com/

The new version of raspberrypi-sys-mods is trying to install systemd and I'm not sure why this is necessary.

Depends: init-system-helpers (>= 1.18~), libcap2-bin, systemd (>= 230)

Is there any way around this as I'm not keen on installing systemd at all.

It's hard to understand what it is without a README.

The new sshpasswd.sh expects the executing user to have sudo without password rights, if that is not the case at least in my setup (which is pretty much default, besides the user configuration) it will send an email warning about security issues.

On one of my machines that is triggered by connecting via ssh, on one other it is actually triggered by an init script of one of the processes. In the first case it just fails with "a password is required", in the second case it warn that "user X is not in sudoers".

In itself that is a quite useful feature, but I might not be the only one who gets confused if systems send you emails warning about someone grepping in your /etc/shadow file.

I'm running kernel 4.19.8-v7+ on a Pi 3B+ (from BRANCH=next rpi-update). When running systemctl status, I noticed that the system was in a "degraded" state. Running systemctl list-units --failed showed that the failed unit was the wifi-country.service unit.

That service runs /usr/lib/raspberrypi-sys-mods/wifi-country, which performs the following logic to get the WiFi iomem address:

address="$(/bin/grep -m 1 /mmc /proc/iomem | /usr/bin/cut -f1 -d-)"

The contents of /proc/iomem look something like this:

root@raspberrypi:~# cat /proc/iomem 
00000000-3b3fffff : System RAM
  00008000-00bfffff : Kernel code
  00d00000-00e69ecf : Kernel data
3f006000-3f006fff : dwc_otg
3f007000-3f007eff : dma@7e007000
3f00b840-3f00b87b : mailbox@7e00b840
3f00b880-3f00b8bf : mailbox@7e00b880
3f100000-3f100027 : watchdog@7e100000
3f101000-3f102fff : cprman@7e101000
3f104000-3f10400f : rng@7e104000
3f200000-3f2000b3 : gpio@7e200000
3f201000-3f201fff : serial@7e201000
  3f201000-3f201fff : serial@7e201000
3f202000-3f2020ff : mmc@7e202000
3f212000-3f212007 : thermal@7e212000
3f215000-3f215007 : aux@7e215000
3f300000-3f3000ff : mmc@7e300000
3f980000-3f98ffff : dwc_otg

That grep for /mmc will never match, and running the wifi-country script results in:

Could not determine WiFi iomem address

I found some error message about rfkill-persist. I don't know what this program originally intends.

It seems that saving state of "RF Kill flag" does not work, and the wireless LAN device is invalidated each time system rebooted.

Error log are below:

$ LANG=C journalctl -b  | grep rfkill
Dec 23 17:10:05 raspberrypi systemd[1]: Listening on Load/Save RF Kill Switch Status /dev/rfkill Watch.
Dec 23 17:10:07 raspberrypi systemd-udevd[464]: Process '/usr/lib/raspberrypi-sys-mods/rfkill-persist' failed with exit code 1.
Dec 23 17:10:11 raspberrypi systemd-udevd[494]: Process '/usr/lib/raspberrypi-sys-mods/rfkill-persist' failed with exit code 1.
Dec 23 17:10:11 raspberrypi systemd-udevd[494]: Process '/usr/lib/raspberrypi-sys-mods/rfkill-persist' failed with exit code 1.

I checked script's source. It invoke systemd-rfkill as follows.

$ cat  /usr/lib/raspberrypi-sys-mods/rfkill-persist
#!/bin/sh
RFKID=`basename $DEVPATH`
/lib/systemd/systemd-rfkill save $RFKID

However, systemd-rfkill command isn't require any arguments.

 $ sudo /lib/systemd/systemd-rfkill save
This program requires no arguments.

Version information:

• Raspberry Pi 3B
• Raspbian Stretch 2017/11/29
• raspberrypi-sys-mods 20171127

$ uname -a
Linux raspberrypi 4.9.70-v7+ #1068 SMP Mon Dec 18 22:12:55 GMT 2017 armv7l GNU/Linux

Can you abstract the hard-coded boot path /boot to a variable so that it can be changed in one place instead of half a dozen?

I'm using GRUB EFI with some other OSes and this is requiring a lot of hacking.

Hey there,

Please forgive me if my english isn't the best, I am no native english speaker.

I am one of the MainsailOS maintainers and some users reported an Issu that our latest Image hangs on the first boot while Generating SSH Keys ... is running.

After a bit of research I identified the root cause in the fix_partuuid function of first boot script.
To come them by I commented out the whiptail lines and added set -ex to see whats going on.

As you can see it struggles to do the step. I waited for around 20minutes on a Pi Zero 2 W without being successful.

To prove the issue please use our latest image using rpi-imager.

As proof of concept for that script you can use an artifact of my patched version from here:

https://github.com/mainsail-crew/MainsailOS/actions/runs/4515245620

But I think you can also reproduce it with pi-gen using the latest kernel instead of kernel 5.15y which is currently shipped in rpi-imager

I will open a PR on that, to prevent you are running into that issue with future releases of Raspberry Pi OS.

Regards Kwad

Still I don't know where you are about this problem, ill keep suggest new possibility.

This one would be to separate the management of the file /etc/apt/sources.list.d/vscode.list and the related key management in a separate package that do one thing (adding M$ repo) and do it well.

Original issue: raspberrypi/rpi-imager#581

If the user enters a SSID in Imager's advanced settings that contains a $ and writes RPI OS, /etc/wpa_supplicant/wpa_supplicant.conf does not get written correctly.

Imager correctly writes a firstrun.sh that calls: /usr/lib/raspberrypi-sys-mods/imager_custom set_wlan '$1234' 'somehash' 'GB'
And that should work because the shell does not see it as a variable if the $ is inside single quotes.

But your script in turns seems to write out a set-wlan helper script that contains: if raspi-config nonint do_wifi_ssid_passphrase "$1234"
And with double quotes $1 does is seen as variable.

Probably also gives problems if the SSID contains a " but haven't tried.

Hi,
Super-minor issue to report; there's some .DS_Store files leaked into the raspberrypi-sys-mod package in the following locations:

/usr/.DS_Store
/usr/lib/.DS_Store
/lib/.DS_Store
/lib/udev/.DS_Store

I can't actually see those files in the git repo so presumably an issue in packaging?

Anyway... totally a non-issue, which I wouldn't bother to mention except... OCD!! :-D

Peter.

It looks like /boot/custom.toml is applied on firstboot, but if I have an SD card of an existing image, and move from one location to another and want to update the wifi, can we have /boot/custom.toml apply on every boot?

raspberrypi-sys-mods postinst appends audio settings to /boot/config.txt. If the existing config.txt uses hardware-specific sections ([pi3], etc) then those changes will only be applied to whatever hardware section was last active, not globally.

It should probably append an [all] before the audio changes.

Can the ability, via an option, be introduced to limit the size of rootfs at first boot?

There can be advantages to having a smaller rootfs partition and a separate partition for data.

Shrinking 'rootfs' is difficult, but starting with a smaller partition and increasing it is relatively simple.

Would be great if you instead of pinpointing a user in 010_pi-nopasswd you instead
pinpoint a group for example like this:

010_rpi-nopasswd:

%magicwand ALL=(ALL) NOPASSWD: ALL

as user pi anyway in my case its the first i remove from raspbian and create my own, so
hopefully you would consider altering this to a group policy instead of user policy.
I have allready made my quick and dirty deb package with the correct settings for this however i feel its much better if upstream version of raspberrypi-sys-mods would have this feature instead so i dont have to lock
my version as the one system would prefer :)

https://github.com/RPIWS/raspberrypi-sys-mods

//Martin aka ztealmax - rpiws.org

Problem:
The sshpasswd.sh script in etc/profile.d performs the check even if the current user is not able to perform the sudo action required. This triggers a security notice (and in my case an email).

Mitigation:
A possible solution would be to check the "$USERNAME" variable for equality with "pi"/"root" before calling "check_hash".
I can prepare a Pull Request if necessary.

ssh-keygen gets installed with openssh-client optional package. If openssh-client is not installed, regenerate SSH host keys fails at boot with the following message.

Starting Regenerate SSH host keys...
[FAILED] Failed to start Regenerate SSH host keys.
See 'systemctl status regenerate_ssh_host_keys.service' for details.

If ssh-keygen is not installed, it is safe to skip regenerating ssh host keys at boot.

In

https://github.com/RPi-Distro/raspberrypi-sys-mods/blob/master/debian/raspberrypi-sys-mods.postinst

at lines : 42, 76

Instead of echoing into files, you should use conffiles to allow dpkg to do the versioning management.

This is how it should be made :
https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html#automatic-handling-of-configuration-files-by-dpkg

Hello,

I found out that when you generate an own Raspberry Pi Image with pi-gen you will not have and get any Microsoft Repository. Because at the moment you only add the Microsoft repository if the raspberrypi-sys-mods version is lower than or unequal to the current version.

Greets
Christian

Continuing from #1:

Hello, after today upgrade to new version of raspberrypi-sys-mods and reboot I'm getting huge fps drops from motion detection camera connected to RPi 3 even I did upgrade to raspberrypi-sys-mods_20160916_all.zip from this thread with dpkg.
The second RPi 3 with camera and without upgrade works fine. Any suggestions please? Thanks.

By moving the entry for the pi user to /etc/sudoers.d/010_pi-nopasswd, passwordless sudo for pi is reintroduced even if it has previously been removed/disabled. I would consider that a security issue.

IMHO, the file should only be created if a) the original entry is still in /etc/sudoers and b) the user pi still exists.

Since c8a2ee7 you are using "uuid" in imager_set_custom

There are end-user reports suggesting that is MIA in RPI OS Lite: https://forums.raspberrypi.com/viewtopic.php?p=2165884#p2165884

Hello,

On every login, mkpasswd complains about wrong salt length:

Wrong salt length: 0 byte when 8 <= n <= 16 expected.

This is caused by the new sshpasswd.sh in /etc/pofile.d/ on line 10:

HASH=$(mkpasswd -msha-512 raspberry "$SALT")

I think there's something off with the sed line that results in an empty $SALT variable. At least, you should check $SALT for emptyness before passing it to mkpasswd.

The sshpasswd.sh script does not handle the salt correctly if the password string for the pi user contains rounds=... in the hashed password string.

Use case:

In this case I am configuring the pi user with Ansible and using a crypted password generated using passlib for python as described in this doc http://docs.ansible.com/ansible/faq.html#how-do-i-generate-crypted-passwords-for-the-user-module

This results in the following line in /etc/shadow: pi:$6$rounds=656000$salt$password...

Since sshpassword.sh does not expect this, it returns 'rounds=65600' as the SALT on line 9 and displays the following error when executing line 10:

Illegal salt character '='.

The above error appears to cause HASH to be an empty string which exits the script at line 11

Suggested solution:

Something along the lines of this should fix the issue:

if echo $SHADOW | grep -q "pi:\$6\$rounds\="; then
     SALT=$(echo "${SHADOW}" | sed -n 's/pi:\$6\$rounds\=[0-9]*\$//;s/\$.*//p')
else
    SALT=$(echo "${SHADOW}" | sed -n 's/pi:\$6\$//;s/\$.*//p')
fi