[SOLVED] uname -r -- does it "read" the kernel or where does it get its output from?

JZL240I-U · 03-22-2010, 02:15 AM

It tells me I have installed 2.6.31.5-0.1.default.

But I updated twice and have now (nominally at least) 2.6.31.12-0.1.default (SuSE). In /lib/modules there are five links to directories from 2.6.31.5-0.1.xyz -> 2.6.31.12-0.1.xyz. A bunch of 2.6.31.8-0.1.xyz directories are obviously the previous and now unused update of the original 2.6.31.5-0.1.xyz. Those 2.6.31.5-0.1.xyz directories seem to have been scrubbed by YAST2.

The GRUB menu.lst reads 2.6.31.12-0.1.default.

So where does "uname -r" read its information? And how do I find out what really is running on my box?

GrapefruiTgirl · 03-22-2010, 02:53 AM

I'm guessing that `uname` queries the kernel, but not really sure, and the man page doesn't really say for sure either.

However, if your kernel has support for keeping its config file in /proc/ for you to access, you can try these couple commands below to query the running kernel's information:

Code:

sasha@reactor: zgrep CONFIG_LOCALVERSION= /proc/config.gz
CONFIG_LOCALVERSION="-33-05to33.1-00"

so you can see my local version name I appended to my kernel name when I built it. This assumes your kernel even HAS a custom local version. To simply see the plain version, try this:

Code:

sasha@reactor: zgrep version /proc/config.gz
# Linux kernel version: 2.6.33.1

and there you see the release version of the kernel.

So, if you compare the data you get from those commands, to the output from `uname`, I guess if they match you at least know what kernel you're running for sure.

Sasha

JZL240I-U · 03-22-2010, 03:14 AM

Quote:

Originally Posted by GrapefruiTgirl

I'm guessing that `uname` queries the kernel, but not really sure, and the man page doesn't really say for sure either.

I know, I tried there first

.

Quote:

Originally Posted by GrapefruiTgirl

...This assumes your kernel even HAS a custom local version...

No, it is as downloaded from the Novell site. They deliver *.pae, *.default and *.xen versions though.

Quote:

Originally Posted by GrapefruiTgirl

...To simply see the plain version, try this:

Code:

sasha@reactor: zgrep version /proc/config.gz
# Linux kernel version: 2.6.33.1

and there you see the release version of the kernel.

Do you know where from /proc gets its content?

Quote:

Originally Posted by GrapefruiTgirl

...So, if you compare the data you get from those commands, to the output from `uname`, I guess if they match you at least know what kernel you're running for sure.

Sasha

Thank you for the information, I'll try it out tonight.

GrapefruiTgirl · 03-22-2010, 03:16 AM

The data in /proc is REALLY from the running kernel

/proc is a "virtual filesystem", i.e. everything in it disappears when you shut down, and it is magically recreated upon reboot. The /proc/config.gz file is from the running kernel itself -- it is not saved from any other time..

Sasha

JZL240I-U · 03-22-2010, 03:19 AM

Aha, thanks. I just wanted to make sure the kernel doesn't read /lib/modules, but from your words I take it that it is branded on its own butt so to speak (and looks there too)

.

GrapefruiTgirl · 03-22-2010, 03:34 AM

Yup, /proc should be current and reliable!

A kernel will read its OWN /lib/modules/.. folder, when looking for modules, and if it tries (or is tricked into) reading modules and things from a modules folder from another kernel, weird things will happen usually. The more different the kernels, the weirder stuff will be.

But: before we speculate on the possible weirdness, let us know how you make out with the /proc/config.gz file, and if you are then sure what kernel you're running!

Here's some more stuff to ponder:

Code:

sasha@reactor: file  /boot/64/bz26331-00
/boot/64/bz26331-00: Linux kernel x86 boot executable bzImage, \
version 2.6.33.1-33-05to33.1-00 \
(root@r, RO-rootFS, root_dev 0x30B, swap_dev 0x2, Normal VGA

Above, I use the `file` command to examine my current kernel image; the bold part I highlighted in the output, you will see some or all (the version, and the local version if you have it) in your /var/log/dmesg file after bootup.

(For those of you who are really awake right now, you can see that `file` tells us that it's an x86 kernel, even though it's actually x86_64.. Interesting!)

P.S> I broke that file output with \'s to make it more readable.

JZL240I-U · 03-23-2010, 02:11 AM

Good morning Sasha

Ummm...

Quote:

Originally Posted by GrapefruiTgirl

...you can try these couple commands below to query the running kernel's information:

Code:

sasha@reactor: zgrep CONFIG_LOCALVERSION= /proc/config.gz
CONFIG_LOCALVERSION="-33-05to33.1-00"

so you can see my local version name I appended to my kernel name when I built it.

That produces a "-0.1-default" on my machine.

Quote:

Originally Posted by GrapefruiTgirl

...To simply see the plain version, try this:

Code:

sasha@reactor: zgrep version /proc/config.gz
# Linux kernel version: 2.6.33.1

and there you see the release version of the kernel.

Now this results in exactly nothing

as do the searches for "kernel" or "Kernel" or "KERNEL" or "2.6" or "31". What the...

And this

Quote:

Originally Posted by GrapefruiTgirl

...sasha@reactor: file /boot/64/bz26331-00
/boot/64/bz26331-00: Linux kernel x86 boot executable bzImage, \
version 2.6.33.1-33-05to33.1-00 \
(root@r, RO-rootFS, root_dev 0x30B, swap_dev 0x2, Normal VGA

I changed to the structure of SuSE's file layout and got from it

Code:

# file /boot/vmlinuz-2-6-31-12-0.1-default 

Linux/x86 Kernel, Setup Version 0x20a, bzImage, Version 2.6.31.12, \  RO-rootFS, root_dev 0x301, swap_dev 0X3, Normal VGA

So that hints strongly at a 2.6.31.12 Kernel.

But (in this case there seems always to lurk some "but" somewhere)

Code:

#cat /proc/version
Linux Version 2.6.31.5-0.1-default

Well, well, well. What do you make of that?

P.S.: How did you break the file output with \'s to make it more readable? I Inserted a "\" but that alone doesn't do the trick.

GrapefruiTgirl · 03-23-2010, 02:21 AM

WOw! Those last two outputs are intriguing to say the least.

I have a theory, but that's all it is: I'd say the output from the `file` command is showing the real version of the kernel binary, while the output of /proc/version is somehow showing a "compatibility" version, a phony version -- say for example, so that the OS could perhaps upgrade the kernel image itself, without needing to upgrade or change other stuff on the system; sort of a way to trick the rest of the system into thinking that the installed kernel is the original (??) 2.6.31.5-0.1-default -- thereby allowing kernel upgrades, without breaking other stuff?

Only a theory as I said -- so if this is wrong, I have no other idea at this time. Interesting though.

I've never run SuSE myself, but from what I gather from reading and looking around the net from time to time, SuSE does things "differently" than many Linuxes, so there must be a good explanation for this weird behavior you are seeing..

Sasha

PS - I just ran `cat /proc/version` on my system, and I get basically the exact same data as I got from the `file` command.

JZL240I-U · 03-23-2010, 02:34 AM

To sum it up: I assume that the kernel image in /boot really gets booted (where else should GRUB get the image from?), so I run a 2.6.31.12 kernel.

All the weird stuff probably comes from these funny linking tricks like 2.6.31.5-0.1.xyz -> 2.6.31.12-0.1.xyz in /lib/modules and probably elsewhere. I wonder why SuSE is doing it that way (and I'd prefer it differently). After all, the original kernel image is even deleted, I could not roll back in case something went wrong. Which it did by the way, one in five links where missing due to problems during the last update. I got lots of errors during the next boot (missing modules), so I created it by hand but that is not exactly what one would expect of a routine updating. And, of course it led to the original question about "uname -a".

Thanks a lot for your help, Sasha, and for the "moral support"

in these bewildering circumstances.

GrapefruiTgirl · 03-23-2010, 02:39 AM

No problem, glad I could help to some degree at least

I think you're on the right track -- that funny linking stuff definitely sounds like it could produce the situation you're seeing, for sure. And, as I'm sure you realize, if there's only one kernel image available in /boot, and the bootloader points to that image, (AND especially if you built the image yourself) then you can be pretty sure (like 99.9999% as there are few certainties in life) that THAT is the kernel that is running.

I don't know either why they do stuff like that -- but I still kinda think it's to trick *something* into believing that a certain version of the kernel is running. If you do find the answer, I'll be interested in hearing it

Sasha

JZL240I-U · 04-07-2010, 03:19 AM

Time for an update...

Over the last holidays I had a little more time and wanted to run an online-update. And lo and behold there was a kernel update included -- which ended with an error, something like kernel rpm could not be installed (one can't copy that out of the YAST-window

).

I then remembered that there had been an error report during my last update too, too fast to really read and remember. And this time again lots of errors during the next boot until I re-assigned the links in /lib/modules.

So this will be the reason for the funny behaviour. I just wonder, where the old kernel is hidden, since it is not in /boot.

Further digging made me assume, that "uname" gets its information from /dev/proc (or /dev/sys?) and not from the static entries in /boot, but I can't prove that.

This is from 1,5 MB error output which I could copy

Code:

Subprocess failed. Error: RPM fehlgeschlagen (<- failed): Free diskspace below /boot: 3782912 blocks
error: db4 error(-30987) from dbcursor->c_get: DB_PAGE_NOTFOUND: Requested page not found
error: error(-30987) getting "ddecac6d" records from Provideversion index
error: db4 error(-30987) from dbcursor->c_get: DB_PAGE_NOTFOUND: Requested page not found
error: error(-30987) getting "f5011f67" records from Provideversion index
error: db4 error(-30987) from dbcursor->c_get: DB_PAGE_NOTFOUND: Requested page not found
....
error: db4 error(-30977) from dbcursor->c_get: DB_RUNRECOVERY: Fatal error, run database recovery
error: error(-30977) getting "" records from Filedigests index
rpmdb: PANIC: fatal region error detected; run recovery
error: db4 error(-30977) from dbcursor->c_get: DB_RUNRECOVERY: Fatal error, run database recovery
error: error(-30977) getting "+��fF� V � �   " records from Filedigests index
rpmdb: PANIC: fatal region error detected; run recovery
....
rpmdb: PANIC: fatal region error detected; run recovery
error: db4 error(-30977) from db->sync: DB_RUNRECOVERY: Fatal error, run database recovery
rpmdb: PANIC: fatal region error detected; run recovery
error: db4 error(-30977) from db->sync: DB_RUNRECOVERY: Fatal error, run database recovery
....

I ran "rpm -v rebuilddb" and got no output despite using the verbosity switch and tried installing the kernel again to the same result.

Can you make something out here? And the most important thing: What has happened to my installation so that I can't update the kernel and how can I alleviate the situation?

GrapefruiTgirl · 04-07-2010, 12:18 PM

Unfortunately, not being SuSE user nor an RPM user, I probably would not do you any favors by trying to speculate on what the above output means for your system.

On the surface, it looks like a DB that is used by RPM (or by YasT) is out of whack, but how/why/what-to-do, I have no idea..

I suggest you maybe use the REPORT button, and ask to have that latest post of yours moved to a brand new thread & retitled, in the SuSE forum, and that you leave a link pointing from this thread to that thread, or vice versa, or both -- since this issue looks to be (in my opinion) slightly different than the original issue, and more SuSE-specific than the earlier situation or to the kernel itself.

Cheers!
Sasha

JZL240I-U · 06-03-2010, 04:53 AM

Okay I found the reason for this behaviour

and described it here:

http://www.linuxquestions.org/questi...6/#post3991074

That much is clear now but I won't mark this thread as [SOLVED] as I still do not understand where uname -r reads it output from...

catkin · 06-03-2010, 05:31 AM

According to the uname source code, the uname command gets its data by using the uname system call. The uname system call man page (displayed in response to man 2 uname), in the NOTES section, says that the information comes from the kernel -- not surprisingly as system calls are user-space programs' interface with the kernel.

JZL240I-U · 06-03-2010, 05:43 AM

Quote:

Originally Posted by catkin

According to the uname source code, the uname command gets its data by using the uname system call.

*respectful bow in recognition of knowledge* *envy*

Quote:

Originally Posted by catkin

The uname system call man page (displayed in response to man 2 uname), in the NOTES section, says that the information comes from the kernel -- not surprisingly as system calls are user-space programs' interface with the kernel.

Okay, but where from, exactly? I mean, is it "hard wired" i.e. compiled in from source or a header and where and how is it read out? Or is it created during the make stage like in other packets? Is it in the file header of the kernel and can be found with a hex editor? In other words where is the source of information uname is drinking from

?