Full system update after more than a year - the experience


(kepszlok) #1

I sold one of my older Thinkpad to a friend. He’s a very basic user, so this machine gets a -Syu only once or twice a year. In this case, it had kernel 4.12 and systemd 231.

So, i ran -Syu. It went fine, just about everything got updated. Then it was not able to boot.

It tried to boot the new kernel with and old systemd 231, because the modules did not get properly updated. I had to chroot in from the live media, and run mkinitcpio -p linux and update-grub commands. So initrd generation did not happend.

While booting with correct systemd, it showed red error message about failed module load. I figured out, acpi-call and vhba-module was unavailable as module.

I had to switch from the already installed acpi-call and vhba-module packages to acpi-call-dkms and vhba-module-dkms packages. After that, everything worked fine.

What’s the point of the non dkms acpi and vhba packages?

pacman.log (181.8 KB)


(Luca Giambonini) #3

dkms packages are there so that our users can use different kernel instead of the one we provide. Is strange that you had to use dkms packages to make it run.
The update problem we are aware, that’s why we need a new ISO out very soon.


(kepszlok) #4

Not just for me. This problem was present in that Thinkpad, my Thinkpad, my desktop (with both Chakra installation on it) and at least 2 more Chakra users of i know.

That’s 6 different place, just from here. So i think it’s safe to assume that this issue are not a separated case.

Without the dkms version of those packages:
sudo systemctl status systemd-modules-load.service

● systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static; vendor>
   Active: failed (Result: exit-code) since Sun 2019-02-17 14:28:01 CET; 3min 40s ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
  Process: 213 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/F>
 Main PID: 213 (code=exited, status=1/FAILURE)

There is a way to reproduce this situation:
Do a fresh installation with Goedel then upgrade it. Then most likely you will see an error during the first part of the boot process.
-there may be other ways too, i did not checked this with current RC3 iso.


(totte) #5

It does sound a lot like this issue:


(Luca Giambonini) #7

yes seems really a problem, I will look on it.

One problem is that the pacman mirrorlist selected is worng, the installed kernel is (4.12.4-1) instead of 4.19.


(kepszlok) #8

Yes, i (and others too) was not aware of the mirror situation at the time. Other people are also did the same, they also had to run mkinitcpio by hand. See my post about this: https://community.chakralinux.org/t/chakra-2017-10-iso-users-shoud-be-warned-about-dropped-mirrors/8292/2

So that can be the cause of these init problems.

But this is not realted to the acpi and vhba problem. Since we know about the mirror problem, we dropped the bad one (btw, my computers at home was not affected by the mirror problem but i still got that module error). After that we did a proper -Syu update but the module error was still present. Then we all switched to the -dkms versions and the problem was solved.


(totte) #9

The issues regarding the erratic mirror and the failing kernel upgrade are already covered in separate issues (and several topics). The pertinent question here is:

According to Wikipedia:

Dynamic Kernel Module Support ( DKMS ) is a program/framework that enables generating Linux kernel modules whose sources generally reside outside the kernel source tree. The concept is to have DKMS modules automatically rebuilt when a new kernel is installed.

An essential feature of DKMS is that it automatically recompiles all DKMS modules if a new kernel version is installed. This allows drivers and devices outside of the mainline kernel to continue working after a Linux kernel upgrade.

Another benefit of DKMS is that it allows the installation of a new driver on an existing system, running an arbitrary kernel version, without any need for manual compilation or precompiled packages provided by the vendor.

DKMS was written by the Linux Engineering Team at Dell in 2003. It is included in many distributions, such as Ubuntu, Debian, Fedora, SUSE, and Arch. DKMS is free software released under the terms of the GNU General Public License (GPL) v2 or later.

DKMS supports both the Rpm and Deb package formats out-of-the-box.


(Luca Giambonini) #10

Ok, let’s dive into this problem. I installed non dkms version on my current machine and I don’t see any issues. You need to provide me more information about the problem.

So

  1. run systemctl status systemd-modules-load
  2. get the PID number and run: journalctl _PID=1234

report here the output of the above command. More details here:


(kepszlok) #11

I tried to replicate the problem, but i failed.

On virtualbox:
-installing RC3 and updating it: no module problems

-installing Goedel and updating with proper mirror: Goedel dies during system update, the screen switches to a black screen with a cursor. After restarting it (when it stopped working with the hdd), it tried to boot with the new kernel using the old systemd 231, so no boot… I assume the init generation did not happened, but i did not checked the logs from a live system. I can, if it matters.
I tried this twice with Goedel, but both resulted the same.

On my laptop:
-i switched back to non dkms version of the packages, and there are no module problems

So this problem may solved itself somehow.


(tom) #12

the pacman upgrade is cause for this problem because pacman 4 used a different way to trigger mkinitcpio as pacman 5 but pacman 4 was replaced by pacman 5 and so was mkinitcpio not triggert.


(kepszlok) #13

Ahh, that was the problem! Thanx.

I was able to reproduce the problem. Steps:
Install Goedel to virtualbox.
Set the proper mirrors in mirrorlist.
Switch to root terminal, then update it with manual init generation:

pacman -Syu --noconfirm && mkinitcpio -p linux && reboot

After the reboot, you will see the module error in early boot.

$ systemctl status systemd-modules-load
● systemd-modules-load.service - Load Kernel Modules
Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static; vendor>
Active: failed (Result: exit-code) since Sat 2019-02-23 19:23:37 CET; 17min ago
Docs: man:systemd-modules-load.service(8)
man:modules-load.d(5)
Process: 290 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/F>
Main PID: 290 (code=exited, status=1/FAILURE)

febr 23 19:23:36 kepsz-pc systemd-modules-load[290]: Failed to find module ‘acpi_call’
febr 23 19:23:36 kepsz-pc systemd-modules-load[290]: Inserted module ‘crypto_user’
febr 23 19:23:37 kepsz-pc systemd-modules-load[290]: Failed to find module ‘vhba’
febr 23 19:23:37 kepsz-pc systemd-modules-load[290]: Inserted module ‘vboxguest’
febr 23 19:23:37 kepsz-pc systemd-modules-load[290]: Failed to find module ‘vboxsf’
febr 23 19:23:37 kepsz-pc systemd-modules-load[290]: Inserted module ‘vboxvideo’
febr 23 19:23:37 kepsz-pc systemd[1]: systemd-modules-load.service: Main process exited>
febr 23 19:23:37 kepsz-pc systemd[1]: systemd-modules-load.service: Failed with result >
febr 23 19:23:37 kepsz-pc systemd[1]: Failed to start Load Kernel Modules.
Warning: Journal has been rotated since unit was started. Log output is incomplete or u>

$ journalctl _PID=290
– Logs begin at Sat 2019-02-23 19:08:33 CET, end at Sat 2019-02-23 19:40:47 CET. –
febr 23 19:23:36 kepsz-pc systemd-modules-load[290]: Failed to find module ‘acpi_call’
febr 23 19:23:36 kepsz-pc systemd-modules-load[290]: Inserted module ‘crypto_user’
febr 23 19:23:37 kepsz-pc systemd-modules-load[290]: Failed to find module ‘vhba’
febr 23 19:23:37 kepsz-pc systemd-modules-load[290]: Inserted module ‘vboxguest’
febr 23 19:23:37 kepsz-pc systemd-modules-load[290]: Failed to find module ‘vboxsf’
febr 23 19:23:37 kepsz-pc systemd-modules-load[290]: Inserted module ‘vboxvideo’

So that’s the problem. - at least for older installations.
Most of pacman log are here: pacman.log (63.6 KB)


(system) automatically bumped #14