Posts by jim_p

Yes I am on v0.06 from 23.06.2022

# head get_nightly.sh
#!/bin/sh
#
# Version 0.06
#
# Build Date 23.06.2022
#
# author: JoeAverage
#
# script is under GPL
# means (or likewise): all changes MUST be provided to *ALL* ${OTHER's}

As for the script part, compare all those steps above with something like that

rm get_nightly.sh
wget https://gist.githubusercontent.com/pitsi/e1a47f4b9c8d0176e2c2b8fa2f8fa1da/raw/67d0a404b7b4beeafde457b10b3354b2686eca30/apt.conf -O get_nightly.sh
chmod +x get_nighly.sh

My gist above is for debian's apt (file /etc/apt/apt.conf), but you get the idea. Also, I use nano because I am not comfortable with vi.

And today, besides the above message that the new image is under downgrade, I am getting a low space message

NOT enough disk space to proceed.
I need roughly echo 1092 MB of free disk space !

I have backed up the image of 20220625 for another reason, but the free space I have is enough for it to download

# df -h
Filesystem                Size      Used Available Use% Mounted on
...
/dev/sda2                 1.3G    382.7M    954.1M  29% /storage
...

Its an old 2gb usb stick. I am now moving the foremention image to my pc so that the script runs properly even with the downgrade option.

---edit

I forgot to mention that the upgrade and downgrade options appear properly on the rpi.

Here is a new set of good and bad boot journalctl logs from 20220626

Please excuse the failed logins via ssh. I was too upset

In order for the option that you mention to appear, you have to switch kodi's settings level to "standard" or higher (actually anything but "basic") from the bottom left corner. It's part 3 here

Settings - Official Kodi Wiki

The good news so far.

The wireless on the x64 installation has come up after each boot so far, although I only did 2 with 20220625, and that long text of warnings does not show up anymore in dmesg

I am now waiting for it to upgrade and boot to the 20220626.

About the rpi, it connected wirelessly as it should after the upgrade to 20220626, but let's see how it goes the following days.

----edit

I spoke too soon for the x64. First boot after the upgrade to 20220626 and wireless is down again. I brought it up with "ifconfig wlan0 up" and tried to reconnect with connman, but only to get that "Error /net/connman/technology/wifi: Not supported" error.

Do I downgrade to 20220625 now or do I keep trying and post a new set of pastes for good and bad boots?

I think something is wrong here

your Platform is:        Generic-legacy.x86_64
running nightly is from: 20220625
and has Git Tag:         ccaf8be
+++ nightlies currently available on the download server +++
* for an update:        !!! No updates !!!
* for an downgrade:     LibreELEC-Generic-legacy.x86_64-11.0-nightly-20220626-17f7264.img.gz

I risked though and pressed d to "downgrade" to that nightly, checked that the file was copied in the .update folder, rebooted and the update was done correctly.

p.s. Can you please use a paste service or a gist or even make github repo for the script? It's kinda annoying to copy 400+ lines every time and create a new file when you can just wget it and be ready in 1 second.

Thank you for the heads up. I just upgraded both my rpi and x64 installations to ccaf8be, so let's see what happens.

On today's first boots, before the upgrade, none of the 2 systems connected wirelessly on boot, but I did not try connecting them after the upgrade.

Quote from JoeAverage

P.S.

what image are for RPi3b+ ?

I guess RPi2

Yes, rpi3 uses the le armv7l variant, which in turn is for rpi2. I wish it was aarch64, but le for rpi4 only is aarch64.

I want to add that I tested the script yesterday on the rpi3b+ and it worked as advertised. Unfortunately, there was no new build for generic-legacy, so I could not test it there too. I then deleted it and waited for the fixes

And today that there are new buids for both, the script was removed

Thank you. Those "minimal changes" that you mention give me very little hope to see my issue fixed.

If e.g. the kernel is the same, mesa is the same, xorg is the same, drivers are the same, then it probably won't make any difference.

Let's say I am on le 10 stable (10.0.2 as of today). If I switch that installation to le 10 nightly, will I be able one day to stop being on nightly and switch back to stable once 10.0.3 is released?

When trying to get the paste for the good log, the url was returned after 3 tries. The first time a message like "nothing to paste" or something like that, the second time it got me back to the prompt without any url and the third time it got the url I posted above, which is obviously wrong.

This situation has happened before, when I was trying to paste some relevant logs from the rpi. So, if the default paste service le is using is faulty, please consider switching to a different one.

I will get a new good paste will be in a few minutes, because I am now troubleshooting some nfs share on my system.

---edit

New paste from good boot

http://ix.io/40Bd

Good boot

http://ix.io/3IV8

Bad boot

http://ix.io/40Ae

I had to connect via ethernet so as to ssh to it and do all that. The 2 minutes of waiting that you asked were checked via uptime, because I am no good at timing stuff without a clock

Weird thing of the day is that the first boot was a good one, the second was a bad one and the third was a good one too. I booted for the third time because I wanted to check dmesg about wlan0 and it does say whatever is mentioned above with the warning.

Thank you for the info.

I tested wifi on le 11 x64 a bit more, like so: boot > libreelec settings > connection > check if wireless is (at least) available in there right after boot > reboot and repeat. Out of 10 boots, the wifi was available only in 2 or 3 of them and never twice in a row. The good part on that is that is was also connected those 2-3 times it was available.

Do you want to cast a video from a browser or a mobile device (on the same network) to the pi?

I just noticed that wlan0 is not mentioned anywhere in dmesg of the rpi. Is this logical? I checked on yesterday's and today's nightlies, i.e. before and after the upgrade.

Also, has the nightly for le 10 moved to iwd yet? I may switch my 10.0.2 x64 installation to nightly and check if those dropped frames still happen. I am totally giving up on le 11 on x64 by the end of the month because of that wifi issue.

---edit

In case anyone has any idea, this is the... horror that happens on dmesg when I run ifconfig wlan up to bring up the wifi

[   59.411902] wl 0000:04:00.0 wlan0: Current addr:  00 25 56 b6 4e 4a 00 00 00                                               00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   59.411911] wl 0000:04:00.0 wlan0: Expected addr: 00 00 00 00 00 00 00 00 00                                               00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   59.411915] ------------[ cut here ]------------
[   59.411917] netdevice: wlan0: Incorrect netdev->dev_addr
[   59.411961] WARNING: CPU: 1 PID: 701 at net/core/dev_addr_lists.c:517 dev_add                                              r_check.cold+0x43/0x7d
[   59.411972] Modules linked in: rfcomm bluetooth ecdh_generic ecc 8021q wl(PO)                                               snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio uvcvideo videobuf2_v                                              malloc videobuf2_memops cfg80211 videobuf2_v4l2 videobuf2_common snd_hda_intel v                                              ideodev snd_hda_codec mc snd_hwdep snd_intel_dspcfg snd_hda_core rfkill pkcs8_ke                                              y_parser fuse
[   59.412007] CPU: 1 PID: 701 Comm: ifconfig Tainted: P           O      5.18.5                                               #1
[   59.412012] Hardware name: LENOVO 20023               /KIWA7, BIOS 18CN19WW(V                                              1.05)          05/27/2009
[   59.412014] RIP: 0010:dev_addr_check.cold+0x43/0x7d
[   59.412020] Code: 01 e8 1d ee f3 ff 0f 0b 49 c7 c4 92 6e cc ae 80 3b 00 75 30                                               48 c7 c6 9d 6e cc ae 4c 89 e2 48 c7 c7 50 8b e1 ae e8 f9 ed f3 ff <0f> 0b e9 8b                                               1c d8 ff 49 c7 c4 92 6e cc ae eb d5 4c 8b 24 d5 60 19
[   59.412023] RSP: 0018:ffffb877c0c17c10 EFLAGS: 00010282
[   59.412027] RAX: 0000000000000000 RBX: ffff9fdc032b2000 RCX: 0000000000000027
[   59.412030] RDX: ffff9fdc7d51b428 RSI: 0000000000000001 RDI: ffff9fdc7d51b420
[   59.412033] RBP: ffffb877c0c17c20 R08: ffffffffaf0c4888 R09: 00000000ffffefff
[   59.412035] R10: ffffffffaf0548a0 R11: ffffffffaf0ac8a0 R12: ffffffffaecb464b
[   59.412038] R13: ffffffffc0a30480 R14: 0000000000000001 R15: ffff9fdc032b2000
[   59.412041] FS:  00007fd8bc339740(0000) GS:ffff9fdc7d500000(0000) knlGS:00000                                              00000000000
[   59.412044] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   59.412047] CR2: 0000000000465efb CR3: 000000000c16e000 CR4: 00000000000406a0
[   59.412049] Call Trace:
[   59.412052]  <TASK>
[   59.412055]  __dev_open+0x43/0x1b0
[   59.412062]  __dev_change_flags+0x1a9/0x220
[   59.412066]  dev_change_flags+0x26/0x60
[   59.412070]  devinet_ioctl+0x5fe/0x810
[   59.412075]  inet_ioctl+0x165/0x190
[   59.412079]  ? netdev_name_node_lookup_rcu+0x61/0x70
[   59.412084]  ? dev_get_by_name_rcu+0xe/0x20
[   59.412088]  ? dev_ioctl+0x46c/0x530
[   59.412093]  sock_do_ioctl+0x45/0xf0
[   59.412098]  sock_ioctl+0xef/0x300
[   59.412103]  __x64_sys_ioctl+0x91/0xb0
[   59.412108]  do_syscall_64+0x3b/0x90
[   59.412115]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[   59.412120] RIP: 0033:0x7fd8bc431648
[   59.412123] Code: 00 00 48 8d 44 24 08 48 89 54 24 e0 48 89 44 24 c0 48 8d 44                                               24 d0 48 89 44 24 c8 b8 10 00 00 00 c7 44 24 b8 10 00 00 00 0f 05 <41> 89 c0 3d                                               00 f0 ff ff 77 0e 44 89 c0 c3 66 2e 0f 1f 84 00 00 00
[   59.412126] RSP: 002b:00007ffe792a8d18 EFLAGS: 00000246 ORIG_RAX: 00000000000                                              00010
[   59.412130] RAX: ffffffffffffffda RBX: 00007ffe792a9d8f RCX: 00007fd8bc431648
[   59.412133] RDX: 00007ffe792a8d90 RSI: 0000000000008914 RDI: 0000000000000003
[   59.412136] RBP: 0000000000008914 R08: 0000000000000000 R09: 0000000000000000
[   59.412138] R10: 00007fd8bc34dda0 R11: 0000000000000246 R12: 0000000000461660
[   59.412140] R13: 00007ffe792a8f90 R14: 00007ffe792a8f98 R15: 0000000000000003
[   59.412144]  </TASK>
[   59.412145] ---[ end trace 0000000000000000 ]---

This does not happen on le 10 or 9 on x64 on the same hw.

Another day, another new weird thing comes up. As usual, the rpi did not connect wirelessly on first boot, so I went wired to do today's update.

First, it stopped at like 95% of the download, so I had to cancel it with ctrl+c and continue it with wget's -c parameter and it completed it after a few seconds. This was happening at the start due to poor wireless signal, but why did it happen on wired connection too?

Second, I did the usual connman procedure of connecting it wirelessly, but connman returned no propmt for the key this time, so I thought it connected successfully. But it did not, according to iwconfig and ifconfig, so I tried again and this time I got this new output of the connection being in progress

connmanctl> connect wifi_bxxx_4xxx_managed_psk
Error /net/connman/service/wifi_bxxx_4xxx_managed_psk: In progress

I retried again after like 1 minute but it showed the same, so I let it continue for a couple of minutes, did the procedure again and I was prompted for the key like usual.

Third, once the update was downloaded (and after checking its sum with the same file downloaded on my pc), I issued a reboot. Unlike previous versions where the connection was terminated instantly (especially via ethernet), le 11 takes some to disconnect and putty to report that the connection was terminated. After like 1 minute, putty was still on and returned to the prompt so as to run another command. I then ran dmesg, which showed the usual cec errors that come up when it is not connected to the tv, but nothing more related to the filesystem.

Then I decided to run htop to check if some other process is delaying it, and it said "sh: htop: access denied" (or something like that). Its green led was permanently on, not blinking, so I hesitated to pull the plug. But I pulled the ethernet cable and after like 30 seconds, I finally saw the green led come of and back on again.

Long story short, it booted to the new nightly, I sshed to it, checked dmesg again for filesystem issues, but still no luck. I ran connman again, reconnected to the wireless (it did not ask for the key this time), rebooted, and luckily wireless was active again after the reboot.

That change was done only 1 month ago. 1 month ago I wasn't even using the nightly on the rpi, let alone on x64.

And the issue with that message has appeared very recenty, like 3-4 nighlies ago. Did something else change recently, e.g. the kernel maybe? I am sad, because 11 fixed the framedrops issue that 10 has but introduced that wifi issue. Anyway, I will keep looking.

There you go.

# cat /etc/os-release
NAME="LibreELEC"
VERSION="nightly-20220612-363112b"
ID="libreelec"
VERSION_ID="11.0"
PRETTY_NAME="LibreELEC (community): nightly-20220612-363112b"
HOME_URL="https://libreelec.tv"
BUG_REPORT_URL="https://github.com/LibreELEC/LibreELEC.tv"
BUILD_ID="363112bf677bfc9fe65522bb53e514c005c2c25d"
LIBREELEC_ARCH="RPi2.arm"
LIBREELEC_BUILD="community"
LIBREELEC_PROJECT="RPi"
LIBREELEC_DEVICE="RPi2"