I apparently screwed up my Arch Linux system by inadvertently updating the kernel, but not the boot partition. So, for example:

pacman -Q linux  -> results in 4.20.arch1-1
uname -a -> results in 4.19.4-arch1-1-ARCH 

I am not sure exactly how this could be. If I look in my /boot directory, it has the three files initramfs-linux-fallback.img, initramfs-linux.img and vmlinuz-linux and the first two of these were recently updated and the last is dated when I installed the system several weeks ago. So, what exactly is out of sync? My vmlinuz-linux is out of sync with my kernel in the root partition?

The result of this is that the kernel is no longer finding my network device for some reason. I am not sure how this happened, the only command that I did that seems relevant was:

sudo pacman -Syu

I thought this command was only supposed to update the package database, not change the kernel.

In any case, my problem now is how to resync the boot partition so that it matches the kernel, or at least make things so that the network device module is being found and loaded, which apparently it is not any more.

My system is set up to boot directly from the motherboard (no intermediate boot loader). However, when I give this command:

# efibootmgr --verbose

I get the result "command not found". Do I need to be in the live boot environment to use this command? How can untangle this mess and get my system synchronized again? Also, how can I avoid this happening in the future? I mean I plan to add a lot of packages, and it will be problematic if the system is updating the kernel and messing up my system every time I add a new package.

  • 1
    You can use pacman -S grub efibootmgrto install efibootmgr. Any invocation telling pacman to upgrade the system will upgrade not only ordinary packages, but kernel packages as well. This is normal behavior regardless of if you use apt, pacman or rpm - they all work similarly. While I'm not completely sure what has happened, making sure everything is mounted and forcing a reinstall of the kernel packages should actually sort this issue out. Commented Jan 8, 2019 at 2:32

2 Answers 2


The solution to this problem is as follows:

  1. Mount the EFI partition (which is a VFAT partition for an EFI stub type of boot in my case) to a convenient directory:

    # mount /dev/nvme0n1p1 /efi

Note that in my case the device has a name like nvme0n1 because it is an M2 drive, but if you are using a SATA drive, the device name might be something like "sda1".

  1. Make a note of the sizes of the boot image files so you can tell the difference between the old ones and the new ones.

  2. Copy the updated boot files from the ext4 partition to the EFI partition (this will overwrite the old boot images):

    # cp /boot/* /efi

  3. Verify that the /efi directory (the VFAT partition) has the new files by checking the file sizes.

  4. Add an empty file to the EFI partition so you can tell the difference between that directory and the /boot directory in the regular (ext4) file tree:

    # cd /efi
    # touch EFI-boot-directory

  5. Add a line in the fstab file that mounts the VFAT partition to the /boot directory. This will shadow the /boot directory in your main Arch root. This will not overwrite the version of the /boot directory on the ext4 drive, but will make it inaccessible. A typical line in the fstab would look like this:

    UUID=4AF7-CA4B /boot vfat defaults 0 0

To find out the UUID for the drive use the lsblk -f command.

  1. Reboot your system to see if it worked and then check your boot directory:

    $ ls /boot

It should show the tag file ("EFI-boot-directory" or whatever name you choose). If the directory does not contain the file, then it means your EFI partition is not getting mounted and you need to re-examine the fstab file.

If the EFI partition is getting mounted automatically to /boot then it should get properly updated whenever you do a system update and your boot images should stay in sync with your installed modules.


There are too many issues to address here, but this won't fit into a comment, so I'll post it here until the question is deleted.

  1. Your /boot was not mounted during the upgrade, so your running kernel has no access to the modules it requires.

  2. efibootmgr is showing "command not found" because you haven't installed it.

  3. Your /boot wasn't mounted for the upgrade because you don't have /boot in your /etc/fstab (or if you do, it is incorrect).

  • @jasonwryan I read the original and it made me laugh. There is a UserScript out there that allows you to ignore specific users (including mods, but that is not a good idea), so if this helps you coming back, please do as I'm ready to give up on Ubuntu and move to Arch (or probably Manjaro as I'm not good enough to go full Arch yet) 0:-) +1
    – Fabby
    Commented Jan 8, 2019 at 23:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .