As i said, i am currently booting from the second ESP, and it works. As far as i understand, the script looks and takes the variables and paths from the currently booted system, which is the purpose. Have not checked if it does anything on the first ESP and i do not care, since i do not use its grub anymore, i keep the first ESP only for windows.
1 Like
Aside from an element of redundancy, and ease of maintenance, if for example one opts to replace one OS with another, or wishes to remove an OS from service quickly/temporarily.
Having each OS on a separate disk (with its own ESP) is particularly beneficial in my case, as well; I use removable caddies, which allows me to swap several OS in a multiboot configuration, as needed – quite useful, when available disks (whether hosting an OS or not) outnumber available SATA ports.
If you don’t multiboot, then sure, I can understand how you wouldn’t see much benefit. Recent years have shown an increase in multiboot adoption (no stats, only observation), and I maintain the one-OS-per-disk principle as being the most convenient, as has been generally recommended for many years.
Before UEFI, multibooting was not as convenient, although still possible. It was common to adopt the many-OSs-on-one-disk approach; and, let’s face it, storage was never as cheap as is popularly claimed, so economically, that made a lot of sense.
Some people still prefer that approach with UEFI, and there’s nothing inherently wrong with that. In fact, the original UEFI standard actually supported @cscs one-ESP-per system; and this makes sense on typical installations.
Whether manjaro-install-grub should ultimately anticipate a multiboot scenario with multiple ESP’s, I can’t say. However, I can positively suggest it should be given due consideration.
Just did a little test on this. It worked before this, so I was of the opinion it should again. I had an error:
Partition Table Entries is not in disk order
…or something. So, I followed these instructions:
It is very easy to fix partition name ordering with that most feared and deadly disk management tool called
fdisk. Here is the summary. For details, see for e.g., here.sudo fdisk /dev/sda
- enter
xto enter expert mode- enter
fto fix partition order- enter
rto return to main menu- enter
wto write the partition table changes to disk
And rebooted…
The warning about grub wasn’t there, I improved and added it.
…right into a grub rescue CLI.
So I booted with my Live environment, and entered a chroot environment and ran:
install-grub
And was confronted by:
WARNING: EFI directory not found! Grub couldn't be installed.
So I continued and reinstalled GRUB according to this page on the wiki, rebooted, and I could use my PC again.
Curios about the error, I tried again:
$ sudo install-grub WARNING: EFI directory not found! Grub couldn't be installed.
This made absolutely no sense. So, I checked lsblk:
$ NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 3.6T 0 disk
└─sda1 8:1 0 3.6T 0 part
sdb 8:16 0 4.5T 0 disk
└─sdb1 8:17 0 4.5T 0 part /home/mirdarthos/virtualbox
/home/mirdarthos/Video
/home/mirdarthos/Pictures
/home/mirdarthos/Music
/home/mirdarthos/KeePass
/home/mirdarthos/Documents
/mnt/5TB
nvme0n1 259:0 0 232.9G 0 disk
├─nvme0n1p1 259:1 0 500M 0 part /boot/efi
├─nvme0n1p2 259:2 0 7.8G 0 part [SWAP]
└─nvme0n1p3 259:3 0 224.6G 0 part /
…which looked fine. So I checked mount:
$ mount | grep efi
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,noatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
…and everything looked OK to me.
And so I checked:
$ sudo fdisk -l
[...]
Disk /dev/nvme0n1: 232.89 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Samsung SSD 960 EVO 250GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 5053CB27-A627-1B45-9E5E-131BA81C39E6
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 1026047 1024000 500M Microsoft basic data
/dev/nvme0n1p2 1026048 17410047 16384000 7.8G EFI System
/dev/nvme0n1p3 17410048 488392031 470981984 224.6G Linux filesystem
…and the EFI partition seems to be another filesystem. (Or I’m still missing something.)
So I’m thinking in my attempt to fix the partition order warning, The partittion type changed. Or something.
But I’m booted into a working system at the moment and the warning is gone. So it would seem all worked out in the end.
And yes, I do realize that this isn’t the intended use of it, but I thought mentioning it anyway would be interesting. FWIW, this is my installed version:
$ pamac search -i install-grub install-grub 2.12-3.10 core
GNU Grub (2) Install Script on Updates
It might be interesting to see how another tool (such as gdisk) reports that information: – sudo pacman -S gptfdisk
sudo gdisk -l /dev/nvme0n1
Here ya go:
$ sudo gdisk -l /dev/nvme0n1
GPT fdisk (gdisk) version 1.0.9.1
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/nvme0n1: 488397168 sectors, 232.9 GiB
Model: Samsung SSD 960 EVO 250GB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 5053CB27-A627-1B45-9E5E-131BA81C39E6
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 488397134
Partitions will be aligned on 2048-sector boundaries
Total free space is 5103 sectors (2.5 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 1026047 500.0 MiB 0700
2 1026048 17410047 7.8 GiB EF00
3 17410048 488392031 224.6 GiB 8300
Well, that’s distressing:
1. 0700 Microsoft basic data (500.0 MiB)
--> Should be:
--> EF00 (the ESP) EFI system partition
2. EF00 EFI system partition (7.8 GiB)
--> Should be:
--> 8200 (if swap) Linux swap
3. 8300 Linux filesystem (224.6 GiB)
--> Is correct:
--> 8300 (assumes) Linux filesystem
If these partition types were not assigned like this via Calamares, then it looks like fsck has seriously fornicated with your partition types.
Check partitions 1 and/or 2 for any sign of additional boot files.
The Microsoft basic data might indicate the partition was either created as, or detected as, a normal Fat32 filesystem, without the EF00 to specify otherwise.
I have seen a very recent post where someone claimed “Calamares didn’t create the ESP properly”, but it was largely dismissed as user-error by others (including moderators).
Perhaps this needs further investingation.
VERY WELL FILTERED. I’LL REMEMBER THAT.
They were like that after installation, IIRC. So it wasn’t calamares.
/dev/nvme0n1p2
…can’t be mounted, since it’s my (very rarely used) swap:
$ sudo mount -t auto /dev/nvme0n1p2 /tmp/tmp
mount: /tmp/tmp: unknown filesystem type 'swap'.
dmesg(1) may have more information after failed mount system call.
Well, perhaps it was, before that. 
Looks that way:
$ cat /etc/fstab 1 ↵
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=D563-DAB7 /boot/efi vfat noatime,umask=0077 0 2
UUID=1b3f894f-5481-4241-ace5-c129a0cdb412 swap swap noatime 0 2
UUID=9a26c8d0-43f4-44ad-a7d3-861d6f6cdbfa / ext4 noatime,data=ordered 0 1
Edit:
You reckon I should change it? Like this:
I’ve never tried to change the partition type post-install, so I can’t be sure of the results. Gdisk might be able to change the type codes, no doubt there. The complication is that after that, you need to save those changes to the partition layout. I don’t know how Gdisk handles that on an already active disk. Fdisk, I’d be even less confident with.
Boot to the Installer, use GParted to re-create and format the ESP, and Swap (for the sake of re-establishing the proper type), reboot with the Live Installer again, manjaro-chroot -a and reinstall Grub.
This seems the logical workaround.
Don’t forget to reassign the mount points.
In that case, and considering this is my only PC and it seems to be working ass it is at the moment, I’ll leave it. At least for now, until someone an give me more information.
Edit:
That’s what I figured as well. But it’ll have to wait a bit, seeing as my day is almost at an end, it works at the moment, and I’ll only suspend my PC, not shut it down, so in that regard, there is no problem.
In the mean time, if anybody else has a better plan, or idea, I’m all eyes.
Nope. Trust me, not ears.
- Have a recent backup
- Use a live manjaro
- Use gparted !
- Save all files from the efi-partition to usb (mount / save / unmount)
- Recreate swap partition
- Recreate efi partition (be aware of the flags)
- Restore all the files to efi partition
- Go into your uefi and select the right entry to boot
Your avatar suggests otherwise.
And, yes, if the boot files are ok, just zip the entire /EFI folder, save it somewhere, and restore it after reconditioning the ESP (and swap).
1 Like
Just rebooted and everything seems still fine.
What I don’t get how or why is:
$ fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 232.89 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Samsung SSD 960 EVO 250GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 5053CB27-A627-1B45-9E5E-131BA81C39E6
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 1026047 1024000 500M Microsoft basic data
/dev/nvme0n1p2 1026048 17410047 16384000 7.8G EFI System
/dev/nvme0n1p3 17410048 488392031 470981984 224.6G Linux filesystem
$ swapon
NAME TYPE SIZE USED PRIO
/dev/nvme0n1p2 partition 7.8G 0B -2
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 3.6T 0 disk
└─sda1 8:1 0 3.6T 0 part /mnt/4tb_backup
sdb 8:16 0 4.5T 0 disk
└─sdb1 8:17 0 4.5T 0 part /home/mirdarthos/virtualbox
/home/mirdarthos/Video
/home/mirdarthos/Pictures
/home/mirdarthos/Music
/home/mirdarthos/KeePass
/home/mirdarthos/Documents
/mnt/5TB
nvme0n1 259:0 0 232.9G 0 disk
├─nvme0n1p1 259:1 0 500M 0 part /boot/efi
├─nvme0n1p2 259:2 0 7.8G 0 part [SWAP]
└─nvme0n1p3 259:3 0 224.6G 0 part /
With lsblk the type is swap but with fdisk not? And it seems neither with gdisk. I don’t get it. AT ALL!
And I always thought of fdisk better/easier than others…
If someone can explain it, THAT’D BE GREAT…
I only trust gparted !
AHA!
That led me to the solution, thanks!
The /dev/nvme0n1p1 had the msfdata flag set, and the /dev/nvme0n1p2 had the boot and esp flags set!
Moved those to /dev/nvme0n1p1 and set the flag for /dev/nvme0n1p2 to swap, and all is well again:
$ fdisk -l /dev/nvme0n1 Disk /dev/nvme0n1: 232.89 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Samsung SSD 960 EVO 250GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 5053CB27-A627-1B45-9E5E-131BA81C39E6
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 1026047 1024000 500M EFI System
/dev/nvme0n1p2 1026048 17410047 16384000 7.8G Linux swap
/dev/nvme0n1p3 17410048 488392031 470981984 224.6G Linux filesystem
You’re very welcome! 
Consideration:
(Added: 2024-01-13)
In a recent thread, it was revealed that Tuxedo are shipping their pre-installed Linux laptops with a non-standard (UEFI) boot configuration:
The ESP is mounted via a /boot mount point rather than /boot/efi, the more common convention. I’ve seen vague references to this an “upstream” preference, for many years, but rarely see it used in the wild.
Additionally, --bootloader-id=grub seems to be universally applied irrespective of the installed distribution, which results in a $ESP/EFI/grub/grubx64.efi bootloader path.
Grub should handle these variants without much fuss, and I presume the new script does, also. However, does it?
Interesting so I always half-updated grub because I never overwrote the UEFI fallback file. Because I did not know that this is also necessary. I’m using LUKS2 and after reading an error that can occur with it I’m glad I haven’t tried it yet.
This script is designed to only alter grub installs made with Calamares during installation of Manjaro. It has several checks. Bootloader-ID gets read out from /etc/default/grub to find the right install of Grub. You can have several ones. Fallback only gets overwritten when it was part of the Manjaro installation.
1 Like