Revert "MKS-Klipad50: Switch to standard support" #7883
Conversation
This reverts commit 4bddce9. Standard support turned out to be too complicated for me.
github-actions
bot
added
size/small
In what sense? This is still a grey zone. You are not obligated to do hard lifting or resolve bugs. If device generally works well and most of general rules apply - try at least until next release and then decide? |
|
I was panicking. :) After the change from .csc to .conf, only the nightly trixie/jammy images got created and apt.armbian.com did not receive any packages (though beta.armbian.com still does). I misassumed that stable images would have been generated earlier. But now it sounds, as if that setup is correct and sufficient, i.e. a stable image and packages on apt.armbian.com will follow in 05/25 (or if there is any earlier release). That would be perfectly fine. You are right, I'll drop this PR and wait for the next release. Thanks for the clarification. |
|
No worries.
Let me clarify this better. Stable images are done manually, one by one, even we have automation "build them all" as some families have either known serious problems or they weren't been finished by the release date. Its a quality control feature - better old images then broken new ones. We can't hold back others ... so I think its better to release majority and release the rest once ready. This is happening right now, today, tomorrow. Its a lot of manual work, first by fixing and then releasing / testing. This includes several people, who we all have some life happening in between. I had to spent few days with my family as otherwise I risk serious problems of different kind ;) Backup is, but not for all roles and tasks ... Since most targets got major kernel upgrade, where troubles are more then expected, we are holding back populating apt repository with all packages. Selecting here is much more difficult as kernel is common for many boards. Luckily we don't have one kernel, so we can hold back Rockchip, but release Allwinner ... but that only adds additional manual work and risk of added bugs in the process due to manual work.
When images are pushed to the download servers, index on download pages is updated automatically, but not the status itself - supported / csc ... This also slightly defines how images are displayed. What we are looking here is a script that would adjust wordpress database with changes on Git. As this is the source of truth. This still has to be switched by hand. If board was previously .csc, it will have community supported targets in the download pages until next recompilation (happens weekly, sometimes not due to compilation issues and has to be fixed and run again), after changed to .conf. .conf is getting daily images and daily repo, but not community ... Perhaps too many complications.
Yes, everything should show up properly within a week. If not, then something could be wrong somewhere and you open a ticket, ping me, ... |
|
Many thanks for that detailed explanation. Getting the whole picture from reading the docs and the workflow galore is a bit demanding for me, being new to this project. |
Great! I know its overwhelming for anyone that wants to jump in the loop. We try our best. Stable images (.conf) - you can prepare them on your own and tell me, when they are tested, to move to download folder. You have rights (once you accept invitation to join .org) for that and here is most of related documentation - https://docs.armbian.com/Process_CI/ When you manage. |
|
Strange: The noble-minimal image goes into bootloop, kernel runs into "Synchronous abort" handler directly after u-boot starts the kernel. It has something to do with the initrd - if I replace it with the initrd from noble-server, it boots up OK. I'll investigate that further, but I wonder if this really only affects the mks-klipad50? Edit: Both other images (bookworm-minimal and noble-server) work fine. |
|
This is strange, hug. Check CI build logs if there is anything odd, like qemu crash. Images were assembled on x86 machine - we can force them to use aarch64 runners ... Build logs for broken image: Build logs for OKish Noble server:
We need to find that out. |
|
Nothing obvious - this was build from trunk and there are some commits after release that could make some troubles. I would propose quick workaround - removing broken image (in progress) - until we find out why it broke. |
|
No need to hurry. |
|
A working uInitrd (without bootloop) gets generated after installing "fuse3".
A locally built noble-minimal from 25.05-trunk (today morning) has no problems booting - but also has no fuse3 installed.
|
|
Not nailed it down yet, current test status for the record (in addition to my prior post):
That happens when u-boot loads initramfs into EFI memory region (that should have been fixed in later versions): https://lore.kernel.org/all/d3f3fc7f-b29a-4503-9fe0-97468bbe1f71@gmx.de/ So maybe that illegal free leads to execution of some random code, which in case of installed fuse3 just happens to take a non-fatal pathway (out of sheer luck)? My other assumption is that this is caused by some bug in an upstream package. Are other boards affected? Probably not, but unsure:
|
|
After rerunning the workflow: That's not my idea of a "stable" release. I'll continue search. |
@paolosabatino Have you experienced this on similar Rockchip RK3328 boards?
To me it looks isolated to Rockchip family, could be to this SoC. It would be more reports, if this would be present wider. |
Fixes loading initramfs into EFI memory region, leading to errors "efi_free_pool: illegal free". Which may be the cause for bootloops: armbian#7883 (comment) See also: https://lore.kernel.org/all/d3f3fc7f-b29a-4503-9fe0-97468bbe1f71@gmx.de/
|
@redrathnure The latest community build (trunk.185) for MKS-PI bookworm-minimal from https://github.com/armbian/community/releases/tag/25.5.0-trunk.185 also runs into the same bootloop on my MKS-Klipad50. I am suspecting that this is caused by u-boot-2022.07 (that is "patch/u-boot/u-boot-rockchip64") loading the initramfs into the EFI address space (see here). Which usually leads to this output at boot: Can you confirm
In case of a bootloop, this will be the output (with varying amounts of EFI errors): I am currently preparing a patch to switch mksklipad50 to u-boot v2025.01 (needs testing and a bit of cleanup/squeezing before PR, but you can get the picture), hoping that this will fix the reboots. Edit: Reworked patch/PR: #7922 |
Fixes loading initramfs into EFI memory region, leading to errors "efi_free_pool: illegal free". Which may be the cause for these bootloops: armbian#7883 (comment) See also: https://lore.kernel.org/all/d3f3fc7f-b29a-4503-9fe0-97468bbe1f71@gmx.de/
|
Will test it during weekends |
|
@torte71 A test on MKSPI + armbian/v25.02 based image, hash: b1ac026, date 2025.02.07, hope it's old enough for the discussion: IMO:
~~Will try to flash latest builds and will drop updates here... ~~ |
Absolutely! And actually, the bootloop doesn't depend on the distro: The first time I noticed it, noble-minimal was affected but debian-minimal ran fine. Then I triggered a rebuild (without having changed any of the klipad related files) and suddenly debian-minimal was affected but noble-minimal was fine. Not less weird is, that by adding fuse3 to initrd, the bootloop could be fixed, though none of the initrd contents show any kind of dependency on fuse3 (and esp. none of the "init" script contents, that are executed before checking "break=top" parameter). In my understanding, this bootloop can only be triggered in/by u-boot (opposed to kernel or initrd):
Double free()s have the potential to allow "random" code execution under certain conditions (and are used for various exploits). So I hope, that by switching to recent u-boot, which claims that the "illegal free" got fixed (hopefully not by just removing the printf() statement), this can be solved. |
Fixes loading initramfs into EFI memory region, leading to errors "efi_free_pool: illegal free". Which may be the cause for these bootloops: armbian#7883 (comment) See also: https://lore.kernel.org/all/d3f3fc7f-b29a-4503-9fe0-97468bbe1f71@gmx.de/
This reverts commit 4bddce9.
Standard support turned out to be too complicated for me.