I thought that was exactly what it was supposed to be, because experienced users knows where the stuff is anyway and most likely wont use this.
If not, you are correct.
Since it involves other distros in the checking, I would assume it could be a great feature if it also checks fstab.
How will it handle a live environment?
If you chroot, and the boot is for some reason not getting mounted correctly/not there, what would happen?
A fstab check would fix that, at least the path. Assuming the fstab is not the REASON for the fail, but then find might figure it out instead.
IDK, I feel like it could be done if done cleverly.
cat /etc/fstab | grep 'boot' | awk '{print $2}'
Edit
Wait, that won’t work with cscs setup, hmmm.
But then again the find would fix it in that case…
I feel the idea is there, execution, not so much.
Install-grub: a new way to keep your EFI/MBR in-sync with grub package
Some might not know that when updating the grub package you’re actually only update GRUB partly. This also creates some issues with your system if an older grub got installed but doesn’t match configurations and scripts. This script fixes most of our installation cases. If you have a fancy partition layout or some extra stuff ongoing, it may fail as explained here: Re: [Regression] efi: Don’t display a uefi-firmware entry if it’s not su You can now install the package install-grub from our unst…
The last tip of that tutorial is TO THIS THREAD. xD
Not here to argue, wanted to provide input and ideas.
UEFI systems tend to have a separate partition for the bootloader. On MBR most of the files can be also on the root partition and no extra mountpoint may exist. That is why we search for the path and not a mountpoint. I added /efi support beside the regular /boot/efi folder Manjaro usually ships, cos @cscs mentioned that it is also kind of a standard to use just /efi.
You are already in the manual fixing mode. The script won’t find it and error out.
This script is not for that. It should automate the update without any user interaction. It is used for users who don’t know how grub was installed and also don’t care about it. It is also designed for those who use Calamares auto-partitioning and standard setup. If you want more, you can dig into grub-multi-install ($974) · Snippets · GitLab and postinst.in ($975) · Snippets · GitLab, which is used at Ubuntu. I tried to only get a working essence for now. I’m open for new features covering other cases as I and the community came up with so far …
If we talk about what this script should cover, we mostly talk about the bootloader module of Calamares 3.2.x. There we have two cmds for grub-install:
Most cases of EFI installs should be covered by now. On BIOS side only the variant via MBR so far. GPT I’ve to check again. On the EFI side of things --no-vram was added. The path for the efi executable stays the same, updating the bootloader entry in the nvram just messes with the priorities and invites issues from non compliant UEFI implementation. It’s easier and better to just not deal with that.
Since we don’t support ZFS with our install medias, that option is not yet covered but most likely easy to add.
Reinstallation of Grub on Debian, and SUSE, in particular, seems to do just that every time. I don’t think that can be easily detected in advance; predicted maybe.
Most likely it will change the priority. Garuda for example uses this to detect that:
local current_grub_entry=“$(efibootmgr | awk ‘match($0,/^BootCurrent: ([0-9a-fA-F]{4})$/,out) { current=out[1] } match($0,/^Boot([0-9a-fA-F]{4})*? ([^:]+)\t/,out) { if (out[1]==current) print out[2] }’)”
Then they check with:
if [ "${current_grub_entry,,}" == "garuda" ] && [ "$did_update" == "true" ]; then
should_act_safe=false
fi
And spit out the notice depending of the result like:
if [ "$did_update" != "true" ]; then
garudalib_add_update_notice "The GRUB bootloader could not be updated automatically safely. Steps to prevent any major issues caused by this have been taken automatically, but if possible, you should update your bootloader using 'grub-install'."
elif [ "$should_act_safe" == "true" ]; then
garudalib_add_update_notice "The GRUB bootloader at /EFI/Garuda was updated, but it seems like you are not using the Garuda Linux bootloader by default. If you are using 'rEFInd' bootloader, you can safely ignore this. Otherwise, please change your EFI boot priorities to prioritize the \"Garuda\" bootloader. Running 'grub-install' will do this automatically."
else
garudalib_add_update_notice "The GRUB bootloader at /EFI/Garuda has been updated/reinstalled using 'grub-install'. If this looks correct, no further action has to be taken."
fi
So if the Bootloader-ID differs some other Bootloader entry was used.
Based on @linux-aarhus tutorial we assume grub to be installed on a partition, rather MBR. Well calamares installed on MBR:
[PYTHON JOB]: "Bootloader: grub (bios)"
.. Running ("grub-install", "--target=i386-pc", "--recheck", "--force", "/dev/sda")
.. Finished. Exit code: 0 output:
Installing for i386-pc platform.
Installation finished. No error reported.
.. Running ("grub-mkconfig", "-o", "/boot/grub/grub.cfg")
.. Finished. Exit code: 0 output:
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-6.6-x86_64
Found initrd image: /boot/intel-ucode.img /boot/amd-ucode.img /boot/initramfs-6.6-x86_64.img
Found initrd fallback image: /boot/initramfs-6.6-x86_64-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.
Adding boot menu entry for UEFI Firmware Settings ...
Root filesystem isn't btrfs
If you think an error has occurred, please file a bug report at "https://github.com/Antynea/grub-btrfs"
Found memtest86+ image: /boot/memtest86+/memtest.bin
Found memtest86+ EFI image: /boot/memtest86+/memtest.efi
done
Calamares offers MBR or installing the bootloader to /. The later I may test another day. However it worked just fine:
~ sudo install-grub
Grub will be installed on: MBR
Installing for i386-pc platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-6.6-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-6.6-x86_64.img
Found initrd fallback image: /boot/initramfs-6.6-x86_64-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.
Root filesystem isn't btrfs
If you think an error has occurred, please file a bug report at "https://github.com/Antynea/grub-btrfs"
Found memtest86+ image: /boot/memtest86+/memtest.bin
Found memtest86+ EFI image: /boot/memtest86+/memtest.efi
done
I mostly tested Calamares auto-partition with ext4 so far on BIOS and UEFI. So you tell me if some is needed regarding BTRFS. Be brave and have the live-ISO at hand if you break things
grub-btrfs is a plugin to create snapshots on package updates and put those easy to select into your grub menu. So BTRFS needs to been tested still. So who wants to go first? @anon6547204 here is your chance to enlighten us Pro-Tip: Use a virtual machine, install Manjaro on it similar to your live setup and try stuff there first.
As this will likely happen so infrequently, it probably isn’t a priority, for now. A few well placed warnings would probably suffice. Maybe a paragraph somewhere explaining that the boot order needs to be reset.