You need to force recovery boot again. This forces vendor u-boot to search for bootscripts that configure it to look for the boot files that AMLGX uses, which are not the same as legacy images. If you don't, vendor u-boot is looking for files that don't exist and (as you found) boot will fail.
Posts by chewitt
-
-
I've merged CI changes so LE13 nightlies should commence in the next 24-48h. There's a probability of boot issues with RK3576 as the Rock4D that I have boots and runs great .. for 30 seconds .. then the board stops responding.
There's also a Rock 3C gathering dust that needs to go into the test rotation so I can look for issues.
I'm not aware of any other issues, but ignorance is bliss
-
The most likely candidate would be the kernel bump to 6.16.7, as other changes in the timeframe are either graphics packages or support for various ARM SoC hardware platforms, not x86_64.
-
First step is to revert to Estuary and confirm whether it's a skin issue or something in Kodi core itself. Second is to report the issue to the correct location, either the AZ skin developer(s) or Team Kodi, as LE is not patching/modying profile behaviour in any way.
-
-
il5algo the AMLGX image mounts filesystems using GUIDs not /dev/device references so have you changed the boot params in uEnv.ini? - What distro was installed before?
-
Most streaming service "geo" blocking also includes the ASN ranges of known hosting providers, so if some VPN provider operates their London infrastructure from well known London hosting centres (or simply their ASN's are known) then their IP ranges will be blocked.
-
Only Libreelec 13 with conman/iwd.
Go repeat the experiment with RPiOS on the same hardware.
-
Look at the systemd journal and kodi.log. One of them should have clues.
-
This is more likely to be a Kodi (software) issue not an LE (packaging of software) issue; but some ideas in no particular order:
* Go backwards in time with nightlies and pinpoint the first date when the issue appears. We can then look at what packages changed on that date. I'll guess that the main package bump will be 'Kodi' .. but then we can look at what changed between the previous Kodi version (tracked through githash) and you can start a conversation with Kodi developers around that.
* Switch to the default skin. If the issues go away, it's either an issue with Arctic Fuse2 skin itself (something to take up with the skin developers) or the skin triggers a rendering problem (something for Kodi developers). If the issue remains; it wasn't the skin.
* You have a large number of add-ons installed. Switch to a clean environment (stop Kodi, rename /storage/.kodi to /storage/.kodi-old and restart) and then start to add back add-ons until you find the one(s) which trip the problem.
-
This is a TV underscan problem and not an HTPC hardware or software problem.
HDMI ports are not always equal. If the TV has other ports, move the cable around and see if any of them work better? See if any are configured for 'PC' use and if possible set them to 'normal' (or some other) mode. You can also see if changing the default desktop resolution from 1080@60 to 1080@50 in case this generates a better outcome?
The option of last resort is to 'calibrate' the output via Kodi settings > System > Display > Calibration. It's the worst option because unlike a CRT tube where calibration mechanically adjusts the spread of the electron beam to better fit the screen, this change is digital and done in software. Calibration forces Kodi to squee``ze e.g. 1920 x1080 pixels into 1900 x1060, with the remaining pixels to make up 1920 x 1080 rendered black. It's a lossy process and 'squeezing' the image can lead to other visual artefacts in playback.
-
No worries. We're just happy it's not an actual bug
-
If you have a repeatable way to recreate the issue please file a detailed bug/issue report on the Kodi GitHub repo.
-
Then nothing is probed and visible to the kernel; hence GUIDS cannot be found and boot failed.
Have a look in dmesg. If you want us to comment, copy/paste the entire log to pastebin.
-
It's a minimal environment so there's nothing other than what's needed to run the init script. See if blkid is there?
-
I've dropped the patch and pushed an updated 'box' image (and .tar) to my share. Can you test and confirm this (with the right dts file) then works the same as your own image?
-
Connect a USB keyboard when it drops to the initramfs debug shell and you can run console commands and poke around. Check the system log for error messages. See if you can manually mount the required boot/disk partitions and then run "boot" to continue. It has failed for a reason ..
-
boot=UUID=1308-5505 disk=UUID=539ccadb-0a89-4cf5-92a9-d7e45e11fe1b quiet console=tty0,ssh
None of the other boot params are comma separated, and my instruction doesn't include one, so why have you added one?
