On AMD systems the microcode update is still handled by the kernel itself assuming the linux-firmware package is installed.
# pacman -Qs linux-firmware
local/linux-firmware 20170622.7d2c913-1
@digifuzzy if your system uses an Intel CPU are microcode updates enabled?
...
You could file a bug report against glibc. Bisecting the issue first would help determine the cause.
I'm using an AMD bulldozer cpu. I'll check.
]]>After upgrading the kernel, I went to reboot and got stopped right at boot with the same "-2" error (init system not found)
I tried the suggestions in...
[SOLVED]Kernel panic init error
[Solved] Kernel panics with "No init found" after upgrade
...without success. I kept getting the same error message.
Only by downgrading glibc to 2.25-7 could I get the system boot restored.
I had to use live cd to:
- downgrade
- re-install filesystem grub mkinitcpio linux
- mkinitcpio -p linux
- grub-mkconfig -o /boot/grub/grub.cfg
After reboot, all was restored.
]]>As can be seen, the only changes made are the removal of the build parameter "--enable-kernel=2.6.32" and a move of upstream commit from
https://sourceware.org/git/?p=glibc.git … 39d3e18369
to
https://sourceware.org/git/?p=glibc.git … e7c0e2a999
At this point, I do not have any ideas for further investigations. Does anyone have a suggestion?
]]>init=/usr/lib/systemd/systemd
for the configurations where systemd needs to be PID 1
]]>$ bsdcpio -iF /boot/initramfs-linux.img
I now have a working system with all packages fully updated, except for the following three packages:
binutils-2.29.0-1 glibc-2.26-3 lib32-glibc-2.26-2
Note that binutils and lib32-glibc depend on the new version of glibc and therefore cannot be updated.
Currently these packages are at these versions:
binutils 2.28.0-4 glibc 2.25-7 lib32-glibc 2.25-7
It seems that mkinitcpio uses the standard c library to compile something, which no longer works with the new version of glibc.
Some answers to your questions:
- The system is x86_64. Note that my computer is a rather old HP elitebook 8540w from 2010.
- The panic occurs immediately after the initial image is loaded, so that is presumably indeed when the system loads initrd.
- My pacman log is rather messy after my binary search experiments. The log from my update on Sunday can be found here:
https://pastebin.com/83Q3Bz87
The full pacman log can be found here (note that I sometimes use yaourt as a frontend, so you may be seeing some artifacts from that).
https://paste.ee/p/H3JCq
- I never run partial updates (except for the binary search I did yesterday)
- I do not run any custom kernels or anything like that. I do have some AUR packages, but these are all user-level packages that - in my mind - could never interfere with the kernel starting process:
acroread 9.5.5-7
btrbk 0.25.1-1
keepass-plugin-rpc 1:1.7.2-1
mathematica 11.1.1-1
mcrl2 201409.1-3
package-query 1.9-2
pamac-aur 5.1.1-3
prover9 2009.11A-2
spotify 1.0.59.395-1
swftools 0.9.2-5
yaourt 1.9-1
yices-bin 2.5.2-1
Does anyone know what the correct path for the init= option should be? Then I can try setting this path manually. I already tried /usr/bin/systemd/systemd and /usr/bin/bash, but both do not work.
]]>After doing a binary search on the updated packages, this seems to be caused by the update of glibc from version 2.25-7 to 2.26-3.
As loqs says, the new glibc seems to be working fine on my system (and presumably most people's since this wasn't an issue I've noticed anybody else posting).
Can you post the results from your search that suggested this was the issue? It might point to something else that wasn't properly updated. Posting your pacman log also would let us know what was updated yesterday. My initial thought is either you are running partial updates or have some package from the AUR or other unofficial source that's causing the problem
]]>