Upgraded linux-ck-haswell 4.3.4 -> 4.3.5, and now it wont boot

simendsjo · 2016-02-03 19:11:02

Upgraded linux-ck-haswell from 4.3.4 to 4.3.5, and now my computer refuses to boot.

Message at boot: https://goo.gl/photos/4MEdHUFLWuzymd2U7

[2016-02-03 18:18] [PACMAN] Running 'pacman -S linux-ck-haswell'
[2016-02-03 18:19] [ALPM] transaction started
[2016-02-03 18:19] [ALPM] upgraded linux-ck-haswell (4.3.4-1 -> 4.3.5-1)
[2016-02-03 18:19] [ALPM-SCRIPTLET] >>> Updating module dependencies. Please wait ...
[2016-02-03 18:19] [ALPM-SCRIPTLET] >>> Generating initial ramdisk, using mkinitcpio. Please wait...
[2016-02-03 18:19] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux-ck.preset: 'default'
[2016-02-03 18:19] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-linux-ck -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-ck.img
[2016-02-03 18:19] [ALPM-SCRIPTLET] ==> Starting build: 4.3.5-1-ck
[2016-02-03 18:19] [ALPM-SCRIPTLET]   -> Running build hook: [base]
[2016-02-03 18:19] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
[2016-02-03 18:19] [ALPM-SCRIPTLET]   -> Running build hook: [autodetect]
[2016-02-03 18:19] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[2016-02-03 18:19] [ALPM-SCRIPTLET]   -> Running build hook: [block]
[2016-02-03 18:19] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[2016-02-03 18:19] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[2016-02-03 18:19] [ALPM-SCRIPTLET]   -> Running build hook: [fsck]
[2016-02-03 18:19] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2016-02-03 18:19] [ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-ck.img
[2016-02-03 18:19] [ALPM-SCRIPTLET] ==> Image generation successful
[2016-02-03 18:19] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux-ck.preset: 'fallback'
[2016-02-03 18:19] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-linux-ck -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-ck-fallback.img -S autodetect
[2016-02-03 18:19] [ALPM-SCRIPTLET] ==> Starting build: 4.3.5-1-ck
[2016-02-03 18:19] [ALPM-SCRIPTLET]   -> Running build hook: [base]
[2016-02-03 18:19] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
[2016-02-03 18:19] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[2016-02-03 18:19] [ALPM-SCRIPTLET]   -> Running build hook: [block]
[2016-02-03 18:19] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: aic94xx
[2016-02-03 18:19] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: wd719x
[2016-02-03 18:19] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[2016-02-03 18:19] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[2016-02-03 18:19] [ALPM-SCRIPTLET]   -> Running build hook: [fsck]
[2016-02-03 18:19] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2016-02-03 18:19] [ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-ck-fallback.img
[2016-02-03 18:19] [ALPM-SCRIPTLET] ==> Image generation successful
[2016-02-03 18:19] [ALPM] transaction completed

I found this post, https://bbs.archlinux.org/viewtopic.php … 5#p1330705, that mentions some mkinitcpio parameters.
I notice that while the fallback is built with

-S autodetect

, the main kernel isn't.
Messing with this file is quite frightening as I'm scared to break my entire system.

Any idea what might be wrong and how I might fix it?

graysky · 2016-02-03 20:50:13

The pacman.log output looks normal. You shouldn't need to mess with mkinitcpio.conf unless you have a specific reason (hardware or raid, encryption etc.) to do so. Are you able to boot from your bootloader at all (ie into the distro kernel)?

simendsjo · 2016-02-03 20:53:50

Yes, the distro kernel works.

graysky · 2016-02-03 21:04:11

Please regenerate the ck images and try again. Also, please update your boot loader config just to rule out a change in UUID or the like.

mkinitcpio -p linux-ck

I dunno which boot loader you're using but I assume you know how to update its config file.

simendsjo · 2016-02-07 10:39:50

Looks like this is an rEFInd issue. Is searches for modules in

/lib/modules/4.4.1-2-ARCH

, which is for the main kernel. The ck modules is located in

/lib/modules/4.3.5-1-ck

. I cannot find any references to any of these in the config files, but at least I think I found the issue.

WorMzy · 2016-02-07 11:05:17

Mod note: Not a problem with pacman, moving to AUR issues.

simendsjo · 2016-02-07 11:20:56

.. And I'm back to square one. I cannot see anything in rEFInd which indicates anything wrong, and mkinitcpio says it's building for the right kernel version..

graysky · 2016-02-07 12:06:54

simendsjo wrote:

Looks like this is an rEFInd issue. Is searches for modules in
/lib/modules/4.4.1-2-ARCH
, which is for the main kernel. The ck modules is located in
/lib/modules/4.3.5-1-ck
. I cannot find any references to any of these in the config files, but at least I think I found the issue.

I have no experience with rEFInd but if you believe that in fact it is to blame, you might wanna change the title to something related and ask a mod to move the thread to a different area. What doesn't make sense to be is that 4.3.4-ck-1 booted fine but 4.3.5-ck-1 does not since each keeps its own modules separate from 4.4.1-2-ARCH. Tell me: was the ck kernel your only kernel when you were on 4.3.4-ck-1?

To rule out rEFInd as the problem, you might wanna post its config and ask for users to review it.

simendsjo · 2016-02-07 12:13:07

graysky wrote:

Tell me: was the ck kernel your only kernel when you were on 4.3.4-ck-1?

It was the only one I was using, but I always have the main kernel just in case.

My configs are as follows:

/boot/refind_linux.conf

"CK with Defaults"              "root=PARTUUID=fd49b830-b5f7-4426-816b-73054b9cd304 rootfstype=ext4 rw rootflags=rw,noatime,discard,data=ordered cgroup_disable=memory add_efi_memmap initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux-ck.img"
"CK with fallback initramfs"    "root=PARTUUID=fd49b830-b5f7-4426-816b-73054b9cd304 rootfstype=ext4 rw rootflags=rw,noatime,discard,data=ordered cgroup_disable=memory add_efi_memmap initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux-ck-fallback.img"
"Boot with Defaults"              "root=PARTUUID=fd49b830-b5f7-4426-816b-73054b9cd304 rootfstype=ext4 rw rootflags=rw,noatime,discard,data=ordered cgroup_disable=memory add_efi_memmap initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux.img"
"Boot with fallback initramfs"    "root=PARTUUID=fd49b830-b5f7-4426-816b-73054b9cd304 rootfstype=ext4 rw rootflags=rw,noatime,discard,data=ordered cgroup_disable=memory add_efi_memmap initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux-fallback.img"

/boot/loader/loader.conf

timeout 5
default archlinux-core-main

/boot/loader/entries/archlinux-core-main

title    Arch Linux
linux    /boot/vmlinuz-linux-ck
initrd   /boot/intel-ucode.img
initrd   /boot/initramfs-linux-ck.img
options  root=PARTUUID=fd49b830-b5f7-4426-816b-73054b9cd304 rootfstype=ext4 rw rootflags=rw,noatime,discard,data=ordered cgroup_disable=memory add_efi_memmap

I've actually just found a way to beet the linux-ck kernel. In the bootloader I can choose `vm-linuz with ck` (or similar) rather that the entries from refind_linux.conf, and then it works. How these are generated, I don't know..

WorMzy · 2016-02-07 12:55:03

simendsjo wrote:

Looks like this is an rEFInd issue. Is searches for modules

I should've commented on this earlier, but refind does not look for modules at all. If something is looking for modules in that location, it is either in the initrd or after the rootfs has been mounted.

If it is in the initrd, then the image is out-of-date (and you would probably get a kernel panic). Rebuild the initrds.

If it is in the rootfs, then your kernel and modules are desynced (that is, the kernel version you are booting does not match the modules version installed on the rootfs). This can happen if you updated the kernel without the ESP mounted.

In this case, I can foresee another possible problem. In your refind config, there is no mention of the kernel. It's been a while since I used refind, but I'm not sure how it handles multiple kernels. When you select "CK with Defaults", how does it know to load the linux-ck kernel? From what you have said, I believe it is loading the regular kernel, and trying to use the linux-ck initrd. Find out how to make it use the correct kernel.

Arch Linux

#1 2016-02-03 19:11:02

Upgraded linux-ck-haswell 4.3.4 -> 4.3.5, and now it wont boot

#2 2016-02-03 20:50:13

Re: Upgraded linux-ck-haswell 4.3.4 -> 4.3.5, and now it wont boot

#3 2016-02-03 20:53:50

Re: Upgraded linux-ck-haswell 4.3.4 -> 4.3.5, and now it wont boot

#4 2016-02-03 21:04:11

Re: Upgraded linux-ck-haswell 4.3.4 -> 4.3.5, and now it wont boot

#5 2016-02-07 10:39:50

Re: Upgraded linux-ck-haswell 4.3.4 -> 4.3.5, and now it wont boot

#6 2016-02-07 11:05:17

Re: Upgraded linux-ck-haswell 4.3.4 -> 4.3.5, and now it wont boot

#7 2016-02-07 11:20:56

Re: Upgraded linux-ck-haswell 4.3.4 -> 4.3.5, and now it wont boot

#8 2016-02-07 12:06:54

Re: Upgraded linux-ck-haswell 4.3.4 -> 4.3.5, and now it wont boot

#9 2016-02-07 12:13:07

Re: Upgraded linux-ck-haswell 4.3.4 -> 4.3.5, and now it wont boot

#10 2016-02-07 12:55:03

Re: Upgraded linux-ck-haswell 4.3.4 -> 4.3.5, and now it wont boot

Board footer