Posts by jim_p
-
-
You are one level ABOVE any menu that shows the "settings level" on the bottom left corner. Click e.g. on system and you will find it.
-
A difficult day started for the rpi. After 2 days of wirelessly connecting with no issues, I had to go wired today for the upgrade.
I started downloading the 20220627 nightly and minimised putty's window. On my tiny 12Mbps connection, it takes ~100 seconds to download the ~1`20MB image for the rpi, so I let it run. I checked it again a few minutes later and it had frozen at ~50% of the way!
I closed that connection, I sshed to it again from a new instance of putty, killed wget, for which I have no idea why was it still running, deleted the existing file just in case, downloaded the file again and rebooted when it was done.
When the rpi boots, I usually wait for the green light to stop blinking before connecting via ssh, but this time it was lit up for 5+ (if not 10+) minutes straight, with no or minimal blinking! I sshed to it to run htop or something, but it came up again with the access denied error (like I said in message 53). Instead of unplugging the ethernet cable like last time, I decided to schedule a shutdown in the next 15-20 minutes with "shutdown -P 8:30".
The green light turned off ~1 minute after I gave the command and at that time the system already at least 10+ minutes of uptime according to uptime (and uptime -s).
I checked dmesg for anything weird, like ext4 corruption, but the only notable thing was that message about cec timeout. I then powered it off. I then started it again (cold boot) and tried to finally connect to the wireless via connman, but I got this... new behavior on the first try
CodeAgent ReportError wifi_bxxx_4xxx_managed_psk invalid-key Error /net/connman/service/wifi_bxxx_4xxx_managed_psk: Input/output error Agent request cancelled by ConnMan
but it connected as usual on the second try, asking for the key again (as usual).
-
Yes I am on v0.06 from 23.06.2022
Code
Display More# 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
Coderm 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
I have backed up the image of 20220625 for another reason, but the free space I have is enough for it to download
Code# 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
-
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
Codeyour 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.
-
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
-
Good boot
Bad boot
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
Code
Display More[ 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.