IPFire 2.27 (armv6l) - Core Update 159 has been running quite nicely on my raspberry pi 3B, so I decided to test how well the aarch64 image would work.
With the HDMI + keyboard working properly, the CLI program “setup” could be run to get the network interfaces configured. Pings to other computers on the LAN were successful, but access from other computers to the IPFire web GUI failed – Firefox came back with PR_CONNECT_RESET_ERROR.
/var/log/httpd/error_log is full of entries:
[Mon Aug 09 00:47:31.853708 2021] [core:notice] [pid 1944:tid 548093470464] AH00052: child pid 2085 exit signal Abort (6)
libgcc_s.so.1 must be installed for pthread_cancel to work
Why does IPFire imply that libgcc_s.so.1 is not installed in my system?
/usr/lib/libgcc_s.so.1 exists and has permissions 644:
$ ls -l usr/lib/libgcc_s.so.1
-rw-r–r–. 1 root root 456080 Aug 9 00:27 usr/lib/libgcc_s.so.1
/usr and /usr/lib appear to have the appropriate permissions:
$ ls -dl usr
drwxr-xr-x. 10 root root 4096 Aug 9 02:32 usr
$ ls -dl usr/lib
drwxr-xr-x. 40 root root 20480 Aug 9 02:32 usr/lib
After reading this thread I checked for directories that have permissions 700:
$find -type d -perm 700
/lost+found
/var/ipfire/ovpn/certs
/var/db/sudo/lectured
/var/lib/sasl
/opt/pakfire/etc/.gnupg
During an update, the web interface goes unresponsive. That is not my issue. I’m doing a clean, fresh install of the image.
The “permission 700” issue is that some directories in the update are 700 and need to be 755. For the fresh install I did, aren’t the relevant directories 755 (namely /usr and /usr/lib)?
Success! The culprit was inappropriate permissions for the root directory (i.e. /).
In order to not wear out the SD card, I had put the root file system on an external USB SSD. When preparing the empty ext4 file system, the permissions for the root directory were set to 700 with the owner and owner group set to the sudoer I was using at the time (not root).
When I set the permissions to 755 and user/group to root/root, the web GUI worked.