Posts by misanthropos

Solved!

With help from #gentoo-arm.

There were binutils backports from 2.45 to 2.44 which seemed to have been the culprit which is fixed in latest binutils-2.44-r4 in gentoo.

see: drop LTO strip patch from 2.44

Dissecting the SYSTEM file from a broken and a working .tar file reveals:

file usr/lib/systemd/systemd

LibreELEC-RPi4.aarch64-13.0-devel-20250803115117-88c8e3c
systemd: ELF 64-bit LSB executable, no machine, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 6.12.0, stripped

LibreELEC-RPi4.aarch64-13.0-devel-20250628054217-b3719f8
systemd: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 6.12.0, stripped

notice: "no machine" versus "ARM aarch64"

The same is true for these .so files in usr/lib: no  machine

Quote from chewitt

Full clean build? .. or you pulled changes and just did a respin?

I did full clean builds lately after a respin failed.

Trying to boot the system it prints following lines:

switch_root: can't  execute '/usr/lib/systemd/systemd': Exec format error

request_module: modprobe binfmt-464c cannto be processed

HiassofT That did the trick!

The image you supplied worked as fresh installation as well as an upgrade for my system.

Sorry this one is the working log with FullHD tv: https://bpa.st/5CBQ

Some more observations:

Using LibreELEC-RPi4.aarch64-13.0-nightly-20250725-f0482de.img.gz on an RPi4 2GB with FullHD TV it installed on the SD card and showed a picture. It works. It will show a black screen after installation if connected to an UltraHD TV and no internet connection.

Going back to the FullHD TV it just works.

Same behaviour with my home installation: it works if connected to a FullHD TV but wont if connected to UltraHD. I have tried it on a 2GB and 8GB RPi4 - they show the same behaviour.

This is a log from my home installation connected to UltraHD TV: https://bpa.st/HINQ

This log comes from the same installation connected to FullHD TV: https://bpa.st/HINQ

I can confirm:

LibreELEC-RPi4.aarch64-13.0-nightly-20250725-f0482de.img.gz 

renders the system unusable. The screen stays black.

I have had problems lately building from LibreELEC.tv git master repo for an RPi4. It will generate a .tar file but after upgrading it would not be able to boot but would tell me it could not load the system (sorry, I did not make picture). Until now I thought it could be related to the OS I am using (Gentoo Linux).

see: https://cant-create-working-upgrade-tar-file-for-rpi4-with-gentoo-linux

This may be gentoo related and I can not figure out what is going wrong:

The Bildsystem with PROJECT=RPi DEVICE=RPi4 ARCH=aach64 make runs through but the resulting binary wont boot.

A journalctl reaveals it is spamming lines like this:

Jul 17 13:58:26 amd systemd[1]: Created slice Slice /system/systemd-coredump.
Jul 17 13:58:26 amd systemd[1]: Started Process Core Dump (PID 25228/UID 0).
Jul 17 13:58:26 amd systemd-coredump[25229]: [🡕] Process 25227 (conftest) of user 1000 dumped core.
                                             
                                             Module /local/src/LibreELEC.tv/build.LibreELEC-RPi4.aarch64-13.0-devel/build/bison-3.8.2/.x86_64-pc-linux-gnu/conftest without build-id.
                                             Module ld-linux-x86-64.so.2 without build-id.
                                             Module libc.so.6 without build-id.
                                             Stack trace of thread 25227:
                                             #0  0x00007f069053adbc n/a (libc.so.6 + 0x95dbc)
                                             #1  0x00007f06904e28e6 raise (libc.so.6 + 0x3d8e6)
                                             #2  0x00007f06904ca34b abort (libc.so.6 + 0x2534b)
                                             #3  0x00007f06904cb516 n/a (libc.so.6 + 0x26516)
                                             #4  0x00007f069052e70b __libc_fatal (libc.so.6 + 0x8970b)
                                             #5  0x00007f0690508e23 n/a (libc.so.6 + 0x63e23)
                                             #6  0x00007f06905264f3 n/a (libc.so.6 + 0x814f3)
                                             #7  0x00007f06905c7fb9 __sprintf_chk (libc.so.6 + 0x122fb9)
                                             #8  0x00005618d71e00e1 main (/local/src/LibreELEC.tv/build.LibreELEC-RPi4.aarch64-13.0-devel/build/bison-3.8.2/.x86_64-pc-linux-gnu/conftest + 0x10e1)
                                             #9  0x00007f06904cc4ae n/a (libc.so.6 + 0x274ae)
                                             #10 0x00007f06904cc569 __libc_start_main (libc.so.6 + 0x27569)
                                             #11 0x00005618d71e0155 _start (/local/src/LibreELEC.tv/build.LibreELEC-RPi4.aarch64-13.0-devel/build/bison-3.8.2/.x86_64-pc-linux-gnu/conftest + 0x1155)
                                             ELF object binary architecture: AMD x86-64
Jul 17 13:58:26 amd systemd[1]: [email protected]: Deactivated successfully.

It looks like the compiler produces x86-64 code or tries linking the x86-64 libc.so.6 Does someone have an idea how to fix this?

I have setup my media server to export e.g. series via nfs with options: rw,root_squash,anonuid=xxxx,anongid=yyyy

my client (LibreELEC) is mounting that share on demand (not permanently mounted) and when downloading a subtitle the file is generated alongside its counterpart video file but no accessible and with a size of 0 bytes.

its permissons are set to ----------.

So how and where can I set default permissions for nfs mounts?

Cross compiling for an RPi4 with PROJECT=RPi DEVICE=RPi4 ARCH=aarch64

results with collect2 complaining not being able to find ld.

Checking LD_FLAGS it contains fuse-ld=gold which is not supported anymore because its development has gone silent according to gentoo developers.

I did not find the line where gold is set as LD standard, but in config/optimize I changed

LDFLAGS_OPTIM_LINKER_GOLD="-fuse-ld=lld"

or commented it - both approaches do work for me.

Maybe we could add lld as a possible linker to use.

I would do it myself, but where is the default linker defined?