Posts by jim_p

  • Adding boot parameters to the rpi (and any arm build probably)

    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

    Code
    Agent 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).

  • shell script to get the latest nightly (old)

    Yes I am on v0.06 from 23.06.2022

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

    Code
    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

    Code
    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

    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.

  • Adding boot parameters to the rpi (and any arm build probably)

    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?

  • shell script to get the latest nightly (old)

    I think something is wrong here :P

    Code
    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.

  • Adding boot parameters to the rpi (and any arm build probably)

    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

  • Adding boot parameters to the rpi (and any arm build probably)

    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 :P

    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.

  • Adding boot parameters to the rpi (and any arm build probably)

    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.

  • Adding boot parameters to the rpi (and any arm build probably)

    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

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

  • Adding boot parameters to the rpi (and any arm build probably)

    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

    Code
    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.

  • Adding boot parameters to the rpi (and any arm build probably)

    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.