This weekend I discovered the dtb for my X96 Air Q1000 doesn’t work at all with the latest linux-vim3 kernel and there is a HDMI issue with the latest linux-aml kernel where the screen is all faded, regardless of the dtb I use.
I know how to build kernels from the the git repos but that takes several hours so it would be great if there was an archive of the Manjaro ARM kernel and kernel headers packages for these situations.
There is already an archive of old ALARM packages here:
So if the Manjaro ARM project don’t have a suitable server to host these then I suspect the admin of that site might be up for helping out. Their email is on the homepage:
This is very old. It is split in linux-odroid > using Tobetter branch. linux-khadas > using khadas patches.
We have had this discussion before with Manjaro Team and it turned out that it would need a lot of storage and then we couldn’t find the right host for that.
Maybe I will try to pick this topic in the group again.
Ah OK, I didn’t notice vim3 had been replaced by linux-khadas/odroid.
I’ve not tried the odroid kernel yet so maybe I’ll have better luck with that or is that kernel really only for genuine odroid devices?
It seems the person running the Arch ARM package archive has a lot of storage space. It has been running for about 6 years now, according to the ALARM forums. I presume they won’t have an objection to storing your kernel packages too if you make it easy for them to download / sync them and its the logical place to find them unless Manjaro ARM gets its own storage sorted. I suppose it might make sense to break it out into a manjaro sub dir because its not vanilla ALARM, if they are up for helping.
Our current kernels can always be downloaded/synced from our repository, so it’s just a matter of choosing a mirror to sync them from.
We don’t have any older kernel packages, as we are a rolling distribution. So installing/keeping an older kernel, while updating the rest of the system, is not supported, as it generates a “partial upgrade” scenario. So using such packages is at your own risk.
I get your point about Manjaro being rolling but the land of dodgy TV boxes that don’t have proper mainline support get broken on a regular basis and so we need to exploit pacman.conf’s IgnorePkg feature if we want to have a (mostly) working kernel. I may be stuck on 5.12 with my TV box but thats fine by me. I doubt later kernels have any new features I need and security isn’t a concern for my TV box, I’d much rather have my hardware work.
Well, other packages might need such a feature. Example, the recent split of the linux-firmware package requires (as Arch states it) a specific kernel config option to be set, which we did not have previously. Now I don’t know exactly what happens if the option is not set when using this new firmware package. Maybe the firmware just does not get loaded at all.
Not being able to pin kernel versions is a problem, not just for TV boxes. There should be some accommodation for not upgrading your kernel. For example, amd64 users need to do this when NVIDIA don’t update their drivers (fast enough). That is just one non TV box specific example of why using older kernels is required.