There used to be common to preface an example command with either $ or # to indicate whether elevated privileges were needed, or whether the command should be used at the user level. It doesn’t seem as widely used any longer, unfortunately.
And you are partly correct.
From experience I can say that it is - for those new to the syntax - common to assume the prefix is part of the command. I know I did a couple of times when I ventured into the Linux world 
My writing style is usually adding the prefix when the output is essential to the context.
No. Not you. Surely not.
OK, I’ll stop calling you Surely.
You are not wrong.
In bash shell:
# user
bedna@bednaManjaro:~ $
# root
root@bednaManjaro:/home/bedna #
Thanks - appreciate that - I am no Lassie - though first half of my surname - only in Danish - relates the canine - that means no monkeys in my family tree - I am the only fox.
1 Like
Så gør det dig til en rævehund?
1 Like
Yup - And a smart one too - the only fox terrier know to be a Linux sysadmin.
2 Likes
Hey everyone.
Thanks for this great how to.
As a freelancer, I am using my manjaro as my primary workstation.
Now I want to update all my packages and do the grub update to.
I remember the last grub update. Since then I get a message on boot regarding the Encrypted Topic (Can't boot LUKS encrypted install after 2023-03-31 stable update - #7 by philm)
Is there a secure way to get through this procedure?
I am still scared to do the grub reinstall.
I do backups with timeshift and back in time very often.
But restoring and recreat my machine would be a very time consuming task and a big mess for me due to many configurations for my clients.
Should i ignore grub updates in the future?
I am using btrfs and crypto_LUKS.
Any help would be appreciated!
This primer does not account for special use cases as it is only meant to get you started.
btrfs and luks encryption is special use cases - it is impossible to cover everything with a primer.
In such special case like this - I suggest you boot a clonezilla iso and create a cold backup of your system.
1 Like
I suggest you boot a clonezilla iso and create a cold backup or your system.
This is indeed solid advice and has become part of my backup routine, about once a month (and before potentially system wrecking “experiments”) I create an image of my system with Rescuezilla, this has saved my butt on numerous occasions.
2 Likes
followed the guide and after reboot i dropped into grub rescue. Thankfully the Manjaro entry in EFI managed to boot.
Seems like i have been using the backup (disk) entry all this time? Which is now broken. Even when i checked /boot/efi/EFI/boot/bootx64.efi exists.
Another lesson in: don’t fix what is not broken.
Thanks @linux-aarhus and @CGA !
Did the backup with rescuezilla and followed this guide.
Worked without problems!
Some clues for @linux-aarhus in verifying whether the grub-install command should target the device or the partition in a BIOS/GPT system.
I just updated a BIOS/GPT system with Stable 2023-12-23 followed immediately by the grub-install before rebooting. I did some prep work prior to installing the updates. Here was the response to
lsblk -o path,pttype,parttypename | grep -e ‘dos’ -e ‘BIOS’
/dev/sda1 gpt BIOS boot
Also, Gparted showed /dev/sda1 as an 8.00 MiB partition having file system grub2 core.img and flag bios_grub.
I was prepared to target the partition sda1 in the grub-install command if the device sda failed. But then I came across this page –
It describes both BIOS/GPT and BIOS/MBR systems and seems to lump both cases specifically stating “The device is the disk (not a partition)” for the grub-install command. So that is what I did.
It worked. No errors, no problems.
That is the same conclusion I reached after a lot of digging around and testing - then some more testing and hexEditing diskimage files.
grub in BIOS/MBR scenarios has always been installed to the the disk MBR - so there is no doubt how this is done.
The problem comes with BIOS/GPT where early implementations needed grub to target the partition - not the device.
grub has clearly some internal logic which searches the disk for a bios-grub partition and dump the core.img to that partition - but as both @philm’s and my tests showed that even if you leave out the bios-grub partition - grub will dump the boot.img to the protected mbr - then scan the device for the /boot/grub/i386/core.img and continue the loading from there.
Also people might miss out to replace the fallback image if there was any. Calamares will install grubx64.efi as bootx64.efi on x86_64 devices. install-grub will compare before updating and copy it over. This guide doesn’t cover that yet, hence people who have the fallback image selected may end up with grub rescue shell due to not matching config and binary files. Older Grub-EFI images tend NOT to work with newer binaries in some cases.
I have added a note on this - I remember the Arch wiki mentioning creating the $esp/EFI/boot/bootx64.efi as this location may be hard coded with some firmware.
Thank you for pointing out the missing mention on this.
So, you think the core.img is located in / partition, then? I’m wondering if it might end up in sectors #34… when no bios_grub partition has been prepared upfront, as illustrated here:
or only the kernel.img is placed there as in the grub manual it’s mentioned that the core.img is built dynamically:
I will dig some more - but it is strange what is written when no bios-grub is present as this is not consistent with GPT partition table.
Thank you for your time. I don’t mean any harm.
In my own environment, if I add a little bit, I may be able to eliminate everything except the SD card.
$ lsblk -o path,pttype,parttypename | grep -P 'sd\D\d\d?|nvme\dn\d$\d?' | grep -e 'dos' -e 'BIOS'
/dev/sdi1 dos Empty
/dev/sdi2 dos EFI (FAT-12/16/32)
Thanks for this guide, worked perfectly fine for me (EFI system).
Small additional note, in case anyone has the same issue as me: grub-install has a --removable flag that must be specified if the device grub is installed on is an external drive (like a USB SSD).