I recently installed Arch Linux on my Pi Zero, it also uses FAT32 for the boot partition. I did the initial setup the way you described. Check out https://archlinuxarm.org/ , it's pretty great.

So that's how they came up with that. As someone who normally installs "normal" Linux systems I find it quite irritating that you have to put a file somewhere, especially the boot record, to "enable" ssh of all things. Up until now I considered it a weird decision. (and I still think it is not optimal) I deploy my RPi's in the field and don't put a monitor on them so I would expect ssh running as default. First time I found out about it was when reading the unit file when I was building a custom image based on raspbian, so I wouldn't consider it obvious :) When working on a Linux Device I just mount the main partition and do my customizations.

Raspbian did originally come with SSH enabled by default but the default credentials pi/raspberry made it trivial for misuse: https://www.zdnet.com/article/linux-malware-enslaves-raspber...

Exactly. You can't have it both ways: make it easy to remember the user/pass and also make it easy to login remotely.

Probably the right decision then. As I don't put them on public networks and delete the pi user this is of little concern to me, but given the target group, it is a simple safety measure.

I think there is a better solution: On a new install on first login, over ssh or on the gui, a user/password must be created.

This way the initial login only works once. Both gui user/pass and ssh user/pass are tied by default.

This is how it works in ARMbian. It forces a password change on first login. It can be annoying if you intend on deleting the alarm user right after that, but I can easily see why. "Default" passwords are always suboptimal.

> I deploy my RPi's in the field and don't put a monitor on them so I would expect ssh running as default. First time I found out about it was when reading the unit file...

So I guess you weren't building those images? If you're building headless RPi images that's something you learn immediately.

I have a tendency to learn stuff in reverse. I used to make an SD Card ready, connected monitor and keyboard and enabled everything as needed. Then I got the task to deploy n-RPi's and looked at the image first to customize it for the requirements we had. That's when I looked around and saw the unusual unit file and tried to understand why the service would look at the boot partition to start a service. In the end I think I added the symlink to start the service thorugh systemd.

I don’t know the details of how they implement this but it sounds like you want a systemd drop in file to override the ConditionPathExists (or similar) directive (I’m assuming you can’t or don’t want to modify the upstream unit directly given the use of symlinks).

It's at https://github.com/RPi-Distro/raspberrypi-sys-mods/blob/mast...

Or you can chroot to the mounted Raspbian root partition and do a normal `systemctl enable ssh` as part of your image customisation. Because, to be clear, you do not have to put a file in /boot to enable SSH, as it was claimed above. That is purely a helpful shortcut.

Have you considered something like Yocto[0]? I've had good luck with it.

[0] https://jumpnowtek.com/rpi/Raspberry-Pi-Systems-with-Yocto.h...

I'm interested in trying it. In the past I used a system based on Debian's Live Build (https://github.com/gumstix/live-build) and I was wondering how it differs, but I'm just now noticing even this suggests using Yocto instead.

it is a bit of work to get rolling, but IMHO worth the effort

Dietpi is pretty similar and easy to setup - https://dietpi.com/

One thing I really wish raspbian had is full disk encryption. I'd go for vanilla Debian, but cannot since raspberry pi4 hardware is not open enough.

The Ubuntu releases for the Raspberry Pi utilize cloud-init with the cloud-init configuration files being stored on the FAT32 partition.

Although there are some benefits, I see it as a complication.

The requirement of multiple partitions, with different filesystem types causes a lot of needless complication in the configuration and boot process.