That’s more confusing to me.
sdXY
Has been used for ages, not only on arch, but Debian based distros, like Ubuntu wiki…
Just random example
as @Zircon34 points out the example in Ubuntu
Edit: They do give a long explanation and examples
Finally I figured out a solution:
first of all it seems my Acer Laptop is getting caught by this one: https://github.com/rhboot/efibootmgr/issues/19
The issue causes that the altered boot order with efibootmgr -o doesn’t take place.
So what did I do to solve the problem?
I reset my BIOS settings. Then I manually added the correct .efi file (You can see which by typing efibootmgr -v into your console). After that I also altered the boot order in my BIOS settings. Now everything is working fine again.
Thanks all for the support. Hope this may help someone.
6 Likes
Hello guys.
I am so frustrated having my system go down from updates. this is like the 3rd major hiccup for me in last 4 months.
Anyway I know there is documenation to fix the issues but when the documenation doesn’t line up with what i am seeing. it gets confusing fast.
I am following this grub fix post. and doing these instructions to the letter. but things look different and i am just stuck. I can’t seem to google my way out of it.
Articles i am following
and
https://discovery.endeavouros.com/system-rescue/arch-chroot-for-efi-uefi-systems/2021/03/
So i boot from EndeavorOS ISO the latest version. I fdisk -l and mount my RFS to /mnt. however lt shows the following 4 directories on my nvme.
@ @cache @home @log
when i cd to @ i can see my RFS.
So i guess i have to sudo arch-chroot /mnt/@ cause thats where the /proc and /dev directories are etc.
Which also means i need to mount my 512M EFI system to /mnt/@/boot/efi
So i do this and then type sudo arch-chroot /mnt/@
Which then gives me a warning
Warning: /mnt/@ is not a mountpoint. this may have undesirable side effects
Then i try running grub-install and i get an error.
grub-install:error: cannot find device for /boot/grub (is /dev mounted?).
I researched on google as much as i can remounted some paths. grub-install just won’t run without error.
What is the proper documentation to follow that will restore my grub and get my system working agian?
Thanks.
Hello @thud
It looks like your set up is btrfs. You need to follow the instructions to arch-chroot for btrfs. Then you can reinstall grub and update grub. You need to slow down. Read the information and understand what you are doing before doing it. If you don’t understand then you should ask before attempting it. The information is provided.
https://discovery.endeavouros.com/system-rescue/arch-chroot-for-efi-uefi-systems/2021/03/
3 Likes
Thanks for the fix. The thing is fdisk -l only says “linux file system” and doesn’t say BTRFS so i guess i just assumed was in ext4.
The doc doesn’t mention that how to check if you are BTRFS. I thought fdisk would explicitly say if i was BTRFS. I guess i should know my default file system.
Thank you for pointing it out. wasted 3 hours of google searching before i posted and getting frustrated.
Its back to normal now.
1 Like
When you install you have to select the file system. So you may have forgotten as you have to select btrfs otherwise it would be ext4. Yes fdisk -l only shows linux file system. Glad you got it fixed.
would it be a good idea to put grub-install grbu-mkconfig into a packman hook? I would think it’s something that should ultimately be fixed upstream, now I’m wondering if a hook would be a good idea.
I think that’s already been discussed and no.
Unfortunately, I haven’t yet found way to safely automate grub-install that works for all cases.
Wouldn’t that mean a dead ending in any case? Or… aked the other way around: Are you really hopeful to accomplish such a feat?
I wrote this, as per my personal view, and it wasn’t a good idea, even in my individual case (compare my first post with the last one in this other thread):
@dalto I get that automating it I get would be difficult at best. I was going to hand write them on my machines, eventually taking what I would be hand typing in a terminal after a grub update and putting it in a hook. It’s going to look slightly different for each of my different computers, two are legacy BIOS and the rest are uefi.
@ricklinux says this has already been discussed - I need to go back and find the discussion to see what the underlying issues are.
To be clear, you could use hooks to automate on your machines using the specific options you need for your installs. What is hard is for EndeavourOS to automate it in a way that would work for all users.
It is what I referenced above.
I don’t see a good way right now but one could certainly exist in the future. For example, if grub introduced a config file.
It is also possible there is a good way now that I just haven’t discovered yet.
3 Likes
@dalto got it, and thanks for the clarification. yep totally get that it would be very hard for EOS to automate the hook because of the subtle differences in everyone’s machines. On my laptop this is what I have as a hook:
[Trigger]
Operation = Upgrade
Type = Package
Target = grub
[Action]
Description = reinstalling grub after updating ....
When = PostTransaction
Exec = /usr/bin/grubupdatefix
grubupdatefix
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=antergos_grub
grub-mkconfig -o /boot/grub/grub.cfg
Hi I wonder if it is possible to upgrade endeavourOS without the need to manually fix the grub using the live USB. Last time (2 weeks ago) I did an upgrade and then did sudo grub-install but it didn’t work and I had to do it via live USB. Maybe I’m doing something wrong. Can anyone help me please? I really need to upgrade some packages and libraries. Thanks in advance.
you only need to run grub-install when grub package itself updates but there we have exactly the issue with grub 
there are endless possible system setups …
if sudo grub-install was not working you may have not only one boot entry in the nvram of your firmware and it used one not updated… like the default device entry firmware generates for drives where it finds efi installs… to check this you could show efibootmgr output.
1 Like
Thank you very much for your answer, I think that some configuration is not quite right. I was using Garuda Linux before but I find endeavour’s proposal much more attractive.
This is what efibootmgr shows
[ehudd@endeavour ~]$ efibootmgr
** Warning ** : Boot000a is not UEFI Spec compliant (lowercase hex in name)
** Warning ** : Boot000b is not UEFI Spec compliant (lowercase hex in name)
** Warning ** : please recreate these using efibootmgr to remove this warning.
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0005,0004,0003,000A,000B
Boot0000* endeavouros HD(1,GPT,18e39401-0a6f-4e4e-a397-ce0630a5c45c,0x1000,0x100000)/File(\EFI\endeavouros\grubx64.efi)
Boot0003* UEFI: IP4 Realtek PCIe FE Family Controller PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)/MAC(b888e31b1765,0)/IPv4(0.0.0.00.0.0.0,0,0)AMBO
Boot0004* UEFI: IP6 Realtek PCIe FE Family Controller PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)/MAC(b888e31b1765,0)/IPv6([::]:<->[::]:,0,0)AMBO
Boot0005* UEFI: KingstonDataTraveler 3.0PMAP PciRoot(0x0)/Pci(0x1d,0x0)/USB(1,0)/USB(1,0)/HD(2,MBR,0xad1fa572,0x1d05b80,0x10000)AMBO
Boot000a* Realtek PXE B01 D00 BBS(26,,0x0)
Boot000b* TOSHIBA MQ01ABF050 BBS(27,,0x0)
[ehudd@endeavour ~]$