How can I avoid my boot and kernel partitions getting out of sync?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












3















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.










share|improve this question



















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

    – Adam Waldenberg
    Jan 8 at 2:32















3















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.










share|improve this question



















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

    – Adam Waldenberg
    Jan 8 at 2:32













3












3








3








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.










share|improve this question
















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.







arch-linux kernel boot






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 8 at 1:16







Tyler Durden

















asked Jan 8 at 0:39









Tyler DurdenTyler Durden

1,59242050




1,59242050







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

    – Adam Waldenberg
    Jan 8 at 2:32












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

    – Adam Waldenberg
    Jan 8 at 2:32







1




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.

– Adam Waldenberg
Jan 8 at 2:32





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.

– Adam Waldenberg
Jan 8 at 2:32










2 Answers
2






active

oldest

votes


















0














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.






share|improve this answer






























    -3














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






    share|improve this answer

























    • @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
      Jan 8 at 23:39











    Your Answer








    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f493118%2fhow-can-i-avoid-my-boot-and-kernel-partitions-getting-out-of-sync%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    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.






    share|improve this answer



























      0














      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.






      share|improve this answer

























        0












        0








        0







        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jan 11 at 2:08









        Tyler DurdenTyler Durden

        1,59242050




        1,59242050























            -3














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






            share|improve this answer

























            • @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
              Jan 8 at 23:39
















            -3














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






            share|improve this answer

























            • @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
              Jan 8 at 23:39














            -3












            -3








            -3







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






            share|improve this answer















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







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jan 8 at 9:48









            terdon

            129k32253428




            129k32253428










            answered Jan 8 at 0:51









            jasonwryanjasonwryan

            49.6k14134185




            49.6k14134185












            • @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
              Jan 8 at 23:39


















            • @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
              Jan 8 at 23:39

















            @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
            Jan 8 at 23:39






            @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
            Jan 8 at 23:39


















            draft saved

            draft discarded
















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f493118%2fhow-can-i-avoid-my-boot-and-kernel-partitions-getting-out-of-sync%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown






            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay