[Solved] Upgraded to linux 3.12 but system freezes showing 3.11.6!

ninian · 2013-11-16 23:45:43

Have a crazy problem (or is it me?) after a pacman -Syu today on my 64-bit Arch system which simply starts with Openbox from .xinitrc.
Upgrade looks normal, and mkinitcpio reports 3.12 images created fine.
But when I reboot (with or without poweroff), the text showing the login prompt is suspiciously huge and says we've got kernel 3.11.6; X starts but the display and desktop background are a bit horizontally stretched; Conky starts up - showing the kernel as 3.11.6 again; then everything completely freezes. I can only proceed by powering off. Did a boot from an Arch live CD and chrooted successfully to downgrade the kernel to 3.11.6 and could boot up again normally.
Changed my Pacman mirrors, and did a pacman -Syyu again, and exactly the same problems.
Had a look at the journals and there seem many suspicious messages, but nothing definitive to me in the quick look I had.
System is too crippled too quickly to proceed I think without some further advice about this bizarre situation!
PS: Using Syslinux to boot - its menu shows, but Arch fallback image fails too - and not using UEFI.

Last edited by ninian (2013-11-17 11:58:28)

karol · 2013-11-16 23:47:55

Do you have a separate /boot partition? Make sure syslinux is pointing to the right place.

ninian · 2013-11-16 23:58:31

karol wrote:

Do you have a separate /boot partition? Make sure syslinux is pointing to the right place.

No, everything - boot, root, home, etc - is in /dev/sda1 partition.
Gosh, that's a kinda scary possibility that we're pointing to conflicting places.
But if Syslinux worked fine before with 3.11.6 and earlier kernels, what could have changed to cause such a failure?!
Or maybe even permissions gone awry?

Never seen a problem like this before, and don't want to update any more of my 64 or 32-bit systems until I sort it out for certain.

Edit: some extra information:
Just booted the dud system again and managed to login on tty2.
The modules seem to be in the right places, namely: /usr/lib/modules/3.12.0-1-ARCH/etc
But 'uname -a' => Linux <user> 3.11.6-1-ARCH!
Mad thought:
I have a second hard drive /dev/sdb which held my original system before I mirrored it to the larger drive /dev/sda. Of course, all the /etc/fstab entries and syslinux.cfg were checked for the change of drive. But I notice that /dev/sdb1 still has the label I gave it - 'sda1'. Surely eg mkinitcpio or the kernel isn't getting confused by this?! (In syslinux.cfg, I specify: APPEND root=/dev/sda1 etc, I don't use UUIDs or Labels there or in /etc/fstab.)

Last edited by ninian (2013-11-17 00:20:34)

karol · 2013-11-17 00:13:23

Chroot and post the list of packages that were updated.
Check the output of 'file /boot/vmlinuz-linux', it should say you're using version 3.12.0-1-ARCH, and make sure /boot/syslinux/syslinux.cfg points to /boot/vmlinuz-linux.

Huge text in tty means no KMS. Stretched display in X probably means fallback vesa drivers on a non-vesa display. Are you using a 16:9 display?

ninian · 2013-11-17 00:38:02

karol wrote:

Chroot and post the list of packages that were updated.
Check the output of 'file /boot/vmlinuz-linux', it should say you're using version 3.12.0-1-ARCH, and make sure /boot/syslinux/syslinux.cfg points to /boot/vmlinuz-linux.
Huge text in tty means no KMS. Stretched display in X probably means fallback vesa drivers on a non-vesa display. Are you using a 16:9 display?

From my login on tty2 (see extra info in OP), here are the answers to your queries:
Packages updated:

libcups
cups
dhcpcd
gtk3
evince
flashplugin
gsimplecal
mesa
mesa-libgl
intel-dri
iptables
iproute2
linux
lirc-utils
netctl
pixman
puddletag
gca-ossl
virtualbox-host-modules
webkitgtk

file /boot/vmlinuz-linux => Linux kernel x86 boot executable bzImage, version 3.12.0-1-ARCH ...
My /etc/X11/xorg.conf only has a section "ServerFlags" to set the option DontZap.
/boot/syslinux/syslinux.cfg has:

LINUX ../vmlinuz-linux
APPEND root=/dev/sda1 ...
INITRD ../initramfs-linux.img

My display is: 1440x900
Yes, I think you are right about VESA - /var/log/Xorg.0.log confirms. Presumably because the intel module has a mismatch with kernel version?

Edit: in the tty2 session, dmesg reports: Linux version 3.11.6-1-ARCH (nobody@var-lib-archbuild-extra-x86_64-thomas)
What's the stuff in parentheses about?!

Last edited by ninian (2013-11-17 00:43:59)

WonderWoofy · 2013-11-17 00:49:57

ninian wrote:

Edit: in the tty2 session, dmesg reports: Linux version 3.11.6-1-ARCH (nobody@var-lib-archbuild-extra-x86_64-thomas)
What's the stuff in parentheses about?!

No idea why you might still be somehow booting 3.11.6, but as far as the stuff in the parenthesis, it means that the package was built by thomas with devtools as the user 'nobody'. Devtools is just a collection of scripts that makes package building easier and automated. It uses clean chroots in /var/lib/archbuild to build the packages. A clean chroot has only the base-devel packages and nothing else. This ensures that no extra ./configure flags are automatically set by autodetection of any optional programs to implement other features.

ninian · 2013-11-17 00:51:28

WonderWoofy wrote:

No idea why you might still be somehow booting 3.11.6, but as far as the stuff in the parenthesis, it means that the package was built by thomas with devtools as the user 'nobody'. Devtools is just a collection of scripts that makes package building easier and automated. It uses clean chroots in /var/lib/archbuild to build the packages. A clean chroot has only the base-devel packages and nothing else. This ensures that no extra ./configure flags are automatically set by autodetection of any optional programs to implement other features.

Ah, okay - fair enough.

ninian · 2013-11-17 01:04:02

Just mounted the second drive and checked:
file /mnt/sdb1/boot/vmlinuz-linux => 3.11.6-1-ARCH
Also, blkid shows:

/dev/sda1: LABEL="Arch64" etc
...
/dev/sdb1: LABEL="Arch64" ... PARTLABEL="sda1" etc
...

So I was wrong; the "label" I had given sdb1 was "Arch64", but where did PARTLABEL come from and is this what's causing the confusion, I wonder?
Maybe I should disconnect the second drive tomorrow to check this out.

cfr · 2013-11-17 01:17:34

You really can't rely on /dev/sda always referring to the same drive if you have multiple drives attached.

[Why would you use a label like "sda1" which is guaranteed to confuse things anyway? Why not "Bob" or "Gwenhwyfar" which your system is never going to come up with on its own?!]

WonderWoofy · 2013-11-17 01:37:17

PARTLABEL is what the partition is named by the GPT. So if you do gdisk -l /dev/sdb you will likely see that the lest colume says simply 'sdb1' for partition 1. You can change this as you please. Just use gdisk /dev/sdb to get the interactive version of gptfdisk, then use 'c' to change the partition name (PARTLABEL).

cfr is absolutely right that if you have more than one disk, you cannot at all be sure that sda is going to be sda every time or that sdb will be persistent either. On my machine, the regular hdd bay is nearly always sda, and the optical bay (which I replaced with a hdd caddy) is sdb, and the msata slot is sdc. But from time to time this actually changes. So in order to ensure that I am getting what I expect every time, I use filesystem labels.

ninian · 2013-11-17 11:27:06

Thanks @cfr and @WonderWoofy.

Physically disconnected the second drive today and nothing found to boot => definitely a Syslinux setup problem.
So chrooted and did an 'extlinux --install /boot/syslinux' then a 'dd bs=440 conv=notrunc count=1 if=/usr/lib/syslinux/bios/gptmbr.bin of=/dev/sda' to copy the MBR and make sure Syslinux was happy. (Also checked using 'sgdisk /dev/sda --attributes=1:show' that the legacy_boot flag was set - "1:2:1 (legacy BIOS bootable" - and it was already okay.)

Up and running again and, mea culpa ...
Your help was much appreciated, and I promise to be more circumspect about how I refer to partitions in the future!

karol · 2013-11-17 11:51:51

Please remember to mark the thread as solved https://bbs.archlinux.org/viewtopic.php?id=130309

Arch Linux

#1 2013-11-16 23:45:43

[Solved] Upgraded to linux 3.12 but system freezes showing 3.11.6!

#2 2013-11-16 23:47:55

Re: [Solved] Upgraded to linux 3.12 but system freezes showing 3.11.6!

#3 2013-11-16 23:58:31

Re: [Solved] Upgraded to linux 3.12 but system freezes showing 3.11.6!

#4 2013-11-17 00:13:23

Re: [Solved] Upgraded to linux 3.12 but system freezes showing 3.11.6!

#5 2013-11-17 00:38:02

Re: [Solved] Upgraded to linux 3.12 but system freezes showing 3.11.6!

#6 2013-11-17 00:49:57

Re: [Solved] Upgraded to linux 3.12 but system freezes showing 3.11.6!

#7 2013-11-17 00:51:28

Re: [Solved] Upgraded to linux 3.12 but system freezes showing 3.11.6!

#8 2013-11-17 01:04:02

Re: [Solved] Upgraded to linux 3.12 but system freezes showing 3.11.6!

#9 2013-11-17 01:17:34

Re: [Solved] Upgraded to linux 3.12 but system freezes showing 3.11.6!

#10 2013-11-17 01:37:17

Re: [Solved] Upgraded to linux 3.12 but system freezes showing 3.11.6!

#11 2013-11-17 11:27:06

Re: [Solved] Upgraded to linux 3.12 but system freezes showing 3.11.6!

#12 2013-11-17 11:51:51

Re: [Solved] Upgraded to linux 3.12 but system freezes showing 3.11.6!

Board footer