RFC: change kernel to RPF one

[Mausy5043]

It seems that the Raspbian kernel development is dead in the water.
Changing over to the Raspberry Pi Foundation kernel or supporting both (via a parameter perhaps) should be considered.

Please use this issue to discuss the pros, cons, what-ifs and howtos.

[diederikdehaas]

I was thinking about a kernel_package parameter (or sth like that). That would also allow installing of an older kernel package (see #166).

But it looks like the Raspbian kernel development may not yet be dead in the water :-D
http://archive.raspbian.org/raspbian/pool/main/l/linux-4.9/ contains a 4.9 kernel package \o/

Haven't tried it yet, but reasonable chance that it may work and on top of that, the 4.9 kernel is also the one that will be used in Debian Stretch.

Still agree with this issue though 👍

[Zeerix]

Kernel 4.9 works and fits better to the new firmware package than the older kernel 4.4 (see my comment on issue 471).

What's the motivation for the switch to the raspberrypi.org's kernel?

[diederikdehaas]

see my comment on issue 471

That was likely the reason that I searched for a new kernel package/version 👍 (obviously didn't read that issue properly :-P)

What's the motivation for the switch to the raspberrypi.org's kernel?

Because for a very long time it did look like the raspbian.org kernels were dead in the water. I had opened several raspbian bugs related to it, but got no response. And until recently there was also no new firmware package which caused newer RPi revisions to not work/boot.
And one of the main reasons to go for the raspbian.org kernel was because it had proper kernel headers package(s) which could be important for installing a (dkms) driver package for wireless devices.
Another reason was for pushing RPF to get their act together and release a kernel headers package, which didn't exist at all for a long time. Apparently it worked as they now (and for a while) do provide such a package ;-)

Why would you prefer the raspbian.org kernel, assuming you do?
(Collecting ppls ideas/motivations/etc for kernel X or Y is the purpose of this issue)

[Zeerix]

I would switch to kernel 4.9 first (simple change) and then add an option to use the RPF kernel.

Everyone who wants a stable-ish system (for production, or "it should just work") can use the raspbian.org kernel, and the people that want to experiment more can use the RPF kernel.
But I don't know how often the RPF kernel is updated and how likely it is to break stuff.

[diederikdehaas]

But I don't know how often the RPF kernel is updated and how likely it is to break stuff.

It gets update (far) too often to my liking with no concern for a stable ABI, which Debian (and raspbian.org) kernels very much strife for. Consequently, it may break stuff

from #508 (comment):

Sad thing is that I've now concluded that it's VERY unlikely that there will be any kernel or firmware update coming from raspbian (evar). Thus model 4 will not work at all.

So a switch to RPF kernel is needed (see #473) or to (full) Debian as Debian's 4.19 kernel and raspi(3)-firmware package should work too, albeit probably not as good as RPF's kernel+firmware, but it would/could be full Debian. That probably does mean RPi 0/1 won't be supported though.
As I am a Debian 'fanboy', that is the more likely option. It's also more in line with what this project previously has done and Debian's raspi(3)-firmware package installs the firmware files into /boot/firmware/ so no more errors when updating the kernel f.e. and 64bit (arm64) should also work ...

We'll see.

[diederikdehaas]

It gets update (far) too often to my liking with no concern for a stable ABI, which Debian (and raspbian.org) kernels very much strife for. Consequently, it may break stuff

The main problem with that it'll break the installer like #501 only '10' times more, namely with each kernel upgrade.
Plugwash presented the/a solution, but that was by using Python, which may actually be a good idea, but a big departure from what has been used (and could force Python in the installer, making it substantially larger)

[positron96]

Just installed ua-netinst this week and discovered that temperature reading via sys thermal_zone0/temp does not work on latest raspbian kernel.

Btw, how does one move to RPF kernel? I tried to install RPF kernel but simple apt-get install raspberrypi-kernel did not work for me (a reboot failed and since I've done that remotely via ssh I can't fix anything until I get to my RPi).

[diederikdehaas]

Btw, how does one move to RPF kernel?

sudo aptitude install raspberrypi-kernel raspberrypi-bootloader
Using aptitude is important (here) as it will provide you with a solution that works; apt-get simply bails out. IIRC it removes raspberrypi-bootloader-nokernel and maybe others.
After that, you need to modify /boot/config.txt to disable the kernel and initramfs lines

[positron96]

Interesting, I got the impression that apt and aptitude are more or less the same these days.

So, you are saying that I need to remove kernel and initramfs lines from config.txt and it will find correct ones?

[diederikdehaas]

apt and aptitude have grown closer together, but apt-get isn't (afaik).
The crucial difference, in general but certainly in this case, is that aptitude's (dependency-) resolver is far more powerful. So "if you install this package (from that release) and remove this/these package(s) then it should fulfill what you want to do".

Remove or comment out (#). If you don't it'll still (try to) boot the raspbian.org kernel and that's not what you want.
And I forgot another thing: remove the file or disable the lines in /etc/apt/preferences.d/01vcgencmd.pref
That's needed to get libraspberrypi-bin libraspberrypi0 from RPF repos. I think that the previous aptitude command will suggest that (to upgrade them).