5
One comment or idea to the subject is: don't use /etc/rc.local anymore!
Debian/Raspbian/Raspberry Pi OS uses systemd instead of deprecated SysV since years as init system to start and manage services. rc.local is a leftover from SysV and only emulated by systemd, but with serious limitations. Have a look at Compatibility with SysV.
You should use a systemd ...
2
To give more insight into the issue, it appears to be a bug in 64-bit qemu emulating a 32-bit machine, which won't use the host's 32-bit libraries in a readdir() call, so the host kernel feed it with 64-bit offsets, which qemu passes to the emulated 32-bit system, which then reports an overflow. This leads to random missing files in the build.
One workaround ...
2
A desktop devoid of all images and icons sounds very much like a known issue with running on 64-bit hosts. qemu needs to be 32-bits for correct emulation and a proper build.
The fixes that worked for me is to run pi-gen directly on the Raspberry Pi 4 (it's a bit slow) or on Ubuntu 16.04 which is 32-bit.
Here is more info:
https://github.com/RPi-Distro/pi-gen/...
1
As @Ingo has said in his answer, systemd is indeed a valid and current method for starting a program at boot time. I also agree that /etc/rc.local should be avoided - this is not so much a matter of opinion as documented fact (see, for example):
The man page for systemd-rc-local-generator states, “Support for /etc/rc.local is provided for compatibility with ...
1
Just wanted to point out a few problems with your script.
First, if you're doing this directly on your root FS, be aware that your backup may have filesystem errors because the FS keeps changing as you make the backup of it. Verify that your backup works!
Second, dd uses a tiny default block size of 512 bytes, so I'm actually surprised you got the ...
1
Some useful commands to get more debug information from the system are:
Have the bluetoothctl tool running in a different terminal when you are running your commands and it may give you more information
More detailed bluetooth information can be found with sudo btmon -t |& tee ~/btmon.log
DBus debug information is available with dbus-monitor --system
Only top voted, non community-wiki answers of a minimum length are eligible
