All failed (triple boot, Leap, MX23, FSL)

Hi,
Very long time and happy Suse user, I’ve taken some times away and now coming back … it’s like Suse is punishing me :wink:
A T440p, 8core, 16Gb RAM, 512Gb NVMe + 2To hybrid SSD
So far, nothing exotic, but whatever order I do the install, none stick.
The NVMe gets /boot; /boot/efi; / (Suse 64Gb); / (MX23 64Gb); / (FSL 64Gb)
The SSD gets (Suse) Swap 64Gb + /tmp 64Gb + /usr 56Gb + /var 48Gb and same for (MX23) and same for (FSL)

Focusing on Suse (Leap 15.5 and Leap 15.6):
Installation from dvd or from usb, everything goes well, partition selection, standard applications, user + root password, all except it just can’t get the repositories downloaded for some reason (I’m on RJ45)
I ignore the repos, and just install the app present on the disk/usb, all the way to reboot, I’m stuck on

grub>

And no startx, boot, yast, no cmd give me anything.
I’ve re-partitionned as I thought maybe Suse don’t like my setup,
NVMe /boot + /boot/efi and Suse = 128Gb
SSD Swap 64G and /tmp 64G (usr and var in / )
Same thing, install without repos, and

grub>

I’m no expert to say the least, but this I really don’t understand, there is nothing unusual that would obvioulsy prevent the install.
And as I tried two different recent downloads, on two diff medium, and even my previous 15.4 on CD, I eliminate that.

Any idea ?

Yes. That I would never do it like that. I would accept the suggested partitioning with
EFI partition of 512M
btrfs for the rest of the NVME
to install the system. And use a swapfile for swap.

It’s a bit difficult, because you have not provided much information about your system.

You mention “T440p”, and I’m guessing that’s a Lenovo.

You haven’t indicated whether using UEFI booting or legacy booting. I’m guessing UEFI because you mentioned “/boot/efi”.

It might help if you can provide the output from:

efibootmgr -v

You should be able to boot the install media to the rescue system, login there as root, and run the above command. Redirect the output to a file (maybe in “/tmp”). And then, if possible, mount a USB drive and copy the output to that so that you can copy/paste in your post.

Thank you, and yes, you “guessed” well the information provided.

It’s a bit difficult because you are asking me to provide the output from a system that won’t boot. I’ve tried ctrl-F2 and ctrl-F6,= (all of them from F2 to F8) nothing happen, I just get the “commend not recognized”

I’ve tried the “rescue system” but it doesn’t recognize any kernel, and jump into install mode … it’s as if the install skept a step and finished “all good” not knowing it missed some

I will go back to it and mess again with rescue, maybe with my Live-USB (tails, Kali, Mini, MediCat, HBCD, …) and see if anything good comes out of it

This implies that grub cannot find its configuration file.

The

echo $grub_platform

on grub> prompt tells you exactly. Or simply set to list all variables.

After several re-install, I now am able to start the system from the CD (boot existing system) but still not from the drive itself
When I use the “boot existing” it doesn’t have any problem finding the partition with kernel, so I’m not sure why Grub is so blind ?
From the strated session, I went in Yast a few times to re-write the Grub to disk and every time it says “all good” yet next reboot is still an error, but no error message, just not booting
I’ve changed the partitionning a bit after seeing an advice = now have a each-its-own /boot 750Mb for each distros, and the shared Fat32 1Gb /boot/efi
Not helping much :frowning:

Not sure if it’s related (like a much-much bigger problem) but my Ventoy USB key is not recognized like 7 times out of 10 at boot (both MediCat and multi-OSes ventoys keys)
I would be very sad to have my T440p being fried (MB bus and such) … of course I have this P15 (running Win10, waiting for yet another attempt at installing Qubes) but still, I’m kinda attached to my T440p :-p
So … now all I have to do is manage to connect to this Forum from the Suse and post the requested log

Here it is !
I discovered Yakuake on MX and now I’m installing it on other distros, I like it :slight_smile:
The uneven, unsorted boot order and partition numbering makes my autistic brain cringy !

sophie@localhost:~> efibootmgr -v
Absolute path to 'efibootmgr' is '/usr/sbin/efibootmgr', so running it may require superuser privileges (eg. root).
sophie@localhost:~> sudo efibootmgr -v
[sudo] password for root: 
BootCurrent: 0009
Timeout: 0 seconds
BootOrder: 0015,0009,000D,0007,0008,000C,0000,0001,0002,0003,0016,000A,000B,000E,0013,0014,0012
*Boot0000  Setup FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b0)*
*Boot0001  Boot Menu     FvFile(126a762d-5758-4fca-8531-201a7f57f859)*
*Boot0002  Diagnostic Splash Screen      FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a389)*
*Boot0003  Lenovo Diagnostics    FvFile(3f7e615b-0d45-4f80-88dc-26b234958569)*
*Boot0004  Startup Interrupt Menu        FvFile(f46ee6f4-4785-43a3-923d-7f786c3c8470)*
*Boot0005  Rescue and Recovery   FvFile(665d3f60-ad3e-4cad-8e26-db46eee0f1b5)*
*Boot0006  MEBx Hot Key  FvFile(ac6fd56a-3d41-4efd-a1b9-870203811a28)*
*Boot0007* USB CD        VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd40dd3ba6a55)*
*Boot0008* USB FDD       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e40)*
*Boot0009* ATAPI CD      VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2099adfde214e8b3a5e471856a354)*
*Boot000A* ATA HDD0      VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f699)*
*Boot000B* ATA HDD1:     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f695)*
*Boot000C* ATA HDD2:     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f691)*
*Boot000D* USB HDD       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50893)*
*Boot000E* PCI LAN       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3893)*
*Boot000F* IDER BOOT CDROM       PciRoot(0x0)/Pci(0x16,0x2)/Ata(0,1,0)*
*Boot0010* IDER BOOT Floppy      PciRoot(0x0)/Pci(0x16,0x2)/Ata(0,0,0)*
*Boot0011* ATA HDD       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab9f6)*
*Boot0012* PCI LAN       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea70cf5cc8f3d3893)*
*Boot0013  Other HDD     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f696)*
*Boot0014  Other CD      VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35496)*
**Boot0015* opensuse      HD(1,GPT,64433111-54b4-4917-934a-0b37226a412d,0x800,0x200000)/File(\EFI\opensuse\grubx64.efi)**
Boot0016* Windows Boot Manager  HD(1,GPT,0e54203e-6cc7-47c7-abdf-656cfa862bbc,0x28,0x7d0000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
sophie@localhost:~> 

At first reading, it looks “normal”, the Suse entry is there, and a BLKID gives me the right part ID

Boot15 entry = 64433111-54b4-4917-934a-0b37226a412d
/boot/efi = /dev/sdb1: UUID="9872-0DA0" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="64433111-54b4-4917-934a-0b37226a412d"

/boot = /dev/sdb2: LABEL="bootSUSE" UUID="ef476cb1-3edd-473c-9ccf-c780249787c6" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c802f6c6-b50c-431f-9137-d34dd9aa0f9d"
/ (root) = /dev/sdb7: LABEL="rootSUSE" UUID="a8db95f0-3f97-41b3-8f0a-caf981ab96f5" UUID_SUB="58250987-4de3-4596-8a11-c38831422902" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="84222ac9-5e8b-410c-94a6-c6640cdaa632"

I’ve mod the partitioning further,
Now I has ESP as first part, no longer any /boot, and then 3 112Gb partitions for each distros
Same thing, none (Suse, MX, FSL) boots “normally”, I have for each to start the live USB and go to “boot existing partition” and it does starts
When I goo to Yast and re-write Grub, it doesn’t change anything, I still have to go through the LIve-USB rescue option; Same for MX “Boot repair”
I’m lost, I really don’t understand what’s happening, what am I missing ?

What does the tree command report for the system ESP partition’s mount point?
What does efibootmgr -v report?
What does the openSUSE system partition’s /etc/fstab contain?

Rewriting “grub” may not be doing what you think. UEFI works differently from legacy/BIOS booting. The rewrite may be doing no more changing than a change in NVRAM, as could efibootmgr.

ocalhost:~ # efibootmgr -v
BootCurrent: 0009
Timeout: 0 seconds
BootOrder: 0015,0009,000D,0007,0008,000C,0000,0001,0002,0003,0016,000A,000B,000E,0013,0014,0012
Boot0000  Setup FvFile(721c8b66-426c-4e86-8e99-3457c46ab9b0)
Boot0001  Boot Menu     FvFile(126a762d-5758-4fca-8531-201a7f57f859)
Boot0002  Diagnostic Splash Screen      FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a389)
Boot0003  Lenovo Diagnostics    FvFile(3f7e615b-0d45-4f80-88dc-26b234958569)
Boot0004  Startup Interrupt Menu        FvFile(f46ee6f4-4785-43a3-923d-7f786c3c8470)
Boot0005  Rescue and Recovery   FvFile(665d3f60-ad3e-4cad-8e26-db46eee0f1b5)
Boot0006  MEBx Hot Key  FvFile(ac6fd56a-3d41-4efd-a1b9-870203811a28)
Boot0007* USB CD        VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd40dd3ba6a55)
Boot0008* USB FDD       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e40)
Boot0009* ATAPI CD      VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2099adfde214e8b3a5e471856a354)
Boot000A* ATA HDD0      VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f699)
Boot000B* ATA HDD1:     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f695)
Boot000C* ATA HDD2:     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f691)
Boot000D* USB HDD       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50893)
Boot000E* PCI LAN       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3893)
Boot000F* IDER BOOT CDROM       PciRoot(0x0)/Pci(0x16,0x2)/Ata(0,1,0)
Boot0010* IDER BOOT Floppy      PciRoot(0x0)/Pci(0x16,0x2)/Ata(0,0,0)
Boot0011* ATA HDD       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab9f6)
Boot0012* PCI LAN       VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3893)
Boot0013  Other HDD     VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f696)
Boot0014  Other CD      VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35496)
Boot0015* opensuse      HD(1,GPT,64433111-54b4-4917-934a-0a37226a412d,0x800,0x4fe800)/File(\EFI\opensuse\grubx64.efi)
Boot0016* Windows Boot Manager  HD(1,GPT,0e54203e-6cc7-47c7-abdf-656cfa862aac,0x28,0x7d0000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot0017* MX Linux      HD(1,GPT,64433111-54b4-4917-934a-0a37226a412d,0x800,0x200000)/File(\EFI\MX\grubx64.efi)
localhost:~ # 
UUID=301b8c8a-80c0-4db8-b0e8-b4dfffbbada7  /                       btrfs  defaults                      0  0
UUID=301b8c8a-80c0-4db8-b0e8-b4dfffbbada7  /                       btrfs  defaults                      0  0
UUID=301b8c8a-80c0-4db8-b0e8-b4dfffbbada7  /var                    btrfs  subvol=/@/var                 0  0
UUID=301b8c8a-80c0-4db8-b0e8-b4dfffbbada7  /var                    btrfs  subvol=/@/var                 0  0
UUID=301b8c8a-80c0-4db8-b0e8-b4dfffbbada7  /usr/local              btrfs  subvol=/@/usr/local           0  0
UUID=301b8c8a-80c0-4db8-b0e8-b4dfffbbada7  /usr/local              btrfs  subvol=/@/usr/local           0  0
UUID=6fb91c60-973e-49a3-ab3d-9f011b435495  /tmp                    btrfs  defaults                      0  0
UUID=6fb91c60-973e-49a3-ab3d-9f011b435495  /tmp                    btrfs  defaults                      0  0
UUID=301b8c8a-80c0-4db8-b0e8-b4dfffbbada7  /srv                    btrfs  subvol=/@/srv                 0  0
UUID=301b8c8a-80c0-4db8-b0e8-b4dfffbbada7  /srv                    btrfs  subvol=/@/srv                 0  0
UUID=301b8c8a-80c0-4db8-b0e8-b4dfffbbada7  /root                   btrfs  subvol=/@/root                0  0
UUID=301b8c8a-80c0-4db8-b0e8-b4dfffbbada7  /root                   btrfs  subvol=/@/root                0  0
UUID=301b8c8a-80c0-4db8-b0e8-b4dfffbbada7  /opt                    btrfs  subvol=/@/opt                 0  0
UUID=301b8c8a-80c0-4db8-b0e8-b4dfffbbada7  /opt                    btrfs  subvol=/@/opt                 0  0
UUID=180C2DF30C2DCC06                      /media/WinDATA          ntfs   fmask=133,dmask=022           0  0
UUID=180C2DF30C2DCC06                      /media/WinDATA          ntfs   fmask=133,dmask=022           0  0
UUID=357ce47a-7390-4d11-03aa-5793c7ed3f47  /media/LXDATA           ext4   data=ordered                  0  2
UUID=357ce47a-7390-4d11-03aa-5793c7ed3f47  /media/LXDATA           ext4   data=ordered,auto,users,rw    0  2
UUID=301b8c8a-80c0-4db8-b0e8-b4dfffbbada7  /home                   btrfs  subvol=/@/home                0  0
UUID=301b8c8a-80c0-4db8-b0e8-b4dfffbbada7  /home                   btrfs  subvol=/@/home                0  0
UUID=301b8c8a-80c0-4db8-b0e8-b4dfffbbada7  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
UUID=301b8c8a-80c0-4db8-b0e8-b4dfffbbada7  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
UUID=301b8c8a-80c0-4db8-b0e8-b4dfffbbada7  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
UUID=301b8c8a-80c0-4db8-b0e8-b4dfffbbada7  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
UUID=2ad298f3-c8e6-45fe-8430-2d74f5fbbde0  swap                    swap   defaults                      0  0
UUID=2ad298f3-c8e6-45fe-8430-2d74f5fbbde0  swap                    swap   defaults                      0  0
UUID=C743-D51D                             /boot/efi               vfat   utf8                          0  2
UUID=C743-D51D                             /boot/efi               vfat   utf8                          0  

Why am I having them all in double ??

BLKID gives me:

/dev/sda1: LABEL_FATBOOT="ESP" LABEL="ESP" UUID="C743-D51D" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="64433111-54b4-4917-934a-0a37226a412d"

HAve no idea how to get “the tree report” ?

# tree /boot/efi/
/boot/efi/
├── EFI
│   ├── BOOT
│   │   ├── BOOTX64.EFI
│   │   └── mt83x64.efi
│   ├── opensuse
│   │   └── grubx64.efi
│   └── opensusetw
│       └── grubx64.efi
└── mt83x64.efi
...

man tree

I have no idea, but if it was mine, I would search dmesg and journalctl to see what errors are reported on account of dupes, and strip all the dupes to see if it helps anything.

Some BIOS don’t deal well with an abundance of entries. If it was mine, I’d delete every VenMsg entry to see if it changes anything, preferable by booting any installed system that will boot, so no DVD or USB is attached during or after booting, or while deleting surplus entries with efibootmgr. Ventoy has a fractured history in interfacing with openSUSE.

Looks like nne other sistros are resent

Sophie@localhost:/home> tree /boot/efi/
/boot/efi/
└── EFI
    └── opensuse
        └── grubx64.efi

2 directories, 1 file
sophie@localhost:/home>

But as this is the ESP, it’s supposed to have an entry for each …

I,ve never had any such trouble, this bios it capable of multi entry

IDK how to delete VenMSG

Suse is installed from a DVD, not a Ventoy USB stick, and that DVD is expected after install, so no interference

If I’m understanding your language correctly, yes it does.

This is true, if all were installed in UEFI mode, and multiple ESPs were not employed, and formatting of a sole ESP did not occur.

And that means it can’t happen? Perhaps you fell short of a breaking point before, but a limit has now been exceeded.

Do you know how to read a man page? Efibootmgr has one that describes a -B switch.

How do you know “no interference”? Most modern computers have no DVD drive, yet can operate quite normally. Mounting the installation media post-boot mainly serves as litter unless the computer is normally used only offline. Not having installation media mounted and enabled as a repo is typically best for online use, since installation of new packages normally will be of the latest, most secure version available. Also the DVD drive doesn’t get tied up, preventing its use for purposes like watching a DVD video. If the UEFI NVRAM or binary has limited capacity, DVD inclusion is wasteful, possibly fatally so.

My point, exactly

Not only does it NOT have an entry for each, but it doesn’t even stay overboots (I have to use the CD rescue everytimes)