Well this is embarassing...
I installed the packages linux-zen and linux-zen-headers using sudo pacman -S <packages>. After that I ran sudo update-grub but me being a big dummy didnt run mkconfig. Now when I boot I do so but directly to the bios. Currently using a live usb, and I can chroot using artix-chroot, but I'm not exactly sure what to do now. It's an UEFI system, and I'll post any logs needed to help fix this.
If I can get help with this, it would be very appreciated!
I will post some logs I managed to get>
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 73.3M 1 loop /run/artix/sfs/livefs
loop1 7:1 0 1.1G 1 loop /run/artix/sfs/rootfs
sda 8:0 1 59G 0 disk
├─sda1
│ 8:1 1 1.2G 0 part /run/artix/bootmnt
└─sda2
8:2 1 4M 0 part
nvme0n1
259:0 0 953.9G 0 disk
├─nvme0n1p1
│ 259:1 0 300M 0 part
├─nvme0n1p2
│ 259:2 0 919.7G 0 part /run/media/artix/c8536395-6f76-4dab-a7a5-745aaa596c28
└─nvme0n1p3
259:3 0 33.8G 0 part [SWAP]
The nvme0n1p1 partition would be the boot partition.
Once you have chrooted into the system, re-install grub and you should be good to go.
The following is should work for you if your ESP partition is /boot/efi.
The bootloader ID should be the same as what your current Grub name, otherwise you will have a new entry into the system's UEFI boot menu through efibootmgr and remove the old broken entry.
#efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000
Boot0000* Grub HD(<Number>,GPT,<Partition GUID>,0x800,0x100000)/File(\EFI\GRUB\GRUBX64.EFI)
This is show you the current UEFI boot menu list. Look for a line that contains \EFI\GRUB\GRUBX64.EFI. The bootloader ID is the name after Boot0000* which in this case would be "Grub".
#grub-install --target=x86_64-efi --efi=/boot/efi --bootloader-id=<GRUB name from efibootmgr list>
#grub-mkconfig -o /boot/grub/grub.cfg
I would recommend creating a script with the grub install line for the next time and place in /usr/local/bin/efi-grub-install.sh should you require it again in the future without the hassle of figuring out the correct syntax again.
The results of running the first command are
BootCurrent: 0007
Timeout: 1 seconds
BootOrder: 0007,0008,0006,0001,0000
Boot0000* Windows Boot Manager VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d00000000000100000010000000040000007fff0400
Boot0001* grub VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0006* UEFI OS HD(1,GPT,eafbd316-af50-ba45-a13a-afc5b222e99c,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
Boot0007* UEFI: USB PciRoot(0x0)/Pci(0x8,0x1)/Pci(0x0,0x4)/USB(5,0)/CDROM(1,0x26c8e4,0x8000)0000424f
Boot0008* UEFI: USB, Partition 2 PciRoot(0x0)/Pci(0x8,0x1)/Pci(0x0,0x4)/USB(5,0)/HD(2,MBR,0x0,0x26c8e4,0x2000)0000424f
Is the line Im looking for the one starting with Boot0001 or Boot00006?
EDIT I supopse it would be the line starting with Boot0006, right?
EDIT 2 Using UEFI on the grub install gives the error /boot/efi doesn't look like an EFI partition, same if using 'UEFI OS'
Also, running the mkconfig command gets me this
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/artix/theme.txt
Found linux image: /boot/vmlinuz-linux-zen
Found initrd image: /boot/intel-ucode.img /boot/amd-ucode.img /boot/initramfs-linux-zen.img
Found fallback initrd image(s) in /boot: intel-ucode.img amd-ucode.img initramfs-linux-zen-fallback.img
Found linux image: /boot/vmlinuz-linux
Found initrd image: /boot/intel-ucode.img /boot/amd-ucode.img /boot/initramfs-linux.img
Found fallback initrd image(s) in /boot: intel-ucode.img amd-ucode.img initramfs-linux-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
ERROR: mkdir /var/lock/dmraid
grub-probe: error: cannot find a GRUB drive for /dev/sda1. Check your device.map.
Adding boot menu entry for UEFI Firmware Settings ...
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
done
The efibootmgr list shows that the bootloader ID is "grub" and the line appears to be broken.
Thus once everything is mounted and you have chrooted into the system. It is critical that the ESP path is /boot/efi for the example to address your issue if the path is different then please adjust the "--efi=<PATH>" to your installation setup.
Run:
#grub-install --target=x86_64-efi --efi=/boot/efi --bootloader-id=grub
That should reconfigure the "Boot0001* grub" correctly. Once the grub line shows the complete path to the EFI file, it will work again.
If it just does not work then one would have to use a new bootloader ID name and then clean up stuff afterwards to set the correct default boot order to the "New bootloader ID" and to remove the broken grub entry. Some motherboards have UEFI issues and may need a hammer and rebuild approach the boot menu.
Also run:
#grub-mkconfig -o /boot/grub/grub.cfg
I always run both after a grub update. That way one should not have any bad surprises on the next boot.
Lets assume I somehow chrooted wrong the system. What would be the steps to do so properly?
Your grub-mkconfig -o /boot/grub/grub.cfg output shows that grub is broken.
grub-probe: error: cannot find a GRUB drive for /dev/sda1. Check your device.map.
The error should be addressed once the UEFI boot entry has been corrected or rebuilt and the grub-mkconfig is run again.
Although I do find it puzzling that you have both the Itel and AMD ucodes installed. I would uninstall the ucode that is not correct for the actual CPU that is installed on your system.
First mount the root partition, then once it is mounted, view the /<mount path>/etc/fstab file and mount the rest of the partitions if any exist. The Artix devs have a script called "artix-chroot" from "artools-base" that will mount the important system folders once the root folder is mounted.
#artix-chroot <mount path of system root>
Or one can do it manually like so after root is mounted:
# cd /<path of the root mount>
# mount -t proc /proc proc/
# mount -t sysfs /sys sys/
# mount --rbind /dev dev/
# mount --rbind /sys/firmware/efi/efivars sys/firmware/efi/efivars/
# chroot /<path of the root mount>
Then run the grub commands.
Just to be sure, should I mount the boot or the root partition? I have nvme0n1p1 for the boot an the nvme0n1p2 for root.
Going back again I'm not sure I understood this line:
It is critical that the ESP path is /boot/efi for the example to address your issue if the path is different then please adjust the "--efi=<PATH>" to your installation setup.
I managed to confirm I'm chrooting fine, even used the artix-chroot tool.
The mounts for those NVME partitions would be the following with root mounted on /mnt:
#mount /dev/nvme0n1p2 /mnt/
#mount /dev/nvme0n1p1 /mnt/boot
#cd /mnt
# mount -t proc /proc proc/
# mount -t sysfs /sys sys/
# mount --rbind /dev dev/
# mount --rbind /sys/firmware/efi/efivars sys/firmware/efi/efivars/
# chroot /mnt
If you have a separate home or any other folders I would recommend mounting them as well before the chroot command. Check the /mnt/etc/fstab file to be sure. You should be able to address the UEFI boot menu issue with GRUB and have a normal working environment again.
The ESP path is the root of storage devices EFI folder. If one follow the standard Artix installation then the complete path for the GRUB EFI after it is successfully installed would be:
#/boot/efi/EFI/GRUB
The root of the storage based part of the EFI would be:
#/boot/efi
This is the "EFI System Partition (ESP)". This path can be changed on installation though most do not.
The "EFI/GRUB" partitions are the parts that are seen inside the UEFI boot environment.
But in order to address this it is critical to get the right location or nothing will be fixed.
Just throwing this out there. Rather than having to chroot in, and then mount this and that etc... you may find it easier to create a rEFInd boot USB and then boot from that in the uefi / bios.
All being well you should be able to use that to get into your normal system and then reinstalling grub should be far simpler.
(Consider actually installing rEFInd instead of reinstalling grub, imho it's better!)
https://www.rodsbooks.com/refind/getting.html
Alright, jspaces I followed your steps to the letter and managed to get past the grub install. (grub-install --target=x86_64-efi --efi=/boot/efi --bootloader-id=grub). However, grub mkconfig fails with the same error message as before (no grub drive for dev/sda1). How could I diagnose what is going on?
Please post the efibootmgr output.
I think that the /dev/sda1 is the image booting device and not the NVME which is the root of your system.
Thus I may have erred on that part. The entries should show something like this using your last output as the source:
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/artix/theme.txt
Found linux image: /boot/vmlinuz-linux-zen
Found initrd image: {/boot/intel-ucode.img or /boot/amd-ucode.img} /boot/initramfs-linux-zen.img
Found fallback initrd image(s) in /boot: intel-ucode.img amd-ucode.img initramfs-linux-zen-fallback.img
Found linux image: /boot/vmlinuz-linux
Found initrd image: {/boot/intel-ucode.img or /boot/amd-ucode.img} /boot/initramfs-linux.img
Found fallback initrd image(s) in /boot: intel-ucode.img amd-ucode.img initramfs-linux-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Everything after os-prober line should not affect the boot process for the main OS.
The last line should state "done".
Sure, sorry for the delay, but here it is
Timeout: 1 seconds
BootOrder: 0001,0007,0008,0006,0000
Boot0000* Windows Boot Manager VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d00000000000100000010000000040000007fff0400
Boot0001* grub HD(1,GPT,eafbd316-af50-ba45-a13a-afc5b222e99c,0x1000,0x96000)/File(\EFI\grub\grubx64.efi)
Boot0006* UEFI OS HD(1,GPT,eafbd316-af50-ba45-a13a-afc5b222e99c,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
Boot0007* UEFI: USB PciRoot(0x0)/Pci(0x8,0x1)/Pci(0x0,0x4)/USB(5,0)/CDROM(1,0x26c8e4,0x8000)0000424f
Boot0008* UEFI: USB, Partition 2 PciRoot(0x0)/Pci(0x8,0x1)/Pci(0x0,0x4)/USB(5,0)/HD(2,MBR,0x0,0x26c8e4,0x2000)0000424f
The line with Boot00001 now has grubx64.efi as the efi file, whereas before it had the bootx64.efi file.
BootOrder: 0001,0007,0008,0006,0000
Boot0001* grub HD(1,GPT,eafbd316-af50-ba45-a13a-afc5b222e99c,0x1000,0x96000)/File(\EFI\grub\grubx64.efi)
It looks good. Grub should be present in the boot menu and work all things being equal.
Check the /boot/grub/grub.cfg file for all of your kernels. Look after "### BEGIN /etc/grub.d/10_linux ###" in the grub.cfg file. If they do not run the grub-mkconfig again and check. Once the entries are good then it is time to reboot.
Here is an example from my grub.cfg:
menuentry 'Artix Linux' --class artix --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-6418ae6c-0cc0-452f-9c3c-68ba19f02bb3' {
savedefault
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 6418ae6c-0cc0-452f-9c3c-68ba19f02bb3
echo 'Loading Linux linux-zen ...'
linux /boot/vmlinuz-linux-zen root=UUID=6418ae6c-0cc0-452f-9c3c-68ba19f02bb3 rw loglevel=3 quiet
echo 'Loading initial ramdisk ...'
initrd /boot/amd-ucode.img /boot/initramfs-linux-zen.img
Well, I'm writing to you now from the repaired system :). There is only one thing that I had to do, and that was adding the boot option from the BIOS options. I was under the impression that GRUB would do this automatically. Was I wrong to suppose that or not? It worries me that I might be one update from doing this all again (but at least I know exactly what to do to fix it now).
Both kernels (stock linux and linux-zen) are working fine now.
Besides that, I have no words to thank you enough for your help
@jspaces , you rock. I will also study the software
@gripped mentioned, it might come handy in the future.
PS: I have not seen an option to add code blocks as you did in your replies, how can I post like that?
As far as I know grub-install always will install the EFI as "grubx64.efi".
Normally the name does not matter. This should only be an issue if you have some motherboard with UEFI problems. It was one way to get some poorly configured UEFI motherboards to work to that only recognized certain words to function. One would copy the grubx64.efi to the default UEFI boot location (check manufacturer's documentation) of the motherboard as bootx64.efi. It is also a way to provide another bootable EFI file that should work in case the original grubx64.efi has issues than the motherboard's UEFI boot should be able to see. I have done this on my system as a backup method.
For most motherboard UEFI:
(this location is not written in stone anywhere as far as I know)
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi
or to the root of the "ESP's EFI" folder
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/bootx64.efi
In general though the EFI name should not matter as long as the executable is valid and points to a location in the ESP that grub or what ever boot loader is used can read their files. If grubx64.efi is loaded by the UEFI of the motherboard menu but cannot read the grub folders and files in the ESP then the dreaded grub rescue mode appears. Though the steps to fix that are same; that is chroot, re-install grub and re-configure grub. I make my ESP to be quite large (500 MB) so that I will have no issues with space for stuff. The FAT formatted ESP is not the greatest to keep files in good working order. And for solid state devices one of the worse formats in existence since trim does not exist in it's specification. If not for Microsoft the standard would have been EXT2 which is extremely stable and would prevented many heartaches IMHO.
Since your question was to fix GRUB I did not go now this path regarding rEFInd (refind). I actually use rEFInd as my main boot loader. It is an excellent way to go very similar to how a Mac boots up. It does have some configuration steps but once it is done updates will not affect it like grub. Or at least I have not experienced any. Earlier in it's existence when EFI standards were not quite set, rEFInd failed me and I could not get it going due to rEFInd itself needed to updated to the new standard. The main trick with rEFInd is to make sure of your folder slashes in certain parts for the initramfs are DOS or Windows formatted.
Here is an example of my /boot/efi/EFI/refind/refind.cfg file manual entry for linux-zen kernel:
menuentry "Artix Linux-Zen" {
icon /EFI/refind/icons/os_artix.png
volume 5a71beee-b8c9-cb4d-bbde-dc1ca16a2ed6
loader /boot/vmlinuz-linux-zen
initrd /boot/initramfs-linux-zen.img
options "root=PARTUUID=5a71beee-b8c9-cb4d-bbde-dc1ca16a2ed6 rw rootfstype=ext4 add_efi_memmap initrd=boot\amd-ucode.img net.ifnames=0 quiet"
submenuentry "Boot using fallback initramfs" {
initrd boot\initramfs-linux-ryzen-fallback.img
}
submenuentry "Boot to terminal." {
add_options "single"
}
} Please note the use of the back slash for the initramfs parts. It is very important for stuff to work.
I actually have both grub and rEFInd both installed and functioning since shit can happen and it is not very nice when the computer just blinks at you.
Oh yes, please edit your original post and the mark this thread as being [Solved] in the subject line.
In the future others may experience something similar and may help them get stuff working again with a working solution.
Take care and have fun. Life is too short after all.
https://archlinux.org/news/grub-bootloader-upgrade-and-configuration-incompatibilities/ (https://archlinux.org/news/grub-bootloader-upgrade-and-configuration-incompatibilities/)
I think all the current Artix install iso's have the "old" grub in them. So if you install with UEFI then it all works fine, you update, still fine. But then if you do "update-grub" without also re-installing Grub then the bootloader stops working, at least that is what I found recently with the Mate openrc iso. The Artix iso on a USB allowed me to boot other partitions that were on the drive and set them as default in the BIOS but it wouldn't boot Artix, you have to chroot in and fix it first because of the version mismatch.
That is why I recommend saving the grub-install line used on a system with the correct info, saved to /usr/local/bin/efi-grub-install.sh then run that script every time grub gets updated then do the grub-mkconfig line. It is not the first time a grub update has made a system no longer bootable. Thus it also pays to have a plan B boot method to get back in without chroot repair process. A few times over the years, I have forgotten to run grub-install or ran it incorrectly with a syntax error or bootloader Id change at my own chagrin. Upgrading grub has always given me a moment pause due to remembering those few occasions. Thus one learns methods that minimize the risk of failure trying to make stuff more reliable. By installing grub every and each time it is updated then run the grub-mkconfig is the only way to get through the update with as little pain as possible in my experience.
Amazing contributions everybody - yeah, I will keep an eye out for future grub updates and will take into account the last two posts just to be safe. I think I'll spend some time tomorrow (if I have the time) really studying all the things you have mentioned.
Again, thanks everybody, you saved my life.