You are not logged in.
After reading last news on archlinux.org about new style on uploading microcode to the CPU I desided to upgrade all my machines with the latest one. My servers have almost grub-legacy as boot loader and there is a problem with grub-legacy - it does not load microcode. Only one machine loads microcode with syslinux.
I cannot upgrade grub-legacy to grub2 and cannot replace it with syslinux due reiserfs.
How can I use intel-ucode.img with grub-legasy ?
...
initrd /boot/intel-ucode.img
initrd /boot/initramfs-linux.img
...
This does not work. It loads both images (it prints that it loads them) but dmesg does not show any microcode update records.
Offline
I haven't used grub-legacy for quite a while, but I'm pretty sure the syntax for multiple initrds was to list them on the same line separated by a space:
initrd /boot/intel-ucode.img /boot/initramfs-linux.img
This does match the remaining documentation as seen here.
If you can confirm this, we can add it to the microcode wiki page.
Last edited by Trilby (2014-10-24 10:55:45)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I haven't used grub-legacy for quite a while, but I'm pretty sure the syntax for multiple initrds was to list them on the same line separated by a space:
initrd /boot/intel-ucode.img /boot/initramfs-linux.img
This does match the remaining documentation as seen here.
If you can confirm this, we can add it to the microcode wiki page.
I can confirm only that synax "initrd /boot/intel-ucode.img /boot/initramfs-linux.img" is wrong and leads to kernel panic with "Unable to mount rootfs bla-bla-bla"
The sintax I described above is right but microcode does not load and boot process writes that it uses intel-ucode.img and then initramfs-linux.img. I suspect that this is grub-legacy "feature" witch is not compatible with intel-ucode.img image. So I have to use iucode-tool from AUR to load microcode in /etc/rc.local :-(.
B.t.w. what's wrong in loading microcode at rc.local on later stage of system start process then using intel-ucode.img in boot-loader ?
Offline
B.t.w. what's wrong in loading microcode at rc.local on later stage of system start process then using intel-ucode.img in boot-loader ?
On Atom N270 machines, the kernel will disable hugepages due to a hardware bug. Applying the microcode late does nothing about it, because corruption in RAM might already happen before the new microcode takes effect. But applying the microcode early, the kernel will not disable hugepages.
Then there's the reason why microcode handling was changed in Arch - if you do a late microcode update on Haswell machines, the system will crash. The only way to avoid that is to load the microcode early.
Last edited by Gusar (2014-10-24 14:46:27)
Offline
warm wrote:B.t.w. what's wrong in loading microcode at rc.local on later stage of system start process then using intel-ucode.img in boot-loader ?
On Atom N270 machines, the kernel will disable hugepages due to a hardware bug. Applying the microcode late does nothing about it, because corruption in RAM might already happen before the new microcode takes effect. But applying the microcode early, the kernel will not disable hugepages.
Then there's the reason why microcode handling was changed in Arch - if you do a late microcode update on Haswell machines, the system will crash. The only way to avoid that is to load the microcode early.
Ok, it happens . Actually more effective way to update microcode is to upgrade BIOS. So more complex answer is: someone should upgrade microcode. Firs of all he should do BIOS upgrade, if this imposible or there is no new BIOS or newest BIOS does not contain new microcode then he should try Intel utilites to upgrade microcode in ROM (updated only microcode blocks with no BIOS upgrade), if it fails or imposible then use microcode image at early boot time, if it is imposible due some reasons then post-boot microcode update should be used. If there are no problems with CPU work then no need to load new microcode until some related to microcode bug is not found.
Offline
Did you find a solution on this? I am also using grub-legacy and applying
initrd /intel-ucode.img /initramfs-linux.img
in /boot/grub/menu.lst leads to kernel panic.
Note: I have a seperate /boot partition, that's why /boot is missing in front of intel-ucode.img and initramfs-linux.img
Offline
What I'd try is remove the initrd line completely, then add this to the end of the kernel line:
initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux.img
(adjust accordingly if /boot is on a separate partition, of course)
Offline
What I'd try is remove the initrd line completely, then add this to the end of the kernel line:
initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux.img
(adjust accordingly if /boot is on a separate partition, of course)
Thanks for the try but this didn't work either. Kernel panic again.
Offline
as described here you could use cat to build a combined initrd image, that way you only need to load one cpio image.
Last edited by Asseon (2014-10-25 09:45:26)
Offline
...you could switch to syslinux if you prefer a minimal boot loader but I think that sentiment is just silly. Grub works just fine and only installs to 7.3 MiB.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Never mind, I switched from grub-legacy to grub...
Offline
Same problem here, still looking for a solution.
Offline