All installed systemd units are forcefully enabled on first boot

All systemd units are forcefully enabled on first boot, including those that does not enabled by default on package install (rsync and iperf3 services, for example) or even those that specifically disabled during armbian build process (smartmontools):

https://github.com/armbian/build/blob/9c75c86a5488b043b76ba39305d0113d98885688/lib/functions/rootfs/distro-specific.sh#L13-L15

It seems systemd's firstboot concept is not an ideal match for debian/ubuntu. AFAIC systemd expects empty/unpopulated `/etc` on first boot and populates it from all units defined in `/usr` ignoring package manager defaults or services made disabled during debootstrap or image build.
Systemd firstboot behavior triggered by
https://github.com/armbian/build/blob/9c75c86a5488b043b76ba39305d0113d98885688/lib/functions/rootfs/rootfs-create.sh#L229-L231

An ideal solution would be to regenerate only /etc/machine-id file on first boot, not triggering full systemd's "firstboot" procedure.
Unfortuntely I have not found solution except manual image file patching before first boot. Eg, mount SD image file, `rm /mnt/sd/etc/machine-id`, `systemd-firstboot --root=/mnt/sd --setup-machine-id`

Userspace release: bookworm

1. How to reproduce?

1) Disable iperf3 service:

```

1. systemctl disable iperf3

2. systemctl is-enabled iperf3
   disabled
   ```
   2) Reboot. As expected iperf3 is still disabled after reboot
   3) Now, `rm /etc/machine-id` and then reboot once again. After that:
   ```

3. systemctl is-enabled iperf3
   enabled

4. systemctl is-active iperf3
   active
   ```

5.  

   1.  

      1. Branch

main (main development branch)

1.  

   1.  

      1. On which host OS are you observing this problem?

Other

1.  

   1.  

      1. Relevant log URL

No response

1.  

   1.  

      1. Code of Conduct

• [X] I agree to follow this project's Code of Conduct

Raised by: https://github.com/alex3d

https://github.com/armbian/build/issues/6264