Skip to main content ↑ ↓
Topic: [SOLVED] Installation going wrong, efi issues (?). Help! (Read 1784 times) previous topic - next topic
0 Members and 6 Guests are viewing this topic.

Re: Installation going wrong, grub issues. Help!

Reply #15 –
Quote from: tintin – on
On my PC :
Code: [Select]
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.

Re: Installation going wrong, grub issues. Help!

Reply #17 –
Quote from: mrbrklyn – on

.../...  Your UEFI bootloader needs to be reset.

This might need to be fixed in the hardward interface.
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

Re: Installation going wrong, grub issues. Help!

Reply #19 –
Quote from: mrbrklyn – on
set up as a removable disk on a permanent hard drive?

A permanent partition on my hard drive :
Code: [Select]
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

Re: Installation going wrong, grub issues. Help!

Reply #20 –
Quote from: mardiyah – on
Imho the more common/standard is mnt efi at /boot/efi e.g /etc/fstab
Code: [Select]
.
 # <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




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

Quote from: mrbrklyn – on
Quote from: Gh0st – on
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

Code: [Select]
Grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB /dev/sdb
Does anyone have any advice? What could be going wrong?



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.


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?

Re: Installation going wrong, grub issues. Help!

Reply #21 –
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"
"Wer alles kann, macht nichts richtig"

Artix USE="runit openrc slim openbox lxde gtk2 qt4 qt5 qt6 conky
-gtk3 -gtk4 -adwaita{cursors,themes,icons} -gnome3 -kde -plasma -wayland "

Re: Installation going wrong, grub issues. Help!

Reply #22 –
Quote from: lq – on
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

Re: Installation going wrong, grub issues. Help!

Reply #23 –
Quote from: Gh0st – on
... when one can osprobe to find all operating systems anyway?

If it's practical, simple and easy, why do you have to keep writing about it?
"Wer alles kann, macht nichts richtig"

Artix USE="runit openrc slim openbox lxde gtk2 qt4 qt5 qt6 conky
-gtk3 -gtk4 -adwaita{cursors,themes,icons} -gnome3 -kde -plasma -wayland "

Re: Installation going wrong, grub issues. Help!

Reply #24 –
Quote from: mrbrklyn – on



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.

Quote
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?

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.

Re: Installation going wrong, grub issues. Help!

Reply #25 –
Quote from: lq – on
Quote from: Gh0st – on
... when one can osprobe to find all operating systems anyway?

If it's practical, simple and easy, why do you have to keep writing about it?

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.

Quote from: mrbrklyn – on

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.

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!
 

Re: Installation going wrong, grub issues. Help!

Reply #26 –
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.

Quote from: srs5693 link=https://bbs.archlinux.org/viewtopic.php?id=166418 date=1708419097


My suspicion is that you've got Gigabyte's absolutely abysmal Hybrid EFI firmware. This is a true EFI implementation, but it exists as a layer atop a traditional BIOS. That's not the real problem, though; the problem is that this EFI is so bug-laden that it's nearly useless. My page on the subject describes the details. One of these details is that the board tends to forget any NVRAM entries made with efibootmgr or bcfg, just as you describe.

On my own system, giving the boot loader of choice the filename EFI/BOOT/bootx64.efi works around this problem. I realize you say you've tried that without luck, but you could try again -- perhaps there was a typo in your first attempt at moving the file, for instance. Also, be sure to copy any support files that you need. I don't recall offhand what support files Arch's implementation of GRUB 2 needs, but if it needs anything at all, be sure to copy them -- or rename GRUB's original directory and grubx64.efi within that directory.



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