After new monitor, old partitions won't boot into GUI

English Install/Boot/Login
21

nosplash==“”==default. IOW, splash is an option that can be enabled, and is disabled by simply not enabling it.

15.3’s inxi is a broken antique. You can upgrade to current directly from upstream:

sudo inxi -U

Since inxi is nothing but a script, you can use the version from 15.5, also old and broken, or from 15.6 (recent enough) or TW (current).

“…TeK driver: N/A” is a blocker that means an appropriate kernel graphics module, amdgpu in your case, failed to load. You may need to check /etc/mod* directories to ensure that amdgpu is not blacklisted. Then try booting by appending (as you might 3 or nomodeset) to the end of the linu line after striking the E key at the grub menu modprobe.blackist=radeon, then proceeding with boot. If this fails to produce a desirable result, try running sudo modprobe amdgpu.

Ati is not a driver. It’s a driver chooser that isn’t relevant to Cezanne. Radeon I don’t believe is supported competently, if at all, on Cezanne, yet that’s the display driver inxi says 15.3 is trying to use. xf86-video-ati should be uninstalled, not appropriate for Cezanne, but likely was for your old ATI GPU. Display driver trouble cannot be overcome before the lack of amdgpu module loading is overcome.

DIX: Device Independent X display driver. (e.g. modesetting)
DDX: Device Dependent X display driver. (e.g. amdgpu, intel, nouveau, radeon)

22

Not sure what you mean there. I had tried nomodeset previously.

But I tried the modprobe.blackist=radeon from the grub menu and editing the linux line and no difference, then I tried sudo modprobe amdgpu from the command prompt after logging in and rebooted with no difference.

This seems disturbing too me. Assuming something else didn’t change I don’t remember. It is very reasonable to consider a lightning strike destroys one’s motherboard, you upgrade it, perhaps switching to a different gpu, and you can’t boot. The only thing comforting is that 15.5 and 15.4 did boot, so maybe if the operating system isn’t too old and there wasn’t a major change right before the disaster, you might be okay.

Since I can log in as root and do a startx, wouldn’t that indicate a permission security issue for my normal user account that needs to be changed, maybe for a different module or driver?

23

“As you might” could be translated “in same manner” or “using same procedure”, nothing about trying to use 3 or nomodeset.

If you’re still interested in trying to get X to work in 15.3, you may need to clarify, as early in thread you mention two 15.3s are present on the system.

Try a normal 15.3 boot from whichever 15.3 you expect to work, without any optional parameters or any /etc/X11/xorg.con* files. After X fails to start, reboot into 15.5, capture the Xorg.0.log file from the 15.3 you just tried to use, and susepaste it for our perusal. It may hold a needed clue.

24

From within 15.5, I renamed the 15.3 xorg.conf.install to xorg.oldconf.install and I renamed the folder xorg.conf.d to xorg.oldconf.d. I added a line of some dashes to /var/log/Xorg.0.log. I rebooted to 15.3, it prompted me with a login prompt. I then rebooted to 15.5 and inspected /etc/X11 and saw it created a new xorg.conf.d directory with 00-keyboard.conf as the only file. The Xorg.0.log had nothing below my line of dashes. I tried again with logging in and doing a startx, but the log still had nothing below the dashes. I don’t think editing the file disables logging?

I was hoping for a special parameter or deleting some files to allow at least a low resolution boot. Given a situation of swapping a hard drive to a different system, how bad is it to do a sudo startx, what ramifications would that cause? Would creating a new user solve any video issues?

25

Every time Xorg succeeds to start, it creates a new Xorg.0.log either in /var/log/ or in ~/.local/share/xorg/. It also writes to it as and when it sees fit. So, editing it can serve no purpose other than indicating whether or not X was able to start when last attempted.

/etc/X11/xorg.conf, /etc/X11/xorg.conf.d/ and /etc/X11/xorg.conf.d/* upstream are all optional. All Leap versions from 42.1 on should be capable of starting X with all these absent.

Our openSUSE maintainer for X maintains startx is not supported, though for some people in some configurations it does work. Complaints in Bugzilla that it doesn’t work fall on deaf ears and/or get WONTFIXed.

Have you tried starting 15.3 directly in graphical.target with xdm, gdm, sddm, and/or lightdm? Is it only startx that is failing to get X running? It’s not clear to me how you define booting successfully or not.

Booting with nomodeset on kernel cmdline should support a minimum of 800x600, and usually 1024x768, but this presumes X is able to run at all.

26

I define booting properly as seeing my desktop. While being prompted for login and actually being able to log in is a lot better than a blue screen of death, it’s not what I want.

I had written in a documentation file, last updated in 2013, that startx - starts X Window System. I’m not familiar with xdm, etc. Maybe new commands from when I first found out about startx? See, I have a handicap here. I don’t have a working knowledge of how everything fits together, GRUB, KDE, X windows, Wayland… I can use it, but when something goes wrong, or I try to do the steps myself, I’m stumbling in the dark. But I’ve never regretted leaving that “other” window system.

So I logged in as my user and tried the commands.
xdm, gdm, lightdm all gave a message saying requiring root access. sddm gave some messages and then just stayed hung for a long time until I pressed ctrl-C.
The xorg log file was updated. Lots of stuff and I didn’t see my dashed line. So I guess that’s what you mean, creates a new log, every time.
Here it is:
https://paste.opensuse.org/pastes/c8ee6efa0a57

27

I had this about ready to submit about 14 hours ago, not long before bedtime, when the forum went down. I remember it was not actually done, but it was still down when last checked before sleep became mandatory. Whatever I intended to add is long forgotten.

Successful booting can mean

  1. rescue.target: single user text mode with no network
  2. multi-user.target: multi-user text mode with network
  3. graphical.target: multi-user plus graphical environment

There’s also default.target, which is usually symlinked to graphical.target. If you can boot to 1 or 2, both constituting successful booting, then problems with 3 can be fixed.

Startx is normally not used unless either having booted to multi-user.target, or needing to start an additional simultaneous GUI login session. Officially, openSUSE does not support startx. If you need it and it works, be happy. If it doesn’t, you need a display manager to start the GUI and present a login screen. This is the job of XDM, GDM, LightDM, KDM3 and/or SDDM, none of which are supposed to be run directly from a shell prompt. Instead, the graphical.target configuration is supposed to load it automatically, along with other graphical setup activity.

To check what your default.target is set to, run systemctl get-default. If your 15.3 reports default is multi-user.target, change it to graphical thus: systemctl set-default graphical.target. This could be a complete solution to your problem there.

Your susepasted Xorg.0.log is from 15.5. I thought we were trying to get 15.3 to work?

28

Yes, the forum was having issues when I posted and had to wait awhile before trying a few more times. Isn’t that how it goes, that whatever you were writing, when you have to redo it, it’s never the same.

Oh no! I went to the 15.3 drive, but must have scrolled down to something else. I look now again, and the last thing in the 15.3 log are my dashes.

Yes, it technically “boots”, and in a worse case situation, I could copy files off. Probably. But not the graphical environment I desire.

I’ve seen mentioned where you can configure a system to boot to the command prompt. Maybe server, maybe preference. What would one do to load the graphical environment for certain times within that situation? I could easily imagine a multi-user system where one user only wants a command prompt except for sometimes.

It’s set to graphical.target.

If I press Ctrl+Alt+F7, I see something that looks like the following I found in the messages log file:

2024-07-31T14:10:19.976217-05:00 localhost systemd[1]: Starting Permit User Sessions...
2024-07-31T14:10:19.976222-05:00 localhost systemd[1]: Finished Permit User Sessions.
2024-07-31T14:10:19.976225-05:00 localhost systemd[1]: Condition check resulted in YaST2 Second Stage being skipped.
2024-07-31T14:10:19.976228-05:00 localhost systemd[1]: Condition check resulted in YaST2 Firstboot being skipped.
2024-07-31T14:10:19.976231-05:00 localhost systemd[1]: Starting X Display Manager...
2024-07-31T14:10:19.976234-05:00 localhost systemd[1]: Starting Hold until boot process finishes up...
2024-07-31T14:10:19.974674-05:00 localhost rsyslogd: imuxsock: Acquired UNIX socket '/run/systemd/journal/syslog' (fd 3) from systemd.  [v8.2106.0]
2024-07-31T14:10:19.974874-05:00 localhost rsyslogd: [origin software="rsyslogd" swVersion="8.2106.0" x-pid="1435" x-info="https://www.rsyslog.com"] start

Not sure if that’s important.

I’m thinking about reinstalling 15.3 on my temporary 15.3 partition which also doesn’t work. Just to confirm that 15.3 works with my hardware or if some odd reason it doesn’t even though 42.3 does. I just find it odd that two 15.3 partitions do not boot to the graphical environment. With one, I could imagine I did something that messed it up, but both of them?

Short of going through the whole install process, is there anything else that would accomplish the same goal? Something like: fix system, or reset system.

29

To fix it you will need to boot it to multi-user.target. In effect it seems you may be doing that now, due to X failure to start. When you try to boot it now, do you get a text login prompt on any vtty, using e.g. Alt-F4 or Ctrl-Alt-F3 if necessary to leave the boot screen?

Those who wish normal booting to mean to a GUI environment, as you do, need default.target set to graphical.target. Those wishing only text terminals need default.target set to multi-user.target. When a deviation in boot type is desired, one need only strike the E key when Grub’s boot menu appears, navigate to the end of the line begining with linu, then add a space and a number before proceeding as the edit screen directs. For those wishing graphical instead of text, the number is 5. For those wishing text instead of graphical, the number is 3. It’s a simple detour that only works for that boot.

“Starting Hold” would seem to indicate something isn’t ready for X to be able to start. If that doesn’t clear up without intervention, you’re stuck without it, in effect on permanent hold, with at best a “multi-user.target” boot.

I can imagine multiple ways that could happen. For one, with two installations of the same OS on the same PC, something could have occurred to cause either or both to be confused which is actually trying to boot, so not using file(s) or filesystem(s) from the correct location. The second of two same OSes will usurp boot control from the other. You’ve complicated this further by having three (or more?) Leaps. What steps did you take in bootloader management to prevent subsequent from usurping prior?

No GNU/Linux OS has technical need for its own bootloader. IOW, once a Linux OS is installed normally, no subsequent Linux installation needs any bootloader installed. It’s an application of KISS philosophy. The second installed can be expected to wrest some degree of boot control from the first. UEFI has an advantage over legacy booting here, as with legacy BIOS/MBR booting, the damage is more extensive and harder to repair. All my UEFI PCs here are multi-multiboot, with Grub installed only on Tumbleweed, and have ESP filesystem mounted on /boot/efi/ only when booted to Tumbleweed.

Otherwise than sticking with just one bootloader per PC, an important first step prior to adding another distro of same name is to edit /etc/default/grub so that GRUB_DISTRIBUTOR= is unique to the PC. The reason is this string becomes what is expected to be the unique location of that OS’s boot files on the ESP filesystem, in /boot/efi/EFI/. The hidden default with any openSUSE version is simply “opensuse”. Unless you made this edit on each of yours, adding a unique string such as “s155” or “os153” or “leap423”, the overlap very likely could be at least a partial cause of the failure to boot as expected anything other than 15.5.

If the reason for X not starting can be found, it can be corrected. Searching dmesg and journal from a normal boot attempt and text login should provide clues needed to get diagnosis started. There may also be clues in ~/.xsession-errors. You may susepaste each and provide URLs so we can peruse them. It may be easier to install afresh. Because of your multi-multiboot situation, I lean strongly in the fix existing over a new installation due to risk of disruption to 15.5. Before commenting further, I’d like a detailed explanation of your bootloader configuration.

Multiboot is a complicated art. I think you’ve been fairly lucky over the years given your level of understanding apparent.

30

I tried that and no effect. In 15.5 Ctrl-Alt-F3 gives me another session with login prompt. In 15.3, Ctrl-Alt-F7 shows the boot screen holding for finishing. I don’t think F3 or through F6 did anything.

I didn’t know you could do that. I tried it and no difference. I tried 3 and then startx, but it didn’t work, I don’t remember what happened, probably like before, just hang like.

That kind of frightens me some. Especially since I don’t fully understand this new efi / uefi stuff. But so far, it’s worked like I expected partitions to work. The only issue I had was way back something like in openSUSE version 11 or 12, where I thought I could copy the files from one partition to another, and it started loading from the old. All these hardcoded uuid’s. So I stopped trying to do that until I could find out how to copy an existing operating system to a new partition, and so far, I haven’t found a good way of doing that.

But anyway, I found out about partitions and wished I knew about that in microsoft. I started with two or three and now I have 4 OS partitions on one drive and 2 on another. Probably too many, but I like keeping the last OS, and having space to experiment with other versions.

I have several small 50 GB, and now with larger disk, 100GB partitions. I used the install .ISO and select the partition after having made sure to refresh my memory of the partition labels I gave them. And I have had some issues with booting (or understanding the install instructions) in the past and had to use a gparted live cd to set the boot flag. But either I learned more or the GPT disks work better, I haven’t had an issue in the last several installs.

Grub does set the default to the last install, but I just choose the item from the list I want the default (usually the current one), go into Yast boot loader, and just save no changes, and it takes care of setting that one to the default.

I’m sorry I don’t know anything about setting unique IDs and any issues with multiple OSs. Each partition has it’s own unique uuid which grub does a probe of other OSs, and sets the menu list with the uuids hardcoded. I do seem to recall after trying to copy a partition, I was forcing the install to use volume labels and that might have had a problem with the same name, I don’t remember exactly, but decided to let the install use the uuids from then on.

At least the partitions portion of Linux installs I thought I understood correctly. Seems to work logically to me. What am I missing? And I had installed 15.5 on my hard disk, and then after my system was working ok, I installed it on the NMVE. Boots much faster! No issue with two 15.5s (and two 15.3s) other than if I forget which menu item was which one. But I don’t usually go back to the hard drive one. Wish I could label them differently from the probed ones without having to go in and edit grub.cfg but not sure how that could be implemented with grub probing.

31

On a previously virgin computer, installing the first (openSUSE) Linux OS causes this result:

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

Above is what your EFI boot directory looks like after first openSUSE installation to a previously clean system. When you add another openSUSE installation. the result looks exactly the same, which is the expected cause of the nefarious last installation or update usurps control of booting.

What should happen, if bootloaders are to be included with more than one Linux installation, is the admin editing /etc/default/grub to make GRUB_DISTRIBUTOR= to make it a “unique” string (on that computer), e.g. GRUB_DISTRIBUTOR=“leap153” The result, upon its application, would become:

# tree /boot/efi/
/boot/efi/
└── EFI
    ├── BOOT
    │   ├── BOOTX64.EFI
    │   ├── fbx64.efi
    │   └── grubx64.efi
    └── leap153
        └── grubx64.efi

Creating an additional openSUSE installation now, instead of overwriting the existing, would produce this:

# tree /boot/efi/
/boot/efi/
└── EFI
    ├── BOOT
    │   ├── BOOTX64.EFI
    │   ├── fbx64.efi
    │   └── grubx64.efi
    ├── leap153
    │   └── grubx64.efi
    └── opensuse
        └── grubx64.efi

So far so good, but when you wish to install a third openSUSE, but fail to edit GRUB_DISTRIBUTOR= on the second as done after the first installation, you would have:

# tree /boot/efi/
/boot/efi/
└── EFI
    ├── BOOT
    │   ├── BOOTX64.EFI
    │   ├── fbx64.efi
    │   └── grubx64.efi
    ├── leap153
    │   └── grubx64.efi
    ├── opensuse
    │   └── grubx64.efi
    └── opensuse
        └── grubx64.efi

If first editing GRUB_DISTRIBUTOR= in the second installation to uniquify it, e.g. GRUB_DISTRIBUTOR=“leap153x”, you’d have e.g.

# tree /boot/efi/
/boot/efi/
└── EFI
    ├── BOOT
    │   ├── BOOTX64.EFI
    │   ├── fbx64.efi
    │   └── grubx64.efi
    ├── leap153
    │   └── grubx64.efi
    ├── leap153x
    │   └── grubx64.efi
    └── opensuse
        └── grubx64.efi

With this latest result, regular bootloader maintenance, such as new kernel installation, will not usurp, aka overwrite, ESP directories created by other installations. This means boot control is fully the admin’s, by virtue of his use of efibootmgr, or UEFI BIOS setup, to select and maintain the installation to be the default. Each new installation that includes a bootloader can be expected to change the default, but it is a simple process to run efibootmgr or UEFI BIOS setup to restore the default, if change is actually desired.

32

I don’t have “efi” in /boot. Maybe I’m not using it? I’ve seen it before, maybe on a laptop.

Does it make a difference if you have a separate boot partition versus like mine, part of / ?

33

Given newness Ryzen 5 5600G, it was easy to presume you’re using UEFI to boot. Apparently you have at least one installed disk that saw life in an older computer, or you simply chose legacy booting over modern mainstream UEFI booting. Usurpation is avoided or handled rather differently booting legacy. A separate boot partition doesn’t affect this choice. Output pasted here, using code tags, from parted -l should be useful going further with this.

All my multiboot UEFI PCs boot using the method shown in this forum thread here. Similar could be done with legacy booting, but note the method uses a one bootloader installed per PC configuration, with a separate primary partition to which Grub is installed, and contains the Grub booting files. It doesn’t get mount it to /boot/, and it contains no kernels or initrds, essentially a one bootloader per PC configuration. It’s a low maintenance system due to making use of kernel and initrd symlinks on installed systems.

34

I’m becoming concerned here. Maybe I’m lucky until I upgrade to the next version? I’m going to have to absorb your link. I’ve always had trouble understanding how grub worked, what I can see as text and what is hidden on the drive. It seems different than DOS booting, but maybe I didn’t really understand it. And I knew UEFI was different, but not sure how it would affect how I installed things. I think I’m about to learn something new.
So what have I got? Is it UEFI and how does one know? Maybe bios_grub?

> sudo parted -l 
[sudo] password for root: 
Model: ATA ST2000DM008-2FR1 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: pmbr_boot

Number  Start   End     Size    File system     Name              Flags
 9      1049kB  11.5MB  10.5MB                  primary           bios_grub
 1      11.5MB  43.0GB  43.0GB  ext4            BootReserve       msftdata
 2      43.0GB  47.3GB  4295MB  linux-swap(v1)  SwapSpace         swap
 3      51.6GB  159GB   107GB   ext4            LinuxOne
 4      159GB   267GB   108GB   ext4            LinuxTwo          legacy_boot
 5      267GB   377GB   110GB   ext4            LinuxThree
 6      377GB   431GB   53.7GB  ext4            ReservePartition
 7      431GB   1269GB  839GB   ext4            MyData


Model: NVMe Device (nvme)
Disk /dev/nvme0n1: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: pmbr_boot

Number  Start   End     Size    File system     Name  Flags
 1      1049kB  9437kB  8389kB                        bios_grub
 2      9437kB  8599MB  8590MB  linux-swap(v1)        swap
 3      8599MB  62.3GB  53.7GB  ext4                  legacy_boot
 4      62.3GB  117GB   54.8GB  ext4

15.3 is on sda5 and the temporary one is on sda6.
The first 15.5 was flagged as legacy_boot while the nmve current one has no flags on 4.

If I’m all messed up and need to start over on my nmve drive, this would be where I’d like to make a copy of my 15.5 partition onto the harddisk :slightly_smiling_face:

35

I checked my bios and looks like I have CSM compatibility enabled. Perhaps it didn’t boot my old disk so I turned it on? So maybe that’s why the install didn’t setup efi folders in the boot directory.

I’ve looked over cavsfan’s from the multiboot link you gave and his ubuntu wiki and all the grub entries look very similar to mine. I must be missing something. Maybe the efi mode of my system?

Maybe my system is messed up regarding efi. Some how I set it up to 8MB but maybe even that is not being used. How do you tell? Is EFI important, useful, if you don’t have windows installed? Should I reformat my nmve drive before I install 15.6, set the bios to not CSM compatibility, and let the install set things up? Or do I need EFI? Probably at some point, there won’t be a compatibility mode. But…

36

8meg is a bit small for a EFI partition

37

Any computer that supports UEFI and CSM now, should continue to do so as long as the computer lasts. Computers have already been on the market for a while that are UEFI only.

I have been multibooting for more than three decades, and currently have multiple multiboot computers. All except one that support UEFI are configured to use it only. The exception was a migration of an MBR SSD as-is, so continues to be used in CSM mode until some opportune moment arrives to switch, if ever. I consider UEFI a blessing, and recommend it for every reasonable opportunity.

If you still have working 15.5 on sda, I recommend starting fresh by disconnecting sda, and repartitioning NVME for UEFI installation of 15.6, which can easily be done by any openSUSE installer integral to installation. After installation, CSM can be re-enabled for use of sda for booting as and when desired. A PC’s BBS menu, as long as it doesn’t have a malfunctioning BIOS, makes this easy enough to do.

An ESP partition for openSUSE needs minimal space, but more than 8MB in virtually all cases. This is from my 2 year old Asus with i5-11400 CPU booted to TW:

# df -h /boot/efi
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p1  320M  7.2M  313M   3% /boot/efi
#

I’m not sure so little as 8MB is allowed for ESP. :stuck_out_tongue: 8MB is about the size required for a BIOS Grub partition to boot legacy mode on a GPT partitioned disk. Windows minimum ESP is 100MB, unless disk size is >16TB, in which case minimum is 260MB. All of mine here are the same 320M size. Note the tiny amount of space I’ve consumed there, even though installations number 16, so little because only TW uses it. Still, if all 16 installations had their own entries there using 3% of space each, my 320MB would still be only half used.

So, do you need it: No. But, for multibooting, I strongly encourage its use.

38

I had previously installed openSUSE on an old laptop. It set it up as efi and has it mounted as /boot/efi/EFI/boot/ and opensuse with grub.efi and other files. It also has grub.cfg which looks like it just loads /boot/grub.cfg. The efi partition is 8MB (6MB used) and there is a biosgrub partition is 8MB. I did a trial run install on my nmve drive and chose the whole hard drive and it offered and 8MB BIOS boot partition. So maybe I have to have the CSM turned off before it offers efi?

I don’t understand what the BIOS boot partition is, if the MBR hands it over to /boot/grub? With EFI configured correctly, will there be no BIOS boot and no MBR?

For some reason, I’m having a hard time understanding all this MBR and efi and grub boot loading. I know in the past, I had flagged a partition for booting and it didn’t work. But MBR seemed to work. But now I’m seeing MBR is maybe old compatibility and not really needed for gpt drives?

Other than moving along with the world, what blessings have you found with UEFI? So far, it sounds a lot more complicated and problem prone. I only thought it was for microsoft trying to prevent copying windows.

So next steps. My 15.5 on sda is quite outdated. What’s the best way of copying my nmve 15.5 over to it? Rsync? Would I have to worry about UUIDs other than possibly in the grub for the sda drive?

39

If true, it would be highly unusual. Booting UEFI is started by the UEFI BIOS loading a file from some directory in /EFI/ on the ESP filesystem. The name of the directory there for any GNU/Linux installation either comes from the GRUB_DISTRIBUTOR= value in the installed system’s file /etc/default/grub, or a default string when that value is absent. In openSUSE, nothing is the default, so the string used is “opensuse”. This means that on a running default openSUSE installation, /boot/efi/EFI/opensuse/ is the location the UEFI BIOS finds openSUSE’s boot file(s).

Understanding this is one of the keys to understanding multibooting in UEFI. Each installation of openSUSE uses this same /boot/efi/EFI/opensuse/ location, which means the second openSUSE installation usurps boot control from the first. Initially this is usually OK, as the new installation is what one wishes to boot, and, when “Probe Foreign OS” has been checked during installation, Grub’s menu will include selections for all previously installed operating systems that it knows how to identify.

As long as GRUB_DISTRIBUTOR= is left at its null default on every installation, every transaction on every openSUSE installation that causes /boot/efi/EFI/opensuse/ to be written, such as new kernel installation or update to Grub, may be wresting control from the other. This can be perfectly OK if your mind understands what is happening.

I don’t like this musical chairs version of boot control. Ways to avoid it include:

  1. only have Grub installed on one installation. Only one bootloader per GNU/Linux PC is necessary.
  2. do not mount ESP filesystem on /boot/efi/ except on the installation you wish to retain control.
  3. use a different ESP filesystem for each operating system installation. This one requires making use of the BIOS BBS menu whenever booting a different OS from last time is desired.
  4. give GRUB_DISTRIBUTOR= a unique value before installing an additional operating system, preferably having it applied to /EFI/ via a kernel update or other activity that writes to the ESP before beginning the new installation. e.g. use YaST Bootloader to change the Grub timeout value.

I employ a combination of 1, 2 and 4. I have an active bootloader only in TW. I also have GRUB_DISTRIBUTOR=“opensusetw” in /etc/default/grub, which means boot is initiated by the UEFI BIOS by loading from /EFI/opensusetw/ on the ESP, and /boot/efi/EFI/opensusetw/ exists on the running TW system. When booted to anything other than TW, the ESP filesystem is not mounted on /boot/efi/. The actual boot stanzas most often used live in /boot/grub2/custom.cfg on the TW / filesystem. The automatically generated /boot/grub2/grub.cfg incorporates its content automatically.

The filesystem for UEFI booting is on the EFI System Partition - ESP. Multibooting is complicated enough without employing imprecise technical terms.

I’m surprised you managed to create an ESP so tiny, and get the installer to actually use it.

Whether CSM or EFI is offered is entirely dependent on whether the installation was initiated in CSM mode or in EFI mode. Typically a boot will default to CSM mode if CSM is enabled, while when it is not, only EFI is possible. With CSM enabled and you with boot in EFI mode, it’s typically necessary to employ the BBS menu directly, or indirectly via UEFI BIOS setup.

MBR is a term with multiple uses. Every disk has a first sector. That sector is called the MBR. When it only contains traditional content, you have an MBR-partitioned disk that can only be booted in legacy/BIOS mode. The content of the MBR usually is of multiple types. It starts with code. It ends with partition table. In between is commonly disk identification.

The MBR sector on a GPT disk needs no boot code. Instead, it contains a partition table in the same location as a legacy disk, but usually with a special “protective” table entry that identifies it as a GPT disk, where the actual partition table utilized begins on the next sector, uses several sectors following, and is duplicated at the end of the disk.

The BIOS boot partition is a substitute for the space in the boot track on a legacy/BIOS/MBR disk that normally holds Grub code. That space, since it’s used for GPT table, is not available for Grub’s use on a GPT disk.

Multibooting has always been complicated to set up, art as much as science, and I can’t imagine it not remaining so indefinitely. Some people have better luck than others, apparently including you. UEFI presents an environment that has multibooting in mind, in design, not as an addon of competing bootloaders. It’s not perfect, but IMO clearly better overall.

Rsync would certainly be an option. Adjusting bootloader and fstab for different UUIDs and LABELs is certainly going to be required whether you rsync or most anything else. If it was me, and sda has room of adequate size to hold the complete / from NVME, I would most like to clone the / filesystem to sda. But as long as sda remains legacy/MBR/BIOS partitioned, the process would likely be constrained by the usual primary/logical partition scheme limitations. A clone from GPT would need to be on a primary, something I’ve never had need to try.

You might want to consider getting sda’s 15.5 to be an up-to-date near twin to that on NVME, so that you can continue running it just as well as now. Once that’s done, you’d be free to start from scratch on NVME for 15.6.

Multibooting is complicated to set up. Did I already say that? Multibooting is complicated to set up. It helps immensely to understand what’s going on and how it works. Once enough of that happens, it seems simpler.

40

I mean to say there are two entries on the laptop:
/boot/efi/EFI/boot
/boot/efi/EFI/opensuse

In your previous example of multiple /boot/efi/EFI/opensuse, that wouldn’t be good. Is there a way to delete one? What does the grubx64.efi in each contain? Same information or a pointer to the UUID where /boot/grub.cfg is found? What in the boot process determines which of the entries in your example to choose? (Looking back over this, I thought I was catching on, but seems like something I’m still not understanding)

Do I understand correctly that /boot/efi/EFI/opensuse/grubx64.efi would have a very minimal configuration that points to the partition that is booting and that is where the real grub entries are? So the first time, say partition 3 has like one entry. Then I install the next opensuse in partition 4 and partition 3/boot/grub2/grub.cfg still has one entry, but partition 4 grub.cfg has two entries?
If so, I think that’s kind of what I thought would happen when long ago I tried to write grub to each new partition and leave the MBR alone.

Sorry, too many terms that I don’t have a working knowledge of. I had not seen ESP used before this thread. Now I see it elsewhere, so probably overlooked the term in the past. I see the letters “/efi” in the folder. But I also seem to see it used elsewhere interchangeably. So the ESP is 8MB. Not sure, but I believe the openSUSE install program chose that. It was a laptop I was practicing with saving windows, messed around a bunch, and finally decided something like windows xp wasn’t worth saving so did something to wipe the whole disk or let the install choose the whole disk and I thought that’s what it picked.

BBS - Another term I’m not familiar with. Something in the install program?
Maybe BIOS Boot Screen? If so, not sure what that means vs. grub?

I always thought grub and MBR did a good job and can even load windows. But with GPT disks, the MBR is only compatibility mode. I guess I would think in design specs, change to GPT, but still have a way to load grub. But maybe that’s what ESP does, and may be a way for certain boot loaders which insist on starting on their own rather than from grub?

I had forgotten about fstab. Thanks.
My data directory is on sda so I can’t wipe it out. Was that what you meant? There are other partitions I could use so I could leave the past one alone. But then we are talking about maybe four 15.5 partitions and I might not get that always sorted out in my head!

Maybe the fog is starting to clear… I suppose I really need to get with the program or there will be some future time that I will have to deal with this learning, such as a future new motherboard that just says there’s no CSM. Thank you for all your help. This is new territory for me but I’m starting to think I’m getting an idea about it.