Hello. So I've decided to install Artix on my system after a good while of consideration, with s6.
I'm at the point where everything I would want for it is fully well configured. I have cross referenced a bunch of guides, and triple checked all my commands.
I am at the point of installing the boot manager, which I chose as Grub. You know, the average
Grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB /dev/sdb
Grub-mkconfig -o /boot/grub/grub.cfg
Thing is, it goes on successfully. It runs without issue. I go check efibootmgr, sure enough my new Artix is there too. I exit chroot, its still there.
I reboot. Its not there anymore. I enter the same installation media that told me it was installed 2 seconds ago, and it doesn't show up in efibootmgr. I redo the grub-install cmd and sure enough, its back.
Does anyone have any advice? What could be going wrong?
What a weird thing, which hardware are you using out of curiosity?
Since you are not booting off of nvme, does it work if you install it as legacy? (e.g. without /boot partition)
Assuming you followed the guide in the wiki normally the grub-install command is:
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub
so
--efi-directory=/boot/efi
and not
--efi-directory=/boot
If following the guide you created the efi partition and mounted it like so:
mkdir /mnt/boot/efi (UEFI)
mount /dev/disk/by-label/ESP /mnt/boot/efi (UEFI)
So your fat efi partition is at /mnt/boot/efi and not /mnt/boot
Not sure if this could be the problem. I have in the past mounted the efi partition at /mnt/boot myself, but I know that by default it's /mnt/boot/efi.
Strange indeed. If the NVRAM is being cleared on a reboot that sounds like a hardware issue, not an installation issue. Although weird stuff can happen with software like grub-install or refind-install. I think refind-install in particular expects a /boot/efi directory, if it sees just /boot it will only pretend to work - no idea why, but it's not relevant here anyway I guess. What happens if you try to manually create the entry with efibootmgr? In your case something like:
efibootmgr -c -d /dev/sdb -p 1 -l '\boot\grub\grubx64.efi' -L 'GRUB' -u
Of course you'll need to change the path, partition, and other details if they're different.
Well, I'm currently using a 1Tb HDD for it, ATX Z390 motherboard with a 13th gen Intel and RTX4060 but that's not too relevant.
I'd rather use GPT/EFI than legacy, and I've followed all steps for it. I could try eventually though.
Well, I've followed some other guides. I have been mounting it to /boot rather than /boot/efi so the commands correct from what I can see here.
This looks like it might do the trick! I'll go ahead paste that through once I get back home to my workstation.
I had the same problem in boxes with windows, where its EFI entry takes precedence over grub. Post the output of efibootmgr.
I'm still not at my machine yet, but I'll post some outputs to recommended commands as well as this soon enough.
In the meantime, my human recreation of the output;
I am making this on a machine that has:
- 2 windows systems, one EFI, one BIOS, on separate disks (SSD 2TB, HDD 2TB)
- 1 Artix Linux system, installed on its own separate 1TB HDD.
Before running grub-install, efibootmgr shows something along the lines of;
0001; UEFI Windows
0002; UEFI Kingston Datatraveller 3.0 (my USB)
0003; UEFI Kingston Datatraveller 3.0 USB key (USB again)
I run grub-install, and it seems to add another entry with ID 0000. After letting the install fully go through, it ends up being ordered in this respective order;
0000; ARTIX (or whatever I set the bootloader ID to) (Points to /boot/grub/grubx64.efi)
0001; UEFI Windows
0002; UEFI Kingston Datatraveller 3.0 (my USB)
0003; UEFI Kingston Datatraveller 3.0 key (USB again)
I restart, and it goes right back to the first sequence I showed; the 0000 entry just vanishes inexplicably. Bear in mind and reminder again, this is on a separate HDD to any Windows machines to begin with. And it's not an entry randomly going infront of the Artix one in the boot order, it just straight-up vanishes without a trace.
There's no issue with /dev/sdb1 (boot partition). I remount it, it has everything the grub install needed, and the data I respectively ordered is definitely on it. I have also re-done the grub-install command with --rechecks about 4 times now.
I do need to mention though. Just before I left my workstation, I noticed there's a button in the installation media's menu which allows me to scan for bootloaders. I managed to find two (?) for some reason, GRUB entries (its likely because I may have accidentally installed it with 2 different IDs when I did grub-install a few times). Trying to boot either up comes with an error which I'll once again have to get home to print out to y'all, but for now, it was something like;
Error: file normal.mo not found (missing module?)
I looked around the internet telling me this is due to incorrect UEFI installations configured by accident for it to be using legacy mode, but I swear I've installed everything properly. The partition is an EFI system, the boot media is booted into EFI, it's mounted correctly at /boot, the grub-install command is correct, and I've ran mkinitcpio and grub-mkconfig a bunch of times with the correct parameters too. What's up? How exactly do I make sure I have these modules /.mo files?
Your problem is indeed weird, with the vanishing EFI boot entries. Can you try installing a non-base s6 ISO like e.g. lxde-s6 from stable branch? I'm curious to see if calamares handles this correctly.
Last time I tried Calamares, it wouldn't allow me to create LVM partitions for my system and would crash, so I decided to do it manually with the base ISO in the first place. That was on a test VM though. Base managed to work well on said VM though, so all the more confusing.
I'll go ahead give it a shot on bare-metal as a last ditch resort if all else doesn't work here, thanks for the recommendation
Any thoughts on the module not found bit at the end of my message?
Right, I just checked. Yep. I can see the media detects a UEFI boot on my /dev/sdb1 disk. This is the exact error:
error: file '/grub/x86_64-efi/normal.mod not found. Entering Rescue mode
All of the .mod files are in the mounted drive's /grub/x86_64-efi/ directory. Including normal. I don't know if its of note, but all files have a ~ at the end before the d in .mod.
normal.mod~ exists, normal.mod doesn't
Is that really the issue? Why tf has grub done this?
I renamed all the files with a bulk command. My install now boots and fully works, all the way to a sweet DE!
Issue is, until anyone manages to get a lead on it, the mysterious vanishing act of that damned missing boot still haunts me. I re-did the efi entry, even did it myself manually as a helpful user here hinted, it still just poofs after reboot.
Imho the more common/standard is mnt efi at /boot/efi e.g /etc/fstab
.
# <file system ID> <mount point> <type> <options> <dump> <pass>
8 UUID=0E18-1644 /boot/efi vfat umask=0077 0 2
9 UUID=1171e3f3-1b89-45c9-be8e-73064998caf5 / ext4 defaults,noatime 0 1
it's esp. mandatory on Windows' partition boot existence
not clarified what sdb (sda too) is, can:
$ sudo gdisk /dev/sdb
$ sudo gdisk /dev/sda
?
or $ sudio lsblk -f
My experience is that for some odd reason, systems do not like this -
First /dev/sdb ? don't you need the partion?
It seems to have settled on
/dev/sda3 499M 296K 499M 1% /boot/efi
with your own partition - but /boot/efi
ALSO - FWIW sync the partions before rebooting.
On my PC :
lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1
├─sda2 5,3G 67% /
├─sda3 134,1G 80% /media/77
├─sda4 41,4M 58% /boot/efi
└─sda5 [SWAP]
You are looking for grub here
error: file '/grub/x86_64-efi/normal.mod not found. Entering Rescue mode
which is wrong I think regardless. Your UEFI bootloader needs to be reset.
This might need to be fixed in the hardward interface.
This is my data partition. :)
I don't know if this answer was intended for me, in any case everything works fine here.
My ACER ES1-732 has a buggy UEFI:
https://askubuntu.com/questions/862946/unable-to-install-ubuntu-on-acer-aspire-es1-533
set up as a removable disk on a permanent hard drive?
A permanent partition on my hard drive :
cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=1c6d01b6-e4b6-4566-a254-674eb70571c9 / ext4 defaults,noatime 0 1
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
UUID=9a1d0fdf-36a0-4fbc-bd99-52c0e23dd5fb /media/77 ext4 defaults,noatime 0 0
UUID=5388ba79-3e30-407b-be68-b5b255de97fb none swap defaults 0 2
UUID=B772-4C60 /boot/efi vfat defaults 0 2
Well, whether common or not, I've done multiple builds where /boot is perfectly OK, and actually some where /boot/efi seems to annoy the system. Everything mounts alright anyway after the bootloader's accessed, it just seems to bugger the efibootmgr entry which doesn't damn stick.
Once I'll get to my workstation I can run that. But I've mentioned somewhere already, and I'll just do my lovely human recreation of what those commands would output;
/dev/sda is a Windows on HDD, partitioned with MBR rather than GPT as far as I'm aware (idk why bootmgr picks it up because of that).
- Its got your average small boot space for BIOS, bios boot flag on
- a large 300GB partition for the main Windows OS
- another 1.7TB allocated to just a separate NTFS partition where I put shared games and media n stuff
/dev/sdb is my fresh Linux build. Its a GPT disk.
- its got a 1gb /boot partition
- the only other partition is an encrypted LUKS partition with the rest of the disk's data, where I have a bunch of LVM parts configured and correctly mounted on the fstab. It all boots perfectly when started up!
/dev/nvme0p1 is a GPT SSD which was mainly made for secondary game/media storage, but I created a basic windows install on for faster gaming.
- its got your average small efi partition
- the main Windows partition, which is 100ish GB
- the rest is just storage space, 1.9GB
No, it seems through guides that command just specifies what root disk needs to be mounted. Every guide I see says not to specify any partition.
How exactly do I do the sync though?
UEFI is just as useful and helpful under GNU Linux as a 10 cubic metre concrete block on your legs when swimming.
Why only one grub is used for all systems with several discs and not the boot menu (one grub for one OS) remains a mystery to me.
"Ceterum censeo M$ esse delendam"
Idk. To me, it seems more redundant; why install 5 bootloaders when one can osprobe to find all operating systems anyway? I don't think I need the 2 strange looking Windows bootmgrs on my system after I get trusty old Grub working. If it fails, boot rescue or USB can be used to fix it in a jiffy.
This is quite offtopic though, there seems to yet be a solution for this disappearing act that my boot entry's pulling on me
If it's practical, simple and easy, why do you have to keep writing about it?
I think you are right but that is for a bios system. I'm just looking at the arch docs at https://wiki.archlinux.org/title/GRUB
man sync
Still, your system is looking in the wrong place and standardinze on /boot/efi usually works.
Firstly, osprobe isn't what this thread is about; works flawlessly on my laptop's baremetal install with Windows which is wonderful. And secondly, it's also worked great on every one of my ~30 Linux test VMs and beyond. The single issue I had aside from this on one of my other of 3 bare-metal devices was troubleshot after 10 minutes of googling.
Again, you've still anything productive to add. I'm asking for help, not opinions. And about my chosen framework, not looking for a replacement. I have nothing against these hints to try some new boot loaders, but I've already looked into my options and have decided this one has the types of features I need, while others may not contain support for the same features.
I see. I might go modify the fstab, change that mount point and see if it works properly, but I have my doubts that's going to fix much. Nevertheless, gotta try everything. Thanks for the help!
I am back here, after post death, to resurrect it with a brief run through with a fix before marking it as resolved. That was truly a brain-melting, unfortunate experience. I'm hoping someone can benefit from this someday!
So, to give an update to everyone's feedback;
Testing around a bit, there was nothing wrong with the directory names/mounting point of my disk. Everything was going as intended; mounted at /boot, EFI directory \EFI.
Further testing using another helpful user's feedback here and some extra research, revealed me trying to use efibootmgr to do ANYTHING to both boot orders and manually trying to add .efi files as entries, both failed entirely. It would still never persist after rebooting, meaning it wasn't a grub issue. It was an efibootmgr issue??
I copied in a efi recovery shell from a github repo and it still couldn't be discovered. Attempting to reach it through the bootloader discovery from the Artix ISO and using the bcfg tool now, I was successfully able to create and reorder the boot entries on THAT in an attempt to circumvent the efibootmgr issue. It still didn't persist after reboot, and no boot entries were visible at all!
It wasn't either software's fault, maybe there's something wrong with how my efi is loaded? I fully updated my firmware, BIOS, etc. I tweaked all BIOS settings I could. Even went back into my OS to remount the efivars directory as rw without any additional parameters, it still wouldn't work!
Literally nothing at all, could make my PC change its' efi variables/list. No software, nothing.
Then when all hope was lost, an obscure post on an Arch Linux forum 11 years ago and buried in dust, descended from the clouds and told me it was a bloody hardware issue. And handed me a brief fix.
By trying to add it manually with efibootmgr, and renaming my .efi from grubx64.efi to bootx64.efi and dropping it in that specific file directory, it finally worked.
What I'm taking away from this is somehow, my new generation motherboard supporting 13th gen Intel (MSI Z790 gaming pro wifi) has some sort of issue similar to the above which is the reason to my pains, and EFI is evil. Alas, after all of that, my singular Linux EFI entry is now up and running and I don't need any others so this inconvenience ends here. /fin. Yay