On 10/28/20 7:00 AM, Carlos E. R. wrote:
On 28/10/2020 05.54, Robin Klitscher wrote:
On 28/10/2020 17:10, Felix Miata wrote:
Robin Klitscher composed on 2020-10-28 12:58 (UTC+1300):
1. On all three installations the line in etc/default/grub is empty, as in "GRUB_DISTRIBUTOR= ". Since this includes the 15.2-1 installation that works, I wonder if the steps you outline in that regard are strictly required?
By default, "GRUB_DISTRIBUTOR= " translates to /boot/efi/EFI/opensuse. Last installation to write it wins control of the post-Grub boot process.
All mine get a unique one first thing after installation, or even before if I'm particularly ambitious, with the result that I can safely delete any "opensuse" directory on the ESP filesystem. Mine unambiguously include opensusetw, opensuse423, opensuse150, opensuse151, opensuse152, fedora32, fedora33, debian10 and debian11, so none overwrite others, and with mounting the ESP partition *only* to the installation I wish to control booting as I do, booting never gets broken unless I screw something up myself, or forget first thing with a new installation to undo. I usually don't need to undo it, as I usually remember to taboo Grub installation unless it's the first on a new ESP.
Some updates do write to that partition. Happened to me few months back, wrote to the wrong place, and got "error: symbol `grub_calloc' not found", "Entering rescue mode".
Thank you; you're 'way ahead of me!
But from what you say, in a multi-boot scenario the running system has indeed written to the ESP. What I don't get is that although I can see and enter the folders and files below /boot/efi from the running system, those same sub-folders and files don't exist in a backup of the root filesystem done with Grsync using full superuser rights and all the other capabilities that Grsync offers. Curious.
Maybe because that partition doesn't need to be mounted while the system is running, and then you don't see it. And maybe because all had the same name and thus the last one installed overwrote the others, and then there was only one.
In the setup you posted, the partition pointed by the two non working did not exist, so there was something weird going on.
It seems that the hurdles here are fundamentally due to sharing a single /boot/efi partition across 3 installations. Is that really needed??? Just fwiw, seeing how far along you are with your current approach, its worth considering that it might be easier to use a separate /boot/efi for each install, using one grub as the master which chainloads the other two or alternatively using the bios boot selection feature (if the machine supports that) to choose which install to boot. I use both, i.e., ordinarily chainloading from the master while having the bios boot as a backup. Re "something weird going on": The TW and -2 fstab files point to two partitions that no longer exist, yet the partition /dev/nvme1n1p1 (which now holds swap) is not included. (A good guess would be that this first partition is where the missing UUID=0908-2851 for /boot/efi was located.) In any event, two corrupted fstab's are not the result of only a "data partition" having been deleted (per the original post). Suggests that partition changes are being made from within one install that affects the other install(s), or that an outside tool is being used. Begs the question, what is OP using Parted Magic/gparted for and why? --dg -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org