[arch-general] Kernel modules not loaded after Linux update

[srainey at delta-info.com]

>>
>>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.