LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software > Linux - Kernel
User Name
Password
Linux - Kernel This forum is for all discussion relating to the Linux kernel.

Notices

Reply
 
Search this Thread
Old 03-22-2010, 03:15 AM   #1
JZL240I-U
Senior Member
 
Registered: Apr 2003
Location: Germany
Distribution: openSuSE 13.1 / 12.3_64-KDE, Ubuntu 14.04, Fedora 20, Mint 17, Chakra
Posts: 3,677

Rep: Reputation: Disabled
uname -r -- does it "read" the kernel or where does it get its output from?


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?
 
Old 03-22-2010, 03:53 AM   #2
GrapefruiTgirl
Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550
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

Last edited by GrapefruiTgirl; 03-22-2010 at 03:54 AM. Reason: typos
 
Old 03-22-2010, 04:14 AM   #3
JZL240I-U
Senior Member
 
Registered: Apr 2003
Location: Germany
Distribution: openSuSE 13.1 / 12.3_64-KDE, Ubuntu 14.04, Fedora 20, Mint 17, Chakra
Posts: 3,677

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by GrapefruiTgirl View Post
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 View Post
...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 View Post
...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 View Post
...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.
 
Old 03-22-2010, 04:16 AM   #4
GrapefruiTgirl
Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550
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
 
Old 03-22-2010, 04:19 AM   #5
JZL240I-U
Senior Member
 
Registered: Apr 2003
Location: Germany
Distribution: openSuSE 13.1 / 12.3_64-KDE, Ubuntu 14.04, Fedora 20, Mint 17, Chakra
Posts: 3,677

Original Poster
Rep: Reputation: Disabled
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) .
 
Old 03-22-2010, 04:34 AM   #6
GrapefruiTgirl
Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550
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.
 
Old 03-23-2010, 03:11 AM   #7
JZL240I-U
Senior Member
 
Registered: Apr 2003
Location: Germany
Distribution: openSuSE 13.1 / 12.3_64-KDE, Ubuntu 14.04, Fedora 20, Mint 17, Chakra
Posts: 3,677

Original Poster
Rep: Reputation: Disabled
Good morning Sasha

Ummm...

Quote:
Originally Posted by GrapefruiTgirl View Post
...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 View Post
...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 View Post
...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.

Last edited by JZL240I-U; 03-23-2010 at 03:20 AM.
 
Old 03-23-2010, 03:21 AM   #8
GrapefruiTgirl
Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550
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.

Last edited by GrapefruiTgirl; 03-23-2010 at 03:22 AM.
 
Old 03-23-2010, 03:34 AM   #9
JZL240I-U
Senior Member
 
Registered: Apr 2003
Location: Germany
Distribution: openSuSE 13.1 / 12.3_64-KDE, Ubuntu 14.04, Fedora 20, Mint 17, Chakra
Posts: 3,677

Original Poster
Rep: Reputation: Disabled
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.
 
Old 03-23-2010, 03:39 AM   #10
GrapefruiTgirl
Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550
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
 
Old 04-07-2010, 04:19 AM   #11
JZL240I-U
Senior Member
 
Registered: Apr 2003
Location: Germany
Distribution: openSuSE 13.1 / 12.3_64-KDE, Ubuntu 14.04, Fedora 20, Mint 17, Chakra
Posts: 3,677

Original Poster
Rep: Reputation: Disabled
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?

Last edited by JZL240I-U; 04-07-2010 at 05:47 AM.
 
Old 04-07-2010, 01:18 PM   #12
GrapefruiTgirl
Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550
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
 
Old 06-03-2010, 05:53 AM   #13
JZL240I-U
Senior Member
 
Registered: Apr 2003
Location: Germany
Distribution: openSuSE 13.1 / 12.3_64-KDE, Ubuntu 14.04, Fedora 20, Mint 17, Chakra
Posts: 3,677

Original Poster
Rep: Reputation: Disabled
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...
 
Old 06-03-2010, 06:31 AM   #14
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,557
Blog Entries: 28

Rep: Reputation: 1178Reputation: 1178Reputation: 1178Reputation: 1178Reputation: 1178Reputation: 1178Reputation: 1178Reputation: 1178Reputation: 1178
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.
 
Old 06-03-2010, 06:43 AM   #15
JZL240I-U
Senior Member
 
Registered: Apr 2003
Location: Germany
Distribution: openSuSE 13.1 / 12.3_64-KDE, Ubuntu 14.04, Fedora 20, Mint 17, Chakra
Posts: 3,677

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by catkin View Post
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 View Post
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 ?

Last edited by JZL240I-U; 06-09-2010 at 02:07 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
square brackets in output of "ps aux" not matching output of "ps -ejH" alirezan1 Linux - Newbie 14 07-14-2010 05:17 AM
printing hh in hh:mm using "awk '{FS=":";print $1}'" misses first line of output!! mayankmehta83 Linux - Newbie 2 12-03-2009 03:55 AM
output of dmesg is "kernel: hda:" rajeev_ku Linux - Server 1 05-04-2009 01:46 PM
"failed to execute child process" "Input/output error" fl.bratu Fedora 4 12-15-2008 05:03 AM
Feeding the output of "diff" or "cat" command to dpkg --purge kushalkoolwal Debian 9 06-19-2008 08:27 AM


All times are GMT -5. The time now is 10:37 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration