Proposal for kernel naming convention - kernel8 is not an upgrade of kernel7l

[iandstanley]

Is this the right place for my bug report?
This repository contains the Linux kernel used on the Raspberry Pi. If you believe that the issue you are seeing is kernel-related, this is the right place. If not, we have other repositories for the GPU firmware at github.com/raspberrypi/firmware and Raspberry Pi userland applications at github.com/raspberrypi/userland. If you have problems with the Raspbian distribution packages, report them in the github.com/RPi-Distro/repo. If you simply have a question, then the Raspberry Pi forums are the best place to ask it.

Describe the bug
the new 64 bit kernel should take a new naming convention
the new kernel is called kernel8 which misleads into thinking it is a production upgrade from kernel7.img or kernel7l.img whereas it is a experimental kernel leading other developers to create software that breaks the sudo apt upgrade process leading to wasted hours trying to find a fix for something that doesn't need a fix

Keeping to the old naming convention has broken old assumptions leading to issues with other packages. e.g. the debian package needrestart
pi@raspberrypi:/ $ apt search needrestart
Sorting... Done
Full Text Search... Done
needrestart/stable,now 3.4-5 all [installed,automatic]
check which daemons need to be restarted after library upgrades

needrestart-session/stable 0.3-6 all
check for processes need to be restarted in user sessions
which in turn breaks the APT UPGRADE process

To reproduce
install raspbian (latest) then install docker-compose (or any other software dependant of the debian

you now get an annoying hook for needrestart package that complains and tells the user to reboot ... but the message never goes away

The whole process wastes a lot of time for the end user trying to figure out what is wrong with his/her system and why it won;t upgrade to the new kernel

Expected behaviour
The operating system should have a clear naming convention that allows scripts like needrestart to ascertain which is the latest operating system and answer the question do I need to reboot to upgrade my kernel.

Without a different naming convention it is impossible to ascertain if the machine is on the latest kernel version.

Which is later 4.19.97-v7l+ or 4.19.97-v8+? to most people the simple reading of this would be 4.19.97-v8+ whereas the actual is IT DEPENDS - an answer that you can only get to after wasting hours on google and confusing contradictory forum postings.

Other operating systems that run on multiple architectures (other linuxes, BSDs, SunOS, (presumably MacOS) and who knows what else) all have ensured that if you are to support different architectures you have to do one of two different things to not create confusion

(1) offer a different release for each type of cpu architecture

• this would be counter-intuitive for new users and really should be avoided - joe public would not understand which operating system version to download (remember the confusion when 64bit windows came out)

or (2) release both kernels in a single release but name the kernels in such a manner that the name of the architecture is embedded into the the kernel file (like the x86_32 and x86_64 tags in the kernel names)

Actual behaviour
kernel8.img is suggestive of an upgrade of kernel7.img or kernel7l.img

any upgrade to a package after this results in the following message

Newer kernel available │
│ │
│ The currently running kernel version is 4.19.97-v7l+ which is not the expected │
│ kernel version 4.19.97-v8+. │
│ │
│ Restarting the system to load the new kernel will not be handled automatically, so │
│ you should consider rebooting.

firstly this results in a lot of confusion and time wasted trying to get to the new kernel8.img when actually you are perfectly ok with kernel7l.img

Secondly as other scripts depend on the naming convention of the kernel being consistent (ie incrementing the number for the next kernel should actually be the newer kernel not an alternative os path

thirdly it would avoid breakages in the apt system
docker-compose requires needrestart which misinterprets the kernel8.img as an upgrade to kernel7l.img which it isn't (it is an alternative 64 bit kernel not an upgrade). unfortunately this means that any scripting of installation also breaks - any kind of scripted automation of a build will break as it needs manual input to get rid of the dialog box that pops up every time you perform a apt upgrade or install

System
Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:

pi@raspberrypi:/ $ raspinfo
bash: raspinfo: command not found

Maybe raspinfo should be added to the default installation?

System Information

Raspberry Pi 4 Model B Rev 1.1
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"

Raspberry Pi reference 2020-02-13
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 5f884374b6ac6e155330c58caa1fb
7249b8badf1, stage5

Linux raspberrypi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux
Revision : c03111
Serial : 10000000e061d57d
Model : Raspberry Pi 4 Model B Rev 1.1
Throttled flag : throttled=0x0
Camera : supported=0 detected=0

**Pi 4

pi@raspberrypi:/ $ vcgencmd version
Feb 12 2020 12:36:21
Copyright (c) 2012 Broadcom
version c3c8dbdf147686fb0c3f32aece709d0653368810 (clean) (release) (start)
pi@raspberrypi:/ $ uname -a
Linux raspberrypi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux**

Logs
If applicable, add the relevant output from dmesg or similar.

Additional context
This issue could cause all sorts of problems for inexperienced users experimenting and educating themselves

A simple change to the naming convention would make it clear to third party developers what is a production kernel and what is experimental, what is for 32 bit and what for 64

Maybe marking the kernels with the 32 or 64 architecture would prompt other developers that these are two different kernels and one is not the

Just incrementing the kernel image number causes confusion to scripting that has been around for years

another worrying issue that has appeared in the apt install process is this
┤ Daemons using outdated libraries ├─────┐
│ │
│ │
│ Which services should be restarted? │
│ │
│ [ ] lightdm.service │
│ [ ] unattended-upgrades.service │
│ │
│ │
│

Beats me whether this is real or not apt update && apt upgrade reports nothing out of date.

As the raspbian os is aimed at inexperienced users (kids, students and university) wanting to learn about technology and not bleeding edge kernel developers we need to think a bit more about how things might appear to them - wasting hours of their time can be discouraging. It this was an industrial development board I'd say to them just go and figure it out but we are talking about people's first real dig into the depths of Linux

when they see two kernels one saying 32 and one 64 and they google 32 or 64 kernel they will see results talking about bits and they naturally ask well how many bits does my board have. seeing a 7, 7l or 8 just leads to confusion

[JamesH65]

AIUI, the 8 comes from the ARMv8 architecture, which is 64 bit., vs the ARMv7 architecture which is 32 bit. So it does make sense from that point of view.

[JamesH65]

Also see this docs page https://www.raspberrypi.org/documentation/configuration/boot_folder.md

[pelwell]

This is the first time anybody has expressed confusion. Most people are completely unaware what the kernel is called - the firmware just loads the correct one. If the user has asked for a 64-bit kernel (with the aptly named arm_64bit flag), it will load that instead. At some point the default value of that flag could change for 64-bit capable devices, but the user still won't need to know what the kernel is called.

Kernel names have never just been incremented. As James says, they were chosen based on the names of the ARM architecture, but giving too much detail might just be more confusing.

[P33M]

I... what?

As far as I can tell, you are having an issue because you aren't parsing the kernel's version string correctly. Note: the version string is a concatenation of independent variables, not a number.

A kernel image with version number 4.bob.6969-v8+ is built from the same codebase as a kernel image with version number 4.bob.6969-v7l+. In both cases the kernel source version is 4.bob.6969. Our naming scheme (which is common elsewhere) appends -v7, -v7l, -v8 to differentiate the architecture(s) that the kernel was built for.

I suggest you upgrade your versioning scripts to parse hyphens.

[Xoib]

Well @iandstanley is right.
But the fix has to go upstream for the needrestart tool. Not here.

$ uname -a Linux raspberry 5.4.51-v7+ #1333 SMP Mon Aug 10 16:45:19 BST 2020 armv7l GNU/Linux

The tool think that the v8 is an upgrade, instead it doesn't consider that I don't use the arm_64bit flag, thus staying in V7l era.

Fyi I tested this on an up to date Raspberry Pi 3 Model B Rev 1.2.