Odroid C4/HC4 unpatched kernel

General Discussion
1

Hello friends.

I am running an Odroid HC4 with DietPi as a Nextcloud server (with Nextcloud installed as a snap). I use Adguard home snap as well for ad blocking on my network. Except for Collabora in Nextcloud, everything seems to work and I like my setup very much.

Only problem I see is that the kernel from Armbian is not patched very frequently (only in the time of their new release). Currently there is still 6.6.16 and upstream is 6.6.31, so there are plenty of unfixed, maybe critical, CVEs. Since it is a public-facing server, I feel responsible to look for a solution, because I host it also for other family members.

The official 4.9 kernel from the manufacturer does not support snap and does not work for me. But there is also a Debian (and also Ubuntu) image called Linux Factory maintained by Hardkernel’s kernel maintainer (mr. Tobetter on Odroid forum) that seems to follow upstream kernel, or at least updates more frequently.
Here is the repository: http://ppa.linuxfactory.or.kr/

Did anyone try this kernel with DietPi? Maybe it would be a better solution than the Armbian one. He said on the forum that the kernel is as official as the manufacturer’s one because he maintains both of them.

Thank you for answers in advance and for your amazing work on DietPi! :slightly_smiling_face:

2

You can use Armbian daily builds. Still better then dietpi.

3

I thought I was on DietPi forum, not Armbian :grinning:

Did you mean to test current-meson64 kernel from beta.armbian.com mirrors? Are they “stable” (I mean at least working)?

I have a good working setup that I am happy with and I don’t plan to change the whole OS.

Unfortunately, I have only one production machine, so I can’t test anything like different kernels, therefore I ask here if somebody else tried it.

4

Did anyone try armbian beta current meson64 kernels with any Odroid board? I really don’t know if it is a usable solution or if it usually breaks…
I see that recent (officially released and downloadable) builds of Armbian for Odroid C4/HC4 are indeed based on beta current kernels, I find it interesting.

5

ping @MichaIng

1 Like
6

This is since the Odroid C4 is not officially supported by Armbian, but just in community maintenance. For this, daily builds are done based on latest Armbian build system version. However, I would probably not call it “beta”. As far as I can say, the build system is not more or less stable when the “stable” image and package versions are generated, i.e. those with a version string based on the last announced Armbian release. More important is, that the kernel is based on mainline LTS, which is the case for those images.

I btw built and pushed to our APT repo kernel packages with the same Linux 6.6.31, to solve a reboot issue on Odroid C2. It will be applied to all 64-bit Amlogic SoC SBCs with next DietPi release. If you want to test them:

echo 'deb https://dietpi.com/apt all odroidc4' >> /etc/apt/sources.list.d/dietpi.list
apt update
apt upgrade
7

I switched the Armbian repo to beta. The kernel is updated daily (the image for C4/HC4 is community maintained - weekly, but meson64 kernels are daily because of officially supported Amlogic C2 board).
Everything seems to work, currently it is the newest 6.6.32. I set my board to update weekly via cron job.

Is “your” kernel repo going to be updated regularly? It would be perfect, if it is possible.

Thank you very much for your answer.

8

Yes, this is planned, as well as the removal of the Armbian repo in turn.

But we won’t update it daily, which seems to be a massive R/W overhead :smile:. Of course for beta/testing this makes sense, but not for production. We’ll update it about monthly, or when certain fixes or new features are available with an update. Faster than apt.armbian.com for sure.

2 Likes
9

That sounds great! This is the frequency I expect to be the best for stability/security ratio :v:t2:
Thank you very much.

1 Like
10

Same scam as “Manjaro stable”?

But Armbian team (more people then you) can easily release their work faster then you. They have many more people that are actually already securing stability you sell to your customers, they have automated testing that test at every code change. How can you provide things better without adding nothing?

Dietpi is just an “Armbian community build”.

Armbian images are tested daily & automatically, even its a community build. Dietpi “supports” everything that they once booted Dietpi and fully rely on Armbian.

Good sales man will always tell you what you want to hear. Sounds yes, but its sadly fake. Diepti can’t provide this, but they can surely tell you that. Anyway end user have no ability to notice the difference.

11

@boxer
Can you please stop spreading your constantly repeating blames of our project where it is completely out of topic, including false statements you cannot know, like whether we are or are not able to trigger kernel package builds on a monthly basis and push them to our APT server? We are doing this on daily-weekly basis just now, fixing some little bugs and small enhancements in the Armbian build system, which I am sadly denied to contribute to Armbian, and hence need to carry in an own fork. Not sure whether you are Igor, but you are wasting mine and other readers time and nerves. When you have some constructive criticism, go ahead.

I have no idea why you feel attacked by me (and others) writing facts. I do not know why Armbian has such long release schedules for their non-beta APT repo, they have their reasons, no one can blame them for it. But IMO (while everyone is free to have a different one) it makes sense to do kernel releases (via APT) more regularly, at least when there is time to test the build beforehand. So we’ll do it more regularly. That’s all.

5 Likes
12

I also don’t understand why you are attacking someone for their good work.

Personally I prefer using DietPi, I feel it is really solid, reliable, I had zero issues with boot/reboot, CPU at idle is cooler. When I need something, it just works.

I cannot say this about Armbian where my CPU produces more heat at idle, boot works only manually pressing the boot button on the board (so I cannot set it to reboot automatically), it is not reliable as a server for my use case.

I donated to both projects, because Armbian makes the kernel and I have nothing bad to say about the project (except for the stable kernel not updating when there is a security issue, but it is their decision).

This is my (user) perspective. I am not mad at anyone. I like stable, working and secure things, which for me is DietPi, not Armbian.

2 Likes
13

Sorry for the offtopic, but I am just here for supporting DietPi team, always ready to help people, WITHOUT asking nothing in return.

The first moment I read Armenian forums I hate the mood it had, with people asking for money for resolving bugs… If you don’t like what you do or don’t get paid don’t do it.

@MichaIng when I saw the post of @boxer I think in the same person as you… Unbelievable person.

I didn’t regret if I have to use a 4.x kernel of older full of vulnerabilities than ask for something to armbian.

Loving, supporting, and recommending DietPi since I knew about it.

P.d: English is not my first language…

2 Likes
14

About stability: Where we do use kernel/bootloader built with Armbian build system, it should be the same/similar in both projects. The patches we add are not many (yet) and specific, like fixing reboot on Odroid C2, LEDs on NanoPi NEO, adding some WiFi/BT drivers. We usually use the “current” branch, which is the same for Armbian’s images, i.e. the ones most prominently shown on their download pages. Only in case of RK3588 SoC SBCs we still use the “legacy” branch, while Armbian switched to “vendor” (based on newer Rockchip Linux 6.1 sources) with their primary images. That one however causes some udev-worker loop with constant ~5% CPU load on my Orange Pi 5 and 5 Plus, which is why we did not switch yet. Would make sense for Armbian to know about this, but if I report it, I likely get a page long blame why I dare to report a bug, wasting mine and the author’s time and nerves, so I leave it. Will have a closer look when I find time, but currently busy with issues on some other SBCs.

Since we provide certain (soon all) kernel upgrades, also for major kernel versions, earlier, our users are a larger number of ~early adopters, compared to Armbian where this is the case for freshly flashed images only, until their APT repository gets the update. Since issues can appear with those newer kernel builds, this is by times a stability downside our end. It could be a benefit for both projects, when we collected and analysed these issues as good as we can, and did an as complete bug report as possible, kept investigation, testing etc. So things had a chance to be fixed before being pushed to Armbian’s APT servers. However, due to mentioned attitude towards bug reports from our side (and bug reports in general), this potential benefit is sadly not claimed. We seem to have fundamental different opinions on whether bug reports are important/essential for the health of a project, or seen as a waste of time for developers only. And I am even on the Armbian GitHub orga blacklist, preventing me from contributing fixes for those solved within our community. I am drifting off …

With what we do in userland, can rarely ever have any impact on device stability: Default CPU governor schedutil vs ondemand (again) on Armbian + they do some IRQ affinity tweaks which, as far as I read into it, have no practical benefit on modern Linux anymore, but do not hurt either. But these are minor performance tweaks, which should only indirectly be able to affect device stability, respectively should not be able to cause instabilities, if the system otherwise runs within sane parameters, with good PSU, quality SD card etc.

This is exactly what I would suggest :+1:, and how I do suggest on vendor forums. I actually want to make this more prominent on our download page. Something like “Kernel/bootloader powered by Armbian”, with a link to their donation page. Same for other such cases, like Fishwaldo for Star64 device tree and some drivers.

3 Likes
15

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.