You are not logged in.
The kernel version number used to change whenever a new kernel was installed. However, since 3.1.1-1-ARCH it does not!
I had to rename the module directory 3.1.2-1-ARCH to 3.1.1-1-ARCH or I could not load any modules at all. We are now at 3.1.4-1-ARCH, but I still use the old module directory from 3.1.2-1-ARCH, renamed 3.1.1-1-ARCH. Oh well, I can rename 3.1.4-1-ARCH to 3.1.1-1-ARCH, and eberything will work.
Still, I would like to know
1) is this happening only for me,and
2) any clue to why, and
3) what to do to correct it.
I have the /boot in the root partition with the files copied to /mnt/boot which is another partition, shared by all OS variants I have on my system. Currently the only other Linux I have on it is Slackware so there is no question of mixed up files.
Last edited by occam (2011-12-05 02:34:39)
Moduli non sunt multiplicandi praeter necessitatem
Offline
It's working for me
[karol@black ~]$ uname -r
3.1.4-1-ARCH
I'm running 32-bit.
Did you reboot after installing the new kernel?
Last edited by karol (2011-12-04 10:56:42)
Offline
I am running the x86_64 version and yes, I have rebooted after the upgrades - every time.
uname -r still says 3.1.1-1-ARCH
Moduli non sunt multiplicandi praeter necessitatem
Offline
then it either failed to generate initrd or your bootloader configuration is busted, loading the old initrd for some other location.
Give what you have. To someone, it may be better than you dare to think.
Offline
cybertorture@ego:~ $ pacman -Qi linux
Name : linux
Version : 3.1.4-1
URL : http://www.kernel.org/
Licenses : GPL2
Groups : base
Provides : kernel26
Depends On : coreutils linux-firmware module-init-tools>=3.16 mkinitcpio>=0.7
Optional Deps : crda: to set the correct wireless channels of your country
Required By : None
Conflicts With : kernel26
Replaces : kernel26
Installed Size : 60112,00 K
Packager : Tobias Powalowski <tpowa@archlinux.org>
Architecture : x86_64
Build Date : 29.11.2011 (вт) 9,59,41 EET
Install Date : 1.12.2011 (чт) 22,58,13 EET
Install Reason : Explicitly installed
Install Script : Yes
Description : The Linux Kernel and modules
cybertorture@ego:~ $ uname -rm
3.1.4-1-ARCH x86_64
is /boot mounted (if it is separate partition)
what is your /boot/grub/menu.lst
O' rly ? Ya rly Oo
Offline
boot is on /dev/sda3 and is mounted, manually, only when a new kernel is to be installed. Arch installs the kernel to /boot, which has no separate partition, after which I copy the files, manually, to /mnt/boot (sda3) and reboot.
The non-comment part of /mnt/boot/grub/menu.lst is
# general configuration:
timeout 5
default 0
color light-blue/black light-cyan/blue
# Arch Linux
title Arch Linux
root (hd0,2)
kernel /vmlinuz-linux root=/dev/sda5 ro
initrd /initramfs-linux.img
# Arch Linux fallback
title Arch Linux Fallback
root (hd0,2)
kernel /vmlinuz-linux root=/dev/sda5 ro
initrd /initramfs-linux-fallback.img
# Slackware 13.37
title Slackware 13.37
root (hd0,2)
kernel (hd0,2)/boot/vmlinuz-huge-smp-2.6.37.6-smp root=/dev/sda7 ro
# Windows 7
title Windows 7
rootnoverify (hd0,0)
#makeactive
chainloader +1
and in both the /boot and the /mnt/boot directory is the date of the initramfs-linux.img files is 04/12/11
My pacman -Qi linux output was identical to the one showed above, except for the install date - I installed it 04/12/11
Moduli non sunt multiplicandi praeter necessitatem
Offline
boot is on /dev/sda3 and is mounted, manually, only when a new kernel is to be installed. Arch installs the kernel to /boot, which has no separate partition, after which I copy the files, manually, to /mnt/boot (sda3) and reboot.
No idea why you think this is a good idea. Your problem stems from booting off the wrong (old, 3.1.1-ARCH) kernel image.
Offline
I used to have several versions of Linux and sometimes the names of the boot files were identical; meaning that the distro assigned file names could not be used. Having a "distro local" boot for each version lets me have a "global" boot directory (which is normally NOT mounted) with unique names, without any problems.
Ok, so if I am booting from an old kernel image, even if the new modules work ok: where does the system find that kernel image? The timestamps and byte count of ALL (=both) vmlinuz-linux files are identical. Neither 'locate' or 'find' can find any other vmliuz-linux files.
Moduli non sunt multiplicandi praeter necessitatem
Offline
root (hd0,2) - this means it boot kernel image from sda3
kernel /vmlinuz-linux - this is the name of image that should be booted (from sda3), unles it is a link to other file
initrd /initramfs-linux.img - same as previous
O' rly ? Ya rly Oo
Offline
Ok, so if I am booting from an old kernel image, even if the new modules work ok: where does the system find that kernel image?
It's on your /boot partition, of course. The new one is installed to the /boot directory on the root partition. modules working between versions is a luxury that you've lucked out on. I'm surprised it works.
$ modinfo -k 3.1.4-1-ARCH i915 -F vermagic
3.1.4-1-ARCH SMP preempt mod_unload modversions
The timestamps and byte count of ALL (=both) vmlinuz-linux files are identical
I have no frame of reference, so this is meaningless to me. Mount /boot, update the kernel. uname does not lie.
Offline
Problem solved, in an unexpected way.
SInce I normally have /dev/sda3 (/mnt/boot) not mounted, I assuned that when I saw a list of files there, it was mounted. I was wrong.
So, I have diligently checked the /mnt/boot directory and copied all new files to it - but it was not mounted. Therefore, of course, the boot process uszed the 'real' boot directory but I was looking at another set of files.
So, obviously, you can use a mount point directory as a 'normal' directory which will be hidden when it is used as a mount point. I should have known..
(Now if I could only remember how to mark a topic [SOLVED])
Moduli non sunt multiplicandi praeter necessitatem
Offline
Edit the initial post and put [Solved] in the title.
Offline
@occam:
I use very much the same setup as you have (*lol* even down to having slackware as well!) - _and_ I have a /mnt/boot which is never mounted (unless I need to update it).
However - I use the 'chainloader' directive instead, that way I don't need to copy files across. Each distro has its bootloader on its root filesystem (some of the others I try out are using grub2 and there's no way I'm gonna let grub2 interfer with my setup!!)
Thus - I would have the following entries in my /mnt/boot/grub/menu.lst
title archlinux
root (hd0,4)
chainloader +1
title slackware
root (hd0,6)
chainloader +1
It makes life ever so eeeezee :-)
Now - it means I can only use filesystems that grub support, but hey - I want my root filesystem to be super-stable rather than experimenting - so reiserfs/ext3 is fine with me. The more exotic fs's I leave for plain data-partitions ...
Last edited by perbh (2011-12-05 17:55:19)
Offline
Thanks for that tip. I will follow it from now on - the ease of use is well worth the limitation in file system types.
Moduli non sunt multiplicandi praeter necessitatem
Offline