Posts by TuxOhOlic

chewitt : This didn't work, what did work is add the missing symlink from /storage/.config/journald.conf.d > /etc/systemd/journald.conf.d/ to SYSTEM and repackage it.

Now the uart logs look better with tetiennes last image (attached here). You also get better logs of the shutdown process. Why isn't "ForwardToConsole=yes" and "TTYPath=/dev/ttySAC2" an active default in journald.conf? It don't think it matters if journald writes there if now uart is attached and extlinux.conf always contains "systemd.debug_shell=ttySAC2 console=ttySAC2,115200n8" anyways.

tetienne : the playback framerate does look somewhat reduced with 5e48165, can you confirm frame drops as well with 1080p50 content?

well done, tetienne, they both run fine and load kodi alpha with network and sound. I'll test the images and my addons some more over the holidays. Here are the uart logs, who still look somewhat incomplete to me after "Run /init as init process". There should be more output. With debian images uart logs look normal, I tested this yesterday. I can't really tell why that is because the relevant boot parameters are similar. systemd-journald has other options in debian, that is one thing i noticed comparing with LE journald. If somebody knows how I can change this without modifying the SYSTEM squash file I'd like to know how this is done.

tetienne: attached is the log for Exynos.arm-13.0-devel-20251220102805-5cc8ee3-odroid-xu4. Your image does boot into a terminal, does hand out an ip and start ssh, but the display stays blank with no signal. I'm still missing debug switches for systemd. The logs do seem to swallow up a lot of content and then just open the ttySAC2 terminal. I have no clue what this is about, but I will test uart against Armbian or my own Debian images I use with the xu4.

it's the same parameters that work fine in 0725. I would like to increase systemd verbosity if that is possible. Parameter order should not matter in extlinux.conf. I do set up screen with the same baudrate of 115200, and that should be all if it works fine in 0725.

"ssh" parameter does not work. I can't ping the host, because the image is not asking for an ip so it is not getting one. Can I set additional debug switches in extlinux.conf? The ones I use are "systemd.debug_shell=ttySAC2 console=ttySAC2,115200n8 console=tty0"

chewitt: you're right it works curiosity made me test it right now, so here are 2 uart logs from 07.25 (the last one booting) and 12.19 from today. Interesting enough you can see 12.19 loading the kernel without a panic or trace, but it is stuck later and is not getting an ip. Blue led keeps blinking, no display.

tetienne: if you want me to test some of your sdhc images please post a link to your raw image. I'll then send you the uart log as well.

I tried this twice and it failed both times. The uart adapters I used are cheap ones like I use for connecting to rpi uarts, they work fine there. I might test one more time over the holidays, maybe it does work with just rx+tx+gnd. If so I would post uart logs in here of a recent testserver image.

chewitt: can you compare your item with the one from hardkernel [link] ?

I spot 2 differences:

1. Molex5268-04 connector goes to the xu4 board [I would have to solder it or find the bare connector plug and crimp it.]
2. CP2102N: USB to Serial UART bridge IC with 1.8~3.3V interface [lower voltage than what amazon offers]

The old uart kit might work with the xu4, but it is discontinued.

lack of the odroid xu4 uart kit is my main issue as well, otherwise i'd like to help test and debug this. The kit is 10$ + a whopping 20$ of shipping fees when you order it in Europe from the hardkernel shop. My budet stops at 20$ for sth like this, shipping fees included

no, can't even ping the device, so the router did not hand out an ip to conman. Can I just use the previous kernel from 07.25 with it's dtb file and check against a current system squash file?

I guess I'm one of the few who occasionally test new nightly images for the xu4, so starting with LibreELEC-Exynos.arm-13.0-nightly-20250730-ecfa284-odroid-xu4 the testserver images no longer boot. The blue led is blinking, but the display stays blank.

Can somebody with an xu4 uart cable check what is happening? This seems to be present in all images I checked since then.

So last one working is LibreELEC-Exynos.arm-13.0-nightly-20250725-f0482de-odroid-xu4. I noticed 4 consecutive missed daily builds in that timespan, could this be related?

@ghostofsparta Those quick freeze annoyances have nothing to do with wireless or wired connection, but with holding the storage folder on a network share per se: I can observe them as well as soon as I create the storage disk on a nfs share. I connect the rpi3b with gigabit wired lan.

Try it for yourself if you happen to own a sata to usb converter and connect it with a usb 2.0 port of your rpi3b: put the same storage content into a ext4 partition and switch cmdline.txt with disk=/dev/sdaX to the drive. Symptoms should go away already by now, if not switch boot=/dev/sdaY as well to a 2nd drive partition: it needs to hold just the squash file called SYSTEM, it can be ext4 as well.

Interestingly enough this only affects the rpi2 images and not x86_64 Generic which I'm completely (PXE-) booting from my NAS. I purchased the rpi4b for Christmas. It works quick and flawless on a usb 3.0 connected drive. I' will test it as well with the same storage folder put on nfs, maybe those freeze ups when I change to Home will reappear again. Will keep you posted.

Could the cifs.ko become part of to the testing images? I'd like to use a systemd-mount service with additional mount parameters.

unix extensions should work fine if you grade down max protocol version from 3.0 to 1.0 on the client side. You can select that inside the services menu - chose the smb client register and switch max protocol from smbv3 (or none) to max smbv1.

Hello my fellow LibreELECtrions,

I've been successfully using LE for more than two years on my laptop and the raspberry pi 3 without much hassle ... it just works and is well documented here in the forum and the wiki.

So it came down to me trying something new during the Covid lockdown, like nfs boot the raspberry - mainly to lighten the sdhc card write load, thus save some of the card's lifespan.

Thanks to the nfs boot wiki I manged to migrate disk and boot to my NAS. It now boots almost as well as it did before when I ran things from the card - except that I'm no longer using the network-online.target of systemd anymore (for obvious reasons I guess - my ip is assigned with dhcp right at the top of the netboot process).

But without that service the cifs filesystem has vanished from /proc/filesystems along with smb3. So my nifty systemd storage-dvds.mount job no longer works, as it can't mount a filesystem the kernel knows nothing about. I thought I could modprobe the module as usual, but apparently it's not to be found, as a quick modinfo cifs states.

So here's where I'm stuck at the moment. I can use the kodi cifs client successfully, but it lacks a cifs mount option I preferably use (nomapposix).

Anybody can pitch in here and explain, how to get the cifs+smb3 module up and running again with network boot?