search

armbian / build

Armbian Linux build framework generates custom Debian or Ubuntu image for x86, aarch64, riscv64 & armhf
https://www.armbian.com
GNU General Public License v2.0
4.28k stars 2.34k forks source link

[Task / Story]: Clean up old kernels/kernel patch leftovers #6821

Closed ColorfulRhino closed 4 months ago

ColorfulRhino commented 4 months ago

Task description

This is part of https://github.com/armbian/build/issues/6820

The goal is to remove 1) deprecated/unused kernels from the code 2) kernel patch folder of kernels which are not used anymore (just forgotten to delete in the past)

Please add leftovers if you know of any. Feel free to discuss and improve :) Please correct me if I do wrong assumptions. I am not familiar with all the families.

Remove kernel patch folders of unused kernels:

Remove unused kernels:

github-actions[bot] commented 4 months ago

Jira ticket: AR-2392

rpardini commented 4 months ago

Nice initiative. I guess it's time to let those go. (I was personally attached to 5.10 meson64 as it took years for 6.x to reach the same level).

igorpecovnik commented 4 months ago

What's up with s5p6818? It's stuck on ancient Linux 4.14

Yes, unfortunately and u-boot is not build-able anymore. Full remove?

ColorfulRhino commented 4 months ago

Yes, unfortunately and u-boot is not build-able anymore. Full remove?

I was first thinking keeping it is better since this family has no other kernel than legacy. But the family has not seen any meaningful activity in 4 years and there are only 4 boards using this family (all NanoPi/NanoPC), without any maintainer.

So after seeing this information, I vote for dropping. especially if it doesn't even build.

I guess in that case we remove the boards as well? They're all just 9 lines of code, nothing worth keeping even in case someone wants to bring this back with an update.

Edit: Also there's mt7623 which has only legacy 4.19 kernel (no current or edge) and is only used for one board without a maintainer. What to do with that?

ColorfulRhino commented 4 months ago

Also I've discovered that the kernel family rockpis (which is only used by 1 board) is still on even more ancient Linux 4.4. How should we proceed with that one? The board config doesn't even enable legacy so it's just dead code.

As proposed in the forums, it could simply be integrated into rockchip64: https://forum.armbian.com/topic/32916-ideas-on-how-to-make-soc-family-patches-more-manageable/ So the family is fully integrated.

@brentr would you like to do this yourself and move stuff from the family config that is still relevant?

For setting a fixed MAC we have also this btw, maybe it can help: https://github.com/armbian/build/blob/ffe83ab5e87cf59d8fb03cb38542c60b5b1c384b/packages/bsp/common/usr/lib/armbian/armbian-common#L38

brentr commented 4 months ago

@ColorfulRhino I agree that the 4.4 Kernel support for RockPI-S can be removed. As for "moving stuff", what stuff in particular? Examples of similar situations would help. Setting different, random MAC addresses on every reboot makes assigning the same IP address to the interface via DHCP very difficult. For headless IOT devices, assigning them fixed IP addresses ensures that port forwarding rules can always reach them behind NAT routers. Do you know of a cleaner way to assign unchanging MACs to boards that lack dedicated EEPROMs for them?

I don't have access to hardware to test until September. (traveling) I'd suggest that you remove the Legacy 4.4 kernel support now and I will "move stuff" out of the RockPI-S family in September, after I can test again.

ColorfulRhino commented 4 months ago

@brentr Thanks for your reply!

As for "moving stuff", what stuff in particular? Examples of similar situations would help.

Apologies, I should have been more precise. By integrating the rockpis "family" (rock-s0 family is also a candidate) into rockchip64, all stuff that is specific to the board can be moved to the board config and other stuff that may be beneficial for all rockchip64 devices could be moved into the rockchip64 family config. Things that are a legacy or workarounds from the past and are not needed anymore can be dropped.

Setting different, random MAC addresses on every reboot makes assigning the same IP address to the interface via DHCP very difficult.

The set_fixed_mac() function can be run in armbian_firstrun for specific boards and will assign a fixed mac to all ethernet interfaces if called, via declarative config (Netplan). Wifi interfaces are not yet implemented for this, feel free to tackle that if you like the function :) This was just meant as a reminder that this functionality is present in Armbian, since we recently updated this function a bit. Of course you can also use the board specific bsp to solve this.

I'd suggest that you remove the Legacy 4.4 kernel support now and I will "move stuff" out of the RockPI-S family in September, after I can test again.

Alright, I'll see what I can do and let the other stuff for you to work on in September 👍

ColorfulRhino commented 4 months ago

There is now only mt7623 left in the list. It has only legacy 4.19 kernel (no current or edge) and is only used for one board without a maintainer. I don't have much insight into this kernel/board though. What to do with that? Leave it as it is for now? @igorpecovnik

igorpecovnik commented 4 months ago

Leave it as it is for now?

There is an attempt to bump it to mainline but it got stalled: https://github.com/armbian/build/pull/4873 @martinl @adeepn

If nothing comes out of pings, IMO, lets remove it. Anyway it can be brought-up if there is some interest.

adeepn commented 4 months ago

Leave it as it is for now?

There is an attempt to bump it to mainline but it got stalled: #4873 @martinl @adeepn

If nothing comes out of pings, IMO, lets remove it. Anyway it can be brought-up if there is some interest.

Oh, I forgot about him. I thought I'd have r2 free for experiments, but it's still busy on the home network and I can't touch it yet. so I'm taking a break. if anything, I'll restore it to csc status later.

p.s. i can try move it to 6.x kernel without testing on real hardware.

ColorfulRhino commented 4 months ago

p.s. i can try move it to 6.x kernel without testing on real hardware.

The hard part is not the bumping itself, but finding and removing every old/leftover stuff in order to keep everything clean and tidy 😄

I've taken https://github.com/armbian/build/pull/4873 and adapted it to current standards. @adeepn I'll leave the testing to you once you got time. Feel free to improve it to get it working :)

ColorfulRhino commented 4 months ago

This is now done! No 4.x kernels are remaining in the system, everything is at least 5.x 🎉 (5.x I'm coming for you soon™ as well 😈)

Remaining stuff like integrating families into rockchip64 has been split off to other tasks.

Thanks to everyone who helped :)

rpardini commented 4 months ago

Excellent work @ColorfulRhino.