Microcode problems

andrekp · 2014-10-26 16:18:10

Did the reading, searched the other forum posts, didn't find a solution for me.

Installed intel-ucode and upgraded kernel to 3.17.1-1

My system is dual boot with Ubuntu. Since Ubuntu is the only one that changes kernel names with each upgrade, I let Ubuntu control updating Grub2. Specifically, I have a custom Ubuntu/etc/grub.d/40_custom file that simply reads in the required linux boot lines for Arch. It reads:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "Arch Linux (on /dev/sdb9)" --class gnu-linux --class gnu --class os {
	insmod part_msdos
	insmod ext2
	set root='(hd1,msdos6)'
	search --no-floppy --fs-uuid --set=root 56fa8712-137b-4700-aac1-8a01206d10da
	linux /boot/vmlinuz-linux root=UUID=56fa8712-137b-4700-aac1-8a01206d10da rw quiet vga=790
	initrd /boot/initramfs-linux.img
}
menuentry "Arch Linux (Fallback initramfs on /dev/sdb6)" --class gnu-linux --class gnu --class os {
	insmod part_msdos
	insmod ext2
	set root='(hd1,msdos6)'
	search --no-floppy --fs-uuid --set=root 56fa8712-137b-4700-aac1-8a01206d10da
	linux /boot/vmlinuz-linux root=UUID=56fa8712-137b-4700-aac1-8a01206d10da rw quiet
	initrd /boot/initramfs-linux-fallback.img
}

As I do it this way, I figure the best solution to loading the microcode image is to alter the initrd line in this 40_custom file, run an update-grub on Ubuntu, and it all should work.

With the line altered to: "initrd /boot/intel-ucode.img /boot/initramfs-linux.img" I get a kernel panic, stating "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)"

I would assume this means that it can't find the second entry, /boot/initramfs-linux.img, when it boots. I have not tried anything unusual like reversing the order, removing "/boot" from the second entry, or the like because the wiki does not say to do so, nor has anyone else, to my knowledge.

This happens on two computers (haven't done the third yet), a Pentium D and a core Duo, both of which are on the list for using this microcode. Both boot fine, obviously, with the intel-core.img line removed from Grub2's menu entry.

Any suggestions?

Last edited by andrekp (2014-10-26 16:45:39)

ewaller · 2014-10-26 16:38:41

The command line is not right:

initrd /boot/intel-core.img /boot/initramfs-linux.img should be initrd /boot/intel-ucode.img /boot/initramfs-linux.img

andrekp · 2014-10-26 16:47:35

Thanks ewaller, but that was just my own (corrected) typo in this post. (typed by hand, since it was since been removed from the Grub2 file that I quoted.)

I believe it was correct when it was actually IN the Grub2 file, but that's certainly something to try again and double check.

EDIT: double checking the Grub entry to be typed correctly and trying again, yields the same error. I do not believe it is a typo causing this.

Last edited by andrekp (2014-10-26 16:53:09)

satanselbow · 2014-10-26 17:26:54

/* missed first line of original post */

Last edited by satanselbow (2014-10-26 17:42:04)

ewaller · 2014-10-26 18:30:50

Time for a sanity check. Are you sure the microcode image file is on the boot partition? If the boot partition was not mounted when you installed the image from pacman, the file might be sitting in the /boot directory of your Arch system rather than having been written to the boot partition as one would expect had the boot partition been mounted.

From your Arch installation, prove that it the boot partition is mounted:

ewaller$@$odin ~ 1002 %mount | grep /boot
/dev/sda5 on /boot type ext2 (rw,relatime)
ewaller$@$odin ~ 1003 %

Then, look in /boot and verify that the microcode image is there.

If it is, is it possible that you have two boot partitions, and you are not booting from the one you think you are? On the Ubunto side, are you using device node names to access partitions, or do you use UUIDs? And on the Arch side? I see you use UUIDs in the grub file. I am trying to find out if that is what you have done in the /etc/fstab files of both distributions.

allonsy · 2014-10-26 19:47:48

I might be wrong by it was my understanding that grub sees '/' as /boot, not as the root of your normal fs tree. So typing /boot/intel-ucode.img and /boot/vmlinuz... means that grub is looking in /boot/boot/intel-ucode.img... for all of your kernel and initrd files. Unless you have a boot directory inside your boot directory, I would remove the beginning /boot from your entries and see if that works.

andrekp · 2014-10-27 12:46:03

@ewaller:

I only have a root and home partition, so the /boot partition of arch was mounted when i installed the image. It is in fact in my /boot folder.

I'm not sure I at all follow what you are trying to say regarding proving that my /boot partition is mounted (beyond that). THAT is my boot partition and it is where my kernal image, my initrfs image is and where my microcode image is. I don't know what other /boot partition I might have...

Where, OTHER THAN, my /boot partition of my Arch / (where the initramfs and kernel are) should the microcode image go?

Yes, on both ubuntu and Arch I use UUID's in Grub and the respective fstab files.

The way my Grub is set up is exactly as you see in my first post, which is a copy/paste from there. I have verified, just in case something else is even possible, that the UUID listed in Grub for my Arch / partition IS in fact the correct UUID. As I said, the /boot partition located in that UUID contains all the relevant files, so I'm not sure what else is possible, or what else I need to prove/disprove.

@allonsy: That may be true or not, BUT for years now my Grub files have been as in my first post with it saying /boot/etc., so I'm not sure why that would have changed all of a sudden.

I just tried about 10 minutes worth of changing things around ion that initrd line. I tried about everything obvious and I get the same kernel panic each time. The only thing that allowed me to boot was putting the microcode text after the initramfs text, but that's just because it was ignored and booted as if it only saw the initramfs text. So removing boot wasn't the fix.

andrekp · 2014-10-27 12:54:58

@ewaller:

If the boot partition was not mounted when you installed the image from pacman, the file might be sitting in the /boot directory of your Arch system rather than having been written to the boot partition as one would expect had the boot partition been mounted.

I've been trying to figure out what you mean here.

Do you maybe mean (in my case) that since Arch doesn't control Grub on my system, that the proper place for the microcode image file is in ubuntu's /boot folder? (the place where the grub menu file is)

EDIT: just tried putting a copy of the image file in Ubuntu's /boot partition, then use every variation I could think of on the initrd line to try to get it to boot with the microcode. No good.

Last edited by andrekp (2014-10-27 13:02:58)

ewaller · 2014-10-27 15:13:05

All I meant was that, if the boot partition was not mounted when you installed the software that that the files would be written into a directory called /boot on your root file system. This is normally the mount point where the boot partition is grafted into the root directory tree. The point is, that /boot in a running Linux system is not used for anything -- except to update the boot partition. At boot time, before there is a running Linux kernel, all of the files must be in the partition from which you booted. That you are managing the boot partition from Ubuntu is fine. I am trying to verify that Arch has been able to actually write the needed files to the partition from which you boot, not just the directory called /boot inside of Arch. It looks like you okay.

andrekp · 2014-10-27 15:58:44

ewaller wrote:

All I meant was that, if the boot partition was not mounted when you installed the software that that the files would be written into a directory called /boot on your root file system. This is normally the mount point where the boot partition is grafted into the root directory tree. The point is, that /boot in a running Linux system is not used for anything -- except to update the boot partition. At boot time, before there is a running Linux kernel, all of the files must be in the partition from which you booted. That you are managing the boot partition from Ubuntu is fine. I am trying to verify that Arch has been able to actually write the needed files to the partition from which you boot, not just the directory called /boot inside of Arch. It looks like you okay.

Except that it doesn't work, that is...

I am trying to verify that Arch has been able to actually write the needed files to the partition from which you boot, not just the directory called /boot inside of Arch.

I have no idea what you mean here.

To clarify: There are two /boot directories. One in Ubuntu, and one in Arch. When I installed the intel-ucode package, only Arch's /boot was mounted, but not Ubuntu's. pacman put the microcode image into Arch's /boot directory, as I expected.

So far as I know, this is exactly what was supposed to happen, right?

So the problem remains as to WHY I can't get the microcode to load as explained in the Wiki, by appropriately altering the associated grub file, on boot?

The Wiki says to install the package, them modify your bootloader to load it. That's what I have done. Is there another unstated step, such as modifying (adding a hook, or something) the mkinitcpio.conf and rerunning that, or...?

ewaller · 2014-10-27 16:16:36

To clarify. There should be a /boot directory in Ubuntu, and there should be a /boot directory in Arch. Those directories should be empty as they will be used as mount points. Neither operating system depends upon, or cares about the contents of /boot. It is not used in the running of Linux.

There should be exactly one boot partition. It contains the one boot loader, all of the initrds for both operating systems and the one configuration file for the boot loader. It is used only at boot time until control is passed to a Linux kernel. Depending on the OS, the kernel will be told to use either your Ubuntu root partition, or your Arch boot partition.

Once the chosen Linux system boots, its /etc/fstab file will control how partitions are mounted. Both Ubuntu and Arch should mount the same (only) boot partition on top of their /boot directory. That will hide anything that is inside the /boot directory, and instead will show the contents of the boot partition when that directory is accessed.

Why, if Linux does not care about what is in /boot do we worry about mounting the one, single, boot partition on /boot? It is so we can update the files in the boot partition. Both OSes need this capability. If you don't, then, when Arch updates its kernel and the drivers in /lib, it won't succeed in updating the kernel that actually gets loaded by the boot loader. This is bad (TM). Even though Arch is not updating the configuration file, Arch must have access to the same (only) boot partition as does Ubuntu. Likewise, Ubuntu needs access to the boot partition as well so it can do its upgrades, including the boot loader configuration.

I have a feeling that the Arch kernel on the boot partition is not the same kernel you have installed in your Arch installation. I think the kernel you need is in the /boot directory. Not the boot partition. This is what would happened if you updated the kernel when the one boot partition was not mounted on /boot during an upgrade.

Trilby · 2014-10-27 16:17:30

Your parititioning and all that is fine. Ewaller's concern have been addressed, and they are not the cause of your issue. But I think I do see the cause. You edited the line wrong.

If you edit the grub.cfg directly, you put both initrds on the same line as you have done. But the wiki indicates that if you are making a grub.d profile (as you are doing) they should each be on their own line each preceded by "initrd". Follow this section of the wiki.

EDIT: OOPS! nevermind this. I missread the wiki page there. The 'diff' syntax threw me off. Have you tried the other method of editing the grub.cfg directly? I have no idea how grub-mkconfig works - it seems odd to me that the ubuntu grub could find and list img files on a partition that is not even mounted when ubuntu is running.

Last edited by Trilby (2014-10-27 16:20:32)

andrekp · 2014-10-27 16:48:13

Actually, I just wrote a long-ish explanation of something I found, but the forum timed me out and it was lost... I'll try a shorter one here:

I have two laptops, Laptop A and Laptop B.

Laptop A has Ubuntu 12.04 and Arch. It kernel panics, as described here, when I boot loading the microcode. It HAS a processor affected by the microcode.

I cloned laptop A's Arch install over to laptop B. Laptop B has a processor that IS NOT affected by the microcode (not on Intel's list). Laptop B booted fine with the Grub changes to load the microcode early. (though obviously, it didn't load any revision, because it's not an affected processor)

So what's the difference?
laptop A has Ubuntu 12.04, while Laptop B has Ubuntu 14.04. Ubuntu 14.04 uses a slightly more up-to-date Grub2.

So as a test, I put the hard drive from Laptop B into Laptop A. Laptop A booted properly and loaded the microcode revision as expected.

This strongly suggests that the problem is in Grub2. Specifically, that older version(s) of Grub2 (which may be current versions in other distros) cannot load the microcode.

Obviously, this will be a problem for anyone that dual boots and uses another distro that uses an older Grub2. I don't know where the change in Grub2 occured.

BTW: While this might technically be deemed a Ubuntu problem and dustbinned as not relevant to Arch, I don't think it should be as there are likely a LOT of Arch users who use other distros in a dual boot situation.

Last edited by andrekp (2014-10-27 18:08:42)

Arch Linux

#1 2014-10-26 16:18:10

Microcode problems

#2 2014-10-26 16:38:41

Re: Microcode problems

#3 2014-10-26 16:47:35

Re: Microcode problems

#4 2014-10-26 17:26:54

Re: Microcode problems

#5 2014-10-26 18:30:50

Re: Microcode problems

#6 2014-10-26 19:47:48

Re: Microcode problems

#7 2014-10-27 12:46:03

Re: Microcode problems

#8 2014-10-27 12:54:58

Re: Microcode problems

#9 2014-10-27 15:13:05

Re: Microcode problems

#10 2014-10-27 15:58:44

Re: Microcode problems

#11 2014-10-27 16:16:36

Re: Microcode problems

#12 2014-10-27 16:17:30

Re: Microcode problems

#13 2014-10-27 16:48:13

Re: Microcode problems

Board footer