How can I avoid my boot and kernel partitions getting out of sync?
Clash Royale CLAN TAG#URR8PPP
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
add a comment |
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
1
You can usepacman -S grub efibootmgr
to 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 useapt
,pacman
orrpm
- 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
add a comment |
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
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
arch-linux kernel boot
edited Jan 8 at 1:16
Tyler Durden
asked Jan 8 at 0:39
Tyler DurdenTyler Durden
1,59242050
1,59242050
1
You can usepacman -S grub efibootmgr
to 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 useapt
,pacman
orrpm
- 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
add a comment |
1
You can usepacman -S grub efibootmgr
to 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 useapt
,pacman
orrpm
- 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 efibootmgr
to 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 efibootmgr
to 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
add a comment |
2 Answers
2
active
oldest
votes
The solution to this problem is as follows:
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".
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.
Copy the updated boot files from the ext4 partition to the EFI partition (this will overwrite the old boot images):
# cp /boot/* /efi
Verify that the /efi directory (the VFAT partition) has the new files by checking the file sizes.
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-directoryAdd 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.
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.
add a comment |
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.
Your
/boot
was not mounted during the upgrade, so your running kernel has no access to the modules it requires.efibootmgr is showing "command not found" because you haven't installed it.
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
Jan 8 at 23:39
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
The solution to this problem is as follows:
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".
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.
Copy the updated boot files from the ext4 partition to the EFI partition (this will overwrite the old boot images):
# cp /boot/* /efi
Verify that the /efi directory (the VFAT partition) has the new files by checking the file sizes.
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-directoryAdd 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.
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.
add a comment |
The solution to this problem is as follows:
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".
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.
Copy the updated boot files from the ext4 partition to the EFI partition (this will overwrite the old boot images):
# cp /boot/* /efi
Verify that the /efi directory (the VFAT partition) has the new files by checking the file sizes.
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-directoryAdd 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.
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.
add a comment |
The solution to this problem is as follows:
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".
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.
Copy the updated boot files from the ext4 partition to the EFI partition (this will overwrite the old boot images):
# cp /boot/* /efi
Verify that the /efi directory (the VFAT partition) has the new files by checking the file sizes.
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-directoryAdd 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.
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.
The solution to this problem is as follows:
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".
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.
Copy the updated boot files from the ext4 partition to the EFI partition (this will overwrite the old boot images):
# cp /boot/* /efi
Verify that the /efi directory (the VFAT partition) has the new files by checking the file sizes.
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-directoryAdd 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.
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.
answered Jan 11 at 2:08
Tyler DurdenTyler Durden
1,59242050
1,59242050
add a comment |
add a comment |
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.
Your
/boot
was not mounted during the upgrade, so your running kernel has no access to the modules it requires.efibootmgr is showing "command not found" because you haven't installed it.
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
Jan 8 at 23:39
add a comment |
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.
Your
/boot
was not mounted during the upgrade, so your running kernel has no access to the modules it requires.efibootmgr is showing "command not found" because you haven't installed it.
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
Jan 8 at 23:39
add a comment |
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.
Your
/boot
was not mounted during the upgrade, so your running kernel has no access to the modules it requires.efibootmgr is showing "command not found" because you haven't installed it.
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).
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.
Your
/boot
was not mounted during the upgrade, so your running kernel has no access to the modules it requires.efibootmgr is showing "command not found" because you haven't installed it.
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).
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
add a comment |
@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
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
1
You can use
pacman -S grub efibootmgr
to 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 useapt
,pacman
orrpm
- 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