What kernel am I running? Can I trust uname? [SOLVED]

rugantino · 2011-08-20 22:15:17

[See solution on my posting of 2011-10-27]
Is there a more direct and intrinsic way to know what Arch kernel I'm running
than asking uname? I have recently installed Archlinux on four machines,
expecting to end up with kernel 2.6.39, or, in the last couple of days, 3.0.1
or 3.0.3.
On the two laptops (one 32-bit and one 64-bit), uname indeed reports the above
kernel numbers, and those are matched by directory names
/lib/modules/2.6.39-ARCH and 3.0-ARCH. However, on the two desktops (both
64-bit, one Intel and one AMD), while I get, as expected, one of those two
directory names in /lib/modules, uname reports instead in both cases
2.6.35-std201!
Is there a way to somehow ask the kernel itself what version it thinks it is?
What's the story behind this mixup?
Thanks

Last edited by rugantino (2011-10-31 19:09:58)

Earnestly · 2011-08-20 22:30:13

pacman -Qi linux perhaps

[ dmesg | grep Linux ]
[ cat /etc/issue]
[ cat /proc/version ]

Last edited by Earnestly (2011-08-29 12:47:27)

ewaller · 2011-08-20 22:34:14

I've never heard of uname reporting anything but the correct kernel version.

Question: Any chance you are not running the kernel you think you are?
Did you have other distros installed on those machines first?
Any chance Grub is running from a partition other than the one you think it is?
Have you verified that the /boot/grub/menu.lst entry you are using actually points to the kernel you think it is?

Is there a way to somehow ask the kernel itself what version it thinks it is?

Try:
cat /proc/version

I run a custom kernel:

ewaller@odin:~ 1037 %cat /proc/version 
Linux version 3.0.3-HP_DV4 (ewaller@odin) (gcc version 4.6.1 (GCC) ) #1 SMP PREEMPT Sat Aug 20 09:59:20 PDT 2011
ewaller@odin:~ 1038 %

rugantino · 2011-08-28 16:44:00

Thanks for suggesting a number of plausible "reasons" for my problem. However, the facts rule out those reasons. Namely,

1. I am not using GRUB, or any other bootloader for that matter. Since I started using GPT partitioning for large disks, and hadn't realized that
GRUB2 needs a dedicated BIOS boot partion (no connection with the /boot/ directory) to support GPT, I'm running at present without a bootloader, and I directly boot the system partition (the one with the / filesystem) by means of system-rescue-cd.
2. This was a virgin hard disk; no other versions of Linux are present on it. So the "2-6-35-std201" kernel name reported by uname cannot have come from a system previously installed on the disk.

I would greatly appreciate a fresh round of conjectures.

---- STOP THE PRESSES ---- I may have found a clue!

After typing point 2 above, I ran uname on another computer in which I had fired up system-rescue-cd, and THAT Linux reported "2-6-35-std201-i686"! So the kernel reported by uname and by /proc/version in my Arch installation may somehow be a leftover of the way it was booted by sys-rescue-cd. That is, for me at least. a TOTALLY UNANTICIPATED occurrence.
Note that, in spite of reporting sys-rescue-cd's kernel, my system is definitely running Arch Linux (for instance, it responds to changes in /etc/rc.conf, and /lib/modules reports 2.6.32-lts/ and 3.0-ARCH/ and no other folders; specifically, not 2-6-35-std201), I presume with a 3.0-ARCH kernel.
Must I conclude that in certain circumstances uname and /proc/version may lie? How can I touch with hand which Linux kernel it is that I'm
really running.
If the present conjecture is right (if not, I would feel horribly confused), whose fault is it? Arch Linux's or sys-rescue's. On what thread should it
be reported?
Many thanks for past and any future advice.

P.S. As supporting evidence for the above diagnosis, at the same time as the problem occurred on two desktops I had installed Arch Linux on two laptops whose hard drives had already been partitioned with usual MBR and already had Windows 7, so I chose GRUB (legacy) at installation time. On those two installations, which use GRUB as a bootloader and thus have no use for system-rescue-cd, uname regularly reports 3.0-ARCH.

Last edited by rugantino (2011-08-28 17:19:41)

falconindy · 2011-08-28 17:40:48

rugantino wrote:

I'm running at present without a bootloader, and I directly boot the system partition (the one with the / filesystem) by means of system-rescue-cd.

Right, so as you've been told multiple times, uname isn't lying. You're booting off the kernel from systemd-rescue-cd, not from Arch's kernel.

ewaller · 2011-08-29 03:26:20

Okay, can you please post the output of ls -l /boot and of mount

I want to see the kernels on your boot disk, and verify that the boot partition is mounted on /boot.
Once we do that, we can move on to looking at how those get loaded.

Also, can you elaborate on

GRUB2 needs a dedicated BIOS boot partion (no connection with the /boot/ directory) to support GPT, I'm running at present without a bootloader, and I directly boot the system partition (the one with the / filesystem) by means of system-rescue-cd.

lukaszan · 2011-08-29 10:34:56

ewaller wrote:

Okay, can you please post the output of ls -l /boot and of mount
I want to see the kernels on your boot disk, and verify that the boot partition is mounted on /boot.
Once we do that, we can move on to looking at how those get loaded.

I'm with falconindy on this one.

He may well have correct kernels mounted correctly, but looks like he is booting a kernel from a different location altogether. System-rescue-cd seems an obvios suspect here.

rugantino · 2011-10-23 18:53:28

If you use SystemRescueCD to boot an "unbootable" system, know what you are doing!

I've figured out what my problem was, and I think the answer may be useful to others. In spite of the legend "boot to a Linux system on the hard disk", SystemRescueCD was launching A GENERIC LINUX KERNEL SUPPLIED BY IT into THE FILESYSTEM ENVIRONMENT (hopefully compatible with that kernel) PRESENT IN A USER-CHOSEN DISK PARTITION. Nothing wrong with that, but misleading.

I had installed Archlinux in a brand-new disk partitioned with GPT, and, since I had a traditional BIOS board and I had not provided a separate boot partition, Grub2 was not able to boot. Thence the need to boot "by hand" in spite of all the necessary information being present in my /boot directory. Being familiar with SystemRescueCD, I imagined that SuperGrub CD would do an even better job at locating a bootable partion and doing the work for me---but that didn't work. I then tried SystemRescued CD, and by being told which partition to use it successfully booted into my ArchLinux installation. Then, after a while, to my dismay I realized it was not running the ArchLinux version I thought I had installed (2.6.38), but 2.6.35std instead! Thence the present BBS thread.

Fact is, SystemRescueCD has two sets of choices in its main menu. The choices in the first set obviously launch SystemRescueCD own LiveCD system, where both kernel and filesystem live in RAM, and the hard disk can contain anything you want, including a broken Linux system you may want to fix, or simply data files you may need to rescue.

As worded, the choices in the second set may make one believe that SystemRescueCD will try to boot into YOUR OWN SYSTEM on the hard disk. What happens, instead, is that, while the resulting Linux will (try to) mount and use as a filesystem the partition you designate, the kernel and the interim intrdfs ramd are provided by SystemRescuedCD; the contents of your /boot directory is ignored. Thus one ends up with a HYBRID system, which may or may not work and may have a lot of surprises in store!

Since an ArchLinux installation will fill the /boot directory with the files (kernel image and ram image) needed to bootstrap ITSELF,
the clean solution if your only problem is how to boot is to go back to the SuperGrub2 disk, and type just three lines in command-line mode (ignore the menus and just press 'c' to enter it); in my case

1. linux (hd0,6)/boot/vmliz-linux root=/dev/sda6
2. initrd (hd0,6)/boot/initramfs-linux.img
3. boot

Voila! I just told SuperGrub2 what kernel I wanted, where to get it, and what parameters to pass to it (line 1); what ramdisk image to use and where to get it (line 2); and finally (line 3), "Now please boot with that!"

stryder · 2011-10-23 23:51:37

Would you then mark your thread as solved, please. Or better still, add "Yes, I can" to the end. :-)

jimbok · 2011-10-24 02:42:38

The last two netinstalls I did using the x86_64 20110819 netinstall image still report "3.0-ARCH" using the uname command. My /boot partition is /dev/sda1 like I always do, and as I transitioned from 3.0.2 through the 3.0.7 kernel updates, I thought it was odd to see 3.0 all the time but thought nothing of it. Then I saw this post and poked around a bit. The only place I could find that "3.0-ARCH" string is in /var/abs/core/linux/linux.install" file. Are the same abs files used for the official kernel builds?

Arch Linux

#1 2011-08-20 22:15:17

What kernel am I running? Can I trust uname? [SOLVED]

#2 2011-08-20 22:30:13

Re: What kernel am I running? Can I trust uname? [SOLVED]

#3 2011-08-20 22:34:14

Re: What kernel am I running? Can I trust uname? [SOLVED]

#4 2011-08-28 16:44:00

Re: What kernel am I running? Can I trust uname? [SOLVED]

#5 2011-08-28 17:40:48

Re: What kernel am I running? Can I trust uname? [SOLVED]

#6 2011-08-29 03:26:20

Re: What kernel am I running? Can I trust uname? [SOLVED]

#7 2011-08-29 10:34:56

Re: What kernel am I running? Can I trust uname? [SOLVED]

#8 2011-10-23 18:53:28

Re: What kernel am I running? Can I trust uname? [SOLVED]

#9 2011-10-23 23:51:37

Re: What kernel am I running? Can I trust uname? [SOLVED]

#10 2011-10-24 02:42:38

Re: What kernel am I running? Can I trust uname? [SOLVED]

Board footer