Posts by TuxOhOlic

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?