[SOLVED] systemd-modules-load.service: Failed with result 'exit-code'

dakota · 2020-01-26 22:50:08

Prior to updating my system software via pacman, I rsync my primary partitions to a set of backup partitions and then verify that I can boot into those backup partitions.

Sometimes after running pacman, modules fail to load when I boot into my backup partitions. I believe this happens (usually? always?) after a kernel upgrade. I suspect that this is normal and that I'm not really doing what I think I'm doing.

$ lsblk -f
--------------------
NAME FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda                                                                         
├─sda1
│    ext4   1.0         c7c442f2-90d8-4e6a-a735-65cb052f90f5    7.2G    58% /
├─sda2
│    ext4   1.0         981eef61-efaa-4e1d-9775-13260481797f   12.1G    79% /home
├─sda3
│    swap   1           a389724a-e8f3-4c01-8355-3b141a097ef7                [SWAP]
├─sda4
│    ext4   1.0         a23e01c0-2f3f-4db4-81e1-2815f7439b14                
└─sda5
     ext4   1.0         2d1891c1-45eb-4b08-b679-2777e12d7d6f                
sr0

$ cat /etc/fstab
--------------------
## <file system> <dir> <type> <options> <dump> <pass>
## /dev/sda1
UUID=c7c442f2-90d8-4e6a-a735-65cb052f90f5       /               ext4            rw,relatime,data=ordered        0 1

## /dev/sda2
UUID=981eef61-efaa-4e1d-9775-13260481797f       /home           ext4            rw,relatime,data=ordered        0 2

## /dev/sda3
UUID=a389724a-e8f3-4c01-8355-3b141a097ef7       none            swap            defaults                        0 0

## /dev/sda4
# UUID=a23e01c0-2f3f-4db4-81e1-2815f7439b14    /                ext4            rw,relatime,data=ordered        0 1

## /dev/sda5
# UUID=2d1891c1-45eb-4b08-b679-2777e12d7d6f    /home            ext4            rw,relatime,data=ordered        0 2

When I backup my system, I reboot, login as root, and then execute the following script to mirror my primary partitions to my backup partitions (with the exception of those directories which are populated at boot and my fstab -- the fstab on the backup partitions needs to be different).

# cat backup_mirrorDrive.sh 
--------------------
#!/bin/bash
echo "mounting backup partitions..."
mount /dev/sda4 /mnt/mirror
mount /dev/sda5 /mnt/mirror/home
echo "backing up with rsync..."
rsync -aAXHzz --progress --delete --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found","/etc/fstab"} / /mnt/mirror/
echo "unmounting backup partitions..."
umount /mnt/mirror/home
umount /mnt/mirror
echo "all done..."

Then I reboot again, and select "Arch Linux Backup" (root=/dev/sda4) from the boot prompt screen.

I am using Syslinux with GPT. I installed Syslinux with the following command and updated the configuration file.

# syslinux-install_update -iam

# cat /boot/syslinux/syslinux.cfg
--------------------
LABEL arch
    MENU LABEL Arch Linux
    LINUX ../vmlinuz-linux
    APPEND root=/dev/sda1 rw
    INITRD ../intel-ucode.img,../initramfs-linux.img

LABEL archfallback
    MENU LABEL Arch Linux Fallback
    LINUX ../vmlinuz-linux
    APPEND root=/dev/sda1 rw
    INITRD ../intel-ucode.img,../initramfs-linux-fallback.img

LABEL archlts
    MENU LABEL Arch Linux LTS
    LINUX ../vmlinuz-linux-lts
    APPEND root=/dev/sda1 rw
    INITRD ../intel-ucode.img,../initramfs-linux-lts.img

LABEL archbackup
    MENU LABEL Arch Linux Backup
    LINUX ../vmlinuz-linux
    APPEND root=/dev/sda4 rw
    INITRD ../intel-ucode.img,../initramfs-linux.img

#LABEL windows
#        MENU LABEL Windows
#        COM32 chain.c32
#        APPEND hd0 1

LABEL hdt
        MENU LABEL HDT (Hardware Detection Tool)
        COM32 hdt.c32

LABEL reboot
        MENU LABEL Reboot
        COM32 reboot.c32

LABEL poweroff
        MENU LABEL Poweroff
        COM32 poweroff.c32

The fstab on /dev/sda4 is slightly different, of course.

# Static information about the filesystems.
# See fstab(5) for details.

## <file system> <dir> <type> <options> <dump> <pass>
## /dev/sda1
# UUID=c7c442f2-90d8-4e6a-a735-65cb052f90f5	/         	ext4      	rw,relatime,data=ordered	0 1

## /dev/sda2
# UUID=981eef61-efaa-4e1d-9775-13260481797f	/home     	ext4      	rw,relatime,data=ordered	0 2

## /dev/sda3
# UUID=a389724a-e8f3-4c01-8355-3b141a097ef7	none           	swap      	defaults			0 0

## /dev/sda4
UUID=a23e01c0-2f3f-4db4-81e1-2815f7439b14    /                ext4            rw,relatime,data=ordered        0 1

## /dev/sda5
UUID=2d1891c1-45eb-4b08-b679-2777e12d7d6f    /home            ext4            rw,relatime,data=ordered        0 2

## /dev/sda3
UUID=a389724a-e8f3-4c01-8355-3b141a097ef7       none            swap            defaults                        0 0

If booting into the backup partitions is successful , I reboot back into my primary partitions and upgrade via pacman. If the upgrade includes a new kernel, then modules fail to load the next time I try to reboot into the backup partitions (full text of dmesg).

$ cat dmesg.txt | grep module
--------------------
[    5.344746] systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE
[    5.344920] systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.

$ 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 preset: disabled)
     Active: failed (Result: exit-code) since Sun 2020-01-26 13:14:04 PST; 2min 40s ago
       Docs: man:systemd-modules-load.service(8)
             man:modules-load.d(5)
    Process: 258 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)
   Main PID: 258 (code=exited, status=1/FAILURE)

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

I am expecting partitions sda1/sda2 to act completely separately from sda4/sda5... with their own /boot folders, kernel modules and configuration files. But apparently that's not happening. A kernel upgrade on sda1 seems to affect the boot process on sda4.

I know sda1 and sda4 share the Syslinux bootloader, but I should be able to direct the bootloader to boot which ever partition I want. Shouldn't I?

Cheers,

Last edited by dakota (2020-01-27 06:30:31)

V1del · 2020-01-27 01:56:19

You are loading the same vmlinuz-linux and initramfs-linux for both. i.e. the one on your main partition, so the kernel you are loading is the new one instead of the old one, you have to redirect that properly to actually load the vmlinuz-linux from your backup partition: https://wiki.archlinux.org/index.php/Sy … ux_systems

Last edited by V1del (2020-01-27 01:58:26)

dakota · 2020-01-27 06:29:59

V1del wrote:

You are loading the same vmlinuz-linux and initramfs-linux for both. i.e. the one on your main partition, so the kernel you are loading is the new one instead of the old one, you have to redirect that properly to actually load the vmlinuz-linux from your backup partition: https://wiki.archlinux.org/index.php/Sy … ux_systems

So simple. Thank you very much!

dakota wrote:

I suspect that this is normal and that I'm not really doing what I think I'm doing.

Turns out I was right.

Several times on that page, the wiki states that "Syslinux, by itself, cannot access files from partitions other than its own." This didn't make sense to me because I thought Syslinux was installed
in the MBR (or protective MBR) before the first partition, and that the purpose of Syslinux.cfg was to tell Syslinux on which partition to find the kernel and initramfs images.

I see that it's a little more complicated than that because the Syslinux code can't all fit into the MBR. Only part of it can. The rest is located on a partition. Instructions for where to find the rest of the code are included with the Syslinux/MBR code. I know this is an over-simplification, but once Syslinux loads the rest of its boot code, it is locked onto that partition... unless special chain-loading instructions are given.

I modified syslinux.cfg on both my primary and backup partitions and added it to my rsync exclusion list. I can boot into either the primary or backup partitions.

Cheers,

Last edited by dakota (2020-01-27 06:31:05)

Arch Linux

#1 2020-01-26 22:50:08

[SOLVED] systemd-modules-load.service: Failed with result 'exit-code'

#2 2020-01-27 01:56:19

Re: [SOLVED] systemd-modules-load.service: Failed with result 'exit-code'

#3 2020-01-27 06:29:59

Re: [SOLVED] systemd-modules-load.service: Failed with result 'exit-code'

Board footer