We have a python script, it will live in its own repo soon.
Has this been done? What is the name of this repo?
I would like to create my own custom channel at home but lack a script to create the releases.json file for the given images.
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.
-
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, strippedLibreELEC-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, strippednotice: "no machine" versus "ARM aarch64"
The same is true for these .so files in usr/lib: no machine
-
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:
Code
Display MoreJul 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?
