Am 30.07.2018 um 18:51 schrieb srainey@xxxxxxxxxxxxxx:
Am 30.07.2018 um 15:36 schrieb Shawn Rainey:
Am 22.07.2018 um 11:27 schrieb Peter Nabbefeld:
Hello,
I've updated my installation yesterday, also doing an update of the
Linux kernel to 4.17.8. When starting this morning, kernel modules
rejected to load, so I even couldn't access the internet.
I've downgraded Linux now to 4.17.2, but still have some problems
(probably because I only downgraded the kernel itself).
I cannot find the error message from the service again, sorry, so I
cannot tell You, it had to do with some security parameter not set.
According to the description of kernel downgrading in the wiki, I
should have downgraded linux-headers, too, but these are not in my
package cache - are they included in the kernel package now?
How can I find out, which other kernel modules need to be downgraded?
Kind regards
Peter
This happened to me on 2 installations so far (the only 2 I've done) on
updating the kernel to 4.17.10-1. It looks like the problem is that the
/boot partition was not mounted, as it usually is, during the update
process.
This caused the previously installed kernel to load, and the modules to fail
to load due to version mismatch.
I fixed it by booting to live media, mounting the /boot and / partitions
appropriately and doing arch-chroot to / to install the cached 4.17.10 image
with pacman -U
For now I've also put the /boot partition in my fstab, even though iirc
the wiki recommends against this.
Good luck,
-Shawn
Thank You, Shawn! So, if I understand You correctly, the basic problem
cause seems to be some change in /boot partition handling (i.e. AFAIK
/boot was automatically mounted during kernel installation, but isn't
now for any reason). As a result, probably the old modules are still
there instead of the new ones after the kernel update.
Do You really still need the fstab change after updating the modules? Or
did Youz just change it so You'll be prepared for the next update?
Kind regards
Peter
That's correct at least in my case - I've never had to take any measures to
mount the separate /boot partition when updating before, and it's never been
in my systems' fstab files, but this past week something must have changed.
When the failure initially happened, the /boot directory in the root file system
contained the correct images - they matched checksums with the images from the
linux package. When I booted to the live media and inspected the actual boot
partition, I could see the old images were still there, which led me to the fix.
I added /boot to the fstab mostly as a precautionary measure. I can't say if
it's truly necessary as I'm not familiar enough with the system to know what
changed and caused this breakage. But it should prevent this particular mode
of failure from happening again.
Also apologies for any odd formatting issues - I don't often write to mailing lists.
-Shawn
I may have actually spoken too soon about adding /boot to fstab - my system is not
happy with that configuration (just notice I had an error in the fstab file that
caused it to silently fail). I don't know what to do about updates in the meantime
other than to be careful to make sure the boot partition has the correct images after
each kernel update.
I'm not sure where to go from here - According to logs, the last upgrade I know was
successful was from Jul. 19 (the system rebooted successfully immediately after).
There was then no attempt to restart the system until upgrading on July 27, when the
boot failure occured.
Hi Shawn, thank You for Your answers! Just updated to linux 4.17.11-1
without any problems. Probably it's just been some conflict in 4.17.8.
Kind regards
Peter
