Uname -r output is weird on newest (RC version) kernels

Manjaro Development QA
1

I posted several dmegs log to developers and realized that uname -r output on rc-kernels are not representative.

Lets see nowadays example: linux59 package of Manjaro Linux.

Output of
uname -r
is close to this
5.9.0-1-MANJARO
on all of rcX-family kernels, so it lasts about 2 months of using of newest kernel.

dmesg output is close to this:

Sep 30 11:06:52 kernel: Linux version 5.9.0-1-MANJARO (builduser@LEGION) (gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35) #1 SMP PREEMPT Sun Sep 27 22:02:13 UTC 2020

so also did not contain certain rcX version and git commit of installed and used kernel - did not contain the actual version of a RC-kernel package:

$ pacman -Qi linux59
Name            : linux59
Version         : 5.9rc7.d0927.ga1b8638-1
Description     : The Linux59 kernel and modules
Architecture    : x86_64
URL             : http://www.kernel.org/
Licenses        : GPL2
Groups          : None
Provides        : linux=5.9rc7.d0927.ga1b8638  VIRTUALBOX-GUEST-MODULES  WIREGUARD-MODULE
Depends On      : coreutils  linux-firmware  kmod  mkinitcpio>=27
Optional Deps   : crda: to set the correct wireless channels of your country [installed]
Required By     : manjaro-system
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 150.92 MiB
Packager        : Helmut Stult <helmut@manjaro.org>
Build Date      : Sun 27 Sep 2020 22:01:47 UTC
Install Date    : Wed 30 Sep 2020 12:43:17 UTC
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

It is not the best idea to tell what kernel version do Manjaro user uses now leads to make additional queries on a system to figure out and actually to fix bad info report of typical dedicated instruments which was developed to provide authoritative solid answers.

Please let dedicated version utils and logs to provide exhaustive/exact/solid about version. Do not brake their behaviour.

If I see old logs I can’t realize which rc-kernel I was running earlier - all rcX-kernels are looks like <major>.<minor>.0-1-MANJARO can’t determine which rcX was on run in prev boots: all ten RCs looks like one 0.1 for 2 months of its lifetime.
It’s not representative even for dedicated utils such as uname -r and dmesg log.

Can this behaviour of broken functionality of typical utils running on newest (RC-family) kernels will be planned to be fixed to provide actual solid full information about kernel version?

2

To be honest i fail to understand what are you trying to convey …

What developers, where and regarding what? The kernel or the coreutils (as uname is part of it) …
The way coreutils works was the same since i know about it. Was always printing the --kernel-release like that and never how the package is named or the way the versioning in the package is done.

Please contact the developers of coreutils
https://www.gnu.org/software/coreutils/
and if you have a proposal to make things better about it, then open an issue there.

1 Like
3

Hi, bogdancovaciu! Now you are in Manjaro team? Congratulations!
Thank you for taking part in topic!

No matter who, why - it is off-topic discussion. Let’s in this topic will stay in topic-related staff.
Anyone who reads for example
uname -r output for current 5.9-rc7 kernel see something close (almost cite it) 5.9.0.1-MANJARO
what output was when current kernel was 5.9-rc6? 5.9.0.1-MANJARO
5.9-rc5? 5.9.0.1-MANJARO
5.9-rc4? 5.9.0.1-MANJARO
5.9-rc3? 5.9.0.1-MANJARO
5.9-rc2? 5.9.0.1-MANJARO
Did I clarified the problem?

dmesg output has the same lack: it only adds some (local machine?) kernel build time. It output close to this:
Sep 30 11:06:52 kernel: Linux version 5.9.0-1-MANJARO (builduser@LEGION) (gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35) #1 SMP PREEMPT Sun Sep 27 22:02:13 UTC 2020

No exact/full/solid/representative info about kernel version: always template 5.9.0-1-MANJARO and sometime build date. But to determine exact kernel version it needs rcX info and if rcX label of building kernel did not match the kernel repo commit, than (or Manjaro do it always) adds build date and exact commit hash, which can be found in MSM and pacman -Qi kernel59.

So for every RC-kernel (5.7, 5.8, 5.9) uname -r, dmesg can’t point to exact kernel version and me and developers who debugging by bug reports can’t understand on which exact kenel version was a bug.
This leads to dedicated utils written to report kernel version can’t do it’s job.

The way coreutils works was the same since i know about it. Was always printing the --kernel-release like that and never how the package is named or the way the versioning in the package is done.

Now may be “core moment” of topic: I think that Manjaro developers decide how to name their kernels of Manjaro OS. Is not it?
So the uname -r output string is a subject which OS developers can change to clarify their kernel version.

Let’s look at:

ubuntu

728×546 32.3 KB

fedora

perfect/exact/full/solid output of kernel version: they are not outputs just the same ‘5.7.0.1’ for 2 months for every RC-kernel version which updates every week. So their example of additional text makes me think that distro developers drives exact kernel version substring (that is I create that topic for in Dev forum section) and every distro uses the same universal algorithms of uname output (so I think it is not the coreutils lack).

Or may be I am wrong and there is no way to add exact kernel version in exactly Manjaro distro to clarify outputs of basic utils like uname, dmesg, etc. and let them as can’t report exact kernel version?

4

I think it’s how the kernels are packaged in x86_64 Manjaro. Because in Manjaro ARM, our linux-rc shows the rcX version in uname.

The reason it’s not set like that in x86, is beyond me, but maybe since it’s actually the same package when it gets stable release, and it’s just easier to maintain packaging it, when doing it like this.

2 Likes
5

Hey, Strit! Thanks for taking part too!

and it’s just easier to maintain packaging it

that’s “killing me” :slight_smile: lets continue: may be to cut all versions? to leave only package name? cause it is also easier, isn’t it? :slight_smile: or we can do it right?
Again: on Manjaro we have such very basic utils like uname which was made to report kernel version to be unable to tell actual version.
I think it is weird, but may be it is the only my discomfort, no matter what I believe in.
If I am not alone alien came from another world and it is not Manjaro related issue (for me that is hard to believe) than we need to escalate upstream problem or we want mess/not exact/semi-understandable/half info in distro which based on well-documented may be best documented distro?

6

RC - looking through my glasses is - release candidate.

The actual kernel packages are numbered - incrementally - not only for the kernel’s release number but also the pkgrel so when you execute

uname -r
5.8.12-3-MANJARO

You get the exact package your kernel was installed from.

This is the Arch way of numbering the kernels - due to the rolling release model.

This is different from what you may be used to - but not a regular issue.

And all changes in the build process - patches added or removed in the PKGBUILD is availiable using the package history on gitlab e.g. for the current linux58 kernel

As the package manager log contains every change made since you intially installed the system - and you need to know which kernel package was installed at a given point in time you could filter the log

grep 'linux59' < /var/log/pacman.log
2 Likes
7

On our end we always replace EXTRAVERSION with our revisions. That is why there are no RC tags on x86_64.

8

exactly what I meant, “your glasses are from my factory” if to continue used metaphor.

yeah, after RC stage ends I saw no problem with exact version of kernel.

Aarhus, I read message to the end and think that may be I was not understood:

  1. it is only RC kernel stage lack
  2. yes, we can determine it and this way pacman -Qi linux59, but:
    2a) it is additional action then I need to say what RC-kernel version is currently running/installed
    2b) dedicated utils not represent full version of every RC-kernel (“Manjaro 20.1” is not a “Manjaro” only and not “Manja” also, so why to cut kernel version?)
    2c) if to analyze history of prev. bootups of PC journal -k -bX, than all I can get is general name the same for all RC-kernels for 2 months long and only some date of kernel. Every time it is investigation of the simple thing “which kernel version did it ran at that time?” there need to compare pacman.log date-time with journal and realized the used version.

Why to cut to 5.9.0.1-MANJARO? All RC looks like the same version number

Why not to leave 5.9.0.1-rc7-MANJARO or even full/solid/exact lossless 5.9.0.1-rc7-d0927.ga1b8638-1-MANJARO (as MSM shows)?

Why to like lossy/cutted version number?

Does anybody born on 2?
What I mean? Jan/Fab/Mar/…? Or may be date of 20/21/22/…?

Why need to investigate simple things making certain/exact answers harder/more time consumed?
The more harder typical actions to do the less we can made: not enough force and time: we spent/waste it to investigate simple things like “what RC kernel version do/did you run?”

9

Highly want to vote to make you to add your info after gathered kernel version numbers, not to cut, not to replace with yours.

Hm, only me want it? May be I am from “another planet” and want version dedicated utils to show version instead of partial version?

“John Smith”? Will be “Jo” :slight_smile:

10

I don’t know - and frankly the matter is of little importance to me - if you want to know something specific filter your pacman log.

I don’t understand why you cannot adapt to the way Manjaro kernel devs package the kernel and accept it for how it is?

For the four years I have been participating on Manjaro forum - it is not the first time a member tries to change Manjaro to fit their perspective. The continuation of this discussion could be considered pointless as I don’t think the Manjaro kernel devs are going to change the way they do things just to accommodate the expressed point of view.

1 Like
11

I just want more comfort. It is the only reason. To simplification of manual actions, more automation, less investigates of primitive questions to free more force and time to more interesting things than compare pacman.log and journalctl -k to answer what kerner version did I ran at certain time in the past. Such a simple but heavier-than-could-be manual tasks took forces and time each time.

Let me show example from world around us just as analogue illustrated case:
on even or odd weeks could you every time do not push the button to flush toiler but take a bucket, open cold water, wait for bucket fills up and then pour out the toilet with water from bucket? why you need comfort, why not just to act with bucket???

It is totally the same reason. Besides unpredictable output of dedicated utils (RC kernel versions shown partially, stable and LTS in full) we should add manual actions for RC kernels. Why to so dislike comfortable always predictable output usage, which also can be used in scripts for all kernel version spectrum?
Do you use ‘compile’ shortcut key in your IDE or take mouse, open menu, search line with ‘compile’, moving pointer to it and press it? why to like comfort of hotkeys?

I do not know how to better explain or to illustrate with real life actions…

I am not right if from version utils I expect version? Utils should sometimes show version and sometime partial version depending on outer kernel is RC or not? Is it really good programming approach? :slight_smile:

of course everybody want more comfort and will act to get it.
But newbie can mistakes often, professional would not so often, but does professional does not make mistakes? May be someone can advice good idea? If somebody someday stops to apply good practices than what the chance the product will be good? If logic “we will not change somewhat cause it is 30 years as is and everything’s fine”, than thank you all so much for attention and taking part in topic. I tried to suggest better (as I see on my current level of understanding). If not so hard restrictions, than it could be voted or may be to make another one conversation item on your virtual team meeting to change it or not.

Of course, if only me is need that, than it is not the target to aim. Of course may be I do not understand something and could not predict bad side.

Anyway, even if I am alone on that idea, thanks to all readers and actors/posters!

13

Manjaro and Arch uses semantic versioning.

You are getting the version 5.9.0.1 - this is RC - when the .1 disappears then you are on release.

Maybe you can persuade the kernel devs to make an automatic increment of the decimal point - but still - most kernel devs know what they are handling - and so do those devs working on the kernel.

This is development versions - they are available so anyone can follow progress maybe provide feedback - and as Manjaro is rolling - and you cannot have different versions of any given major release - same goes for development versions - and 5.9.x.1 is development and you cannot run different versions of the same development kernel.

Your quest to satisfy a nice requirement for your benefit only is a waste of time.

image

1 Like