Reinstall in a multiboot system

Hi everyone! Hope you’re all having a nice life! :slight_smile:

I have openSUSE installed alongside Windows 7, Debian Testing and Fedora 34 in an UEFI system with legacy BIOS enabled. Without going into details, I want to reinstall because of some issues. Thing is, I’m not sure how to proceed because I don’t see openSUSE in Debian’s Grub, Debian’s listed in openSUSE’s, but Fedora is not, likewise, openSUSE’s not in Fedora’s while Debian is. Is it because of Fedora and openSUSE both use BTRFS? Windows 7 is in all of them. AFAIK, and as I’ve done before, I would need to delete a distro’s partition from another one using something like partition manager, then update grub and that would be it, but I’m not sure if that’s how I should do it this time, because of what I said above, or is it? Any advice is much appreciated. Thanks in advance for your answers. :slight_smile:

That’s very likely the problem. While grub2 can use “btrfs”, it can be confused by the subvolume structure.[/QUOTE]
I’m doing something similar, though I mostly avoid “btrfs”. And I do use UEFI booting. However, how you boot is pretty much dependent on how Windows boots. My UEFI box does not use Windows, and my Windows 7 box uses legacy booting.

I’ll describe what I do. Whether that’s helpful for you, that I cannot guess.

I partition first before any linux install. So my installs all use existing partitioning.

For grub booting, I try to set it up so that no matter which controls the boot, that system can boot all of the others. For that, I use “/etc/grub.d/40_custom”, where I add entries to boot each linux system.

Here’s a typical entry:


menuentry "configfile for openSUSE Tumbleweed on /dev/sdb2"  {
        set bootdir='hd2,gpt2'
        search --label --set=bootdir boot1
        configfile (${bootdir})/grub2/grub.cfg
}

If you are using “btrfs”, you might need to add a line for “insmod btrfs” when the system being booted uses that. Put it before the “search” line.

You will notice that I am using a search for label. Previously, I used search for UUID. But the trouble is that the UUID changes on a reinstall. Since I can set the label myself, I can avoid that problem with labels.

When I boot a different linux system, I use the “configfile” line for that system. This brings up another layer of menu. The advantage is that on a kernel update, the second level of menu should know which is the latest kernel. That’s because the kernel install normally updates the menu for that linux (which becomes the second level menu).

You can omit that “set bootdir=” line. It’s just gives a fallback if the search fails. And it is hard to get it right. How grub numbers your disks may depend on the hardware and BIOS.

Thanks for your reply. Ok, I should’ve mentioned this before, but my system doesn’t boot to Grub, instead I have to press F9 to get a UEFI(?) menu where I can choose the OS to boot to, otherwise it just boots straight to Windows 7. Once I choose a Linux, then I get a Grub menu where I can choose some OS depending on whether it is one or the other as I explained above, for instance, if I choose Fedora I don’t see openSUSE and vice versa, I do see Debian and W7 if choose any of them. My concern, is that if I do decide to go the route I know; delete openSUSE’s partition from either Debian or Fedora, and update-grub, I might get some unwanted, undesired results, like no OS booting at all. I don’t see why it should happen, but then I’m not an expert by any means.

I’ve had that happening – no boot at all. I keep a bootable USB around in case I ever mess up that way.

Yeah, and that’s exactly what I’d like to avoid very much. I too keep a bootable USB around just in case, and I’ve already backed up the important data. I was wondering too if deleting openSUSE from Windows could be an option, it would be certainly the case in a dual-boot scenario as that’s how you should do it, so I do wonder, since it doesn’t show in Fedora’s or Debian’s Grub … By the way, I would use the DVD to re-install, can I just re-install over it?

Changing and installing many OS means you must manual mange the EFI boot partition and the UEFI static memory boot stack. Simply over writing or erasing an OS does not change the EFI boot stack IS;s don;t have an uninstall option. :wink:

Why would you? What exactly would you be deleting?

Thanks for your reply, however, did you read this in its entirety? Seems like you didn’t. I would be deleting openSUSE’s partition and then reinstalling it in the same partition.

Thanks for your reply, however, I’m not sure I understand what you’re trying to say there.

[quote="“Moltke,post:8,topic:145923”]

…did you read this in its entirety? Seems like you didn’t.[/QUOTE]Again, why?

I would be deleting openSUSE’s partition and then reinstalling it in the same partition.
It seems like you don’t understand the difference between a filesystem and a partition, a distinction that whose importance is elevated in a multiboot environment. You might delete a partition, then recreate a new partition in the same freespace created by the deletion, but you wouldn’t install to a deleted partition, because without a partition, there is no place to put the filesystem required by the new installation. Repartitioning a device with multiple OS installations is not an exercise to be taken lightly. It’s fraught with booby traps. It’s better to reuse existing partitions whenever existing partitioning matches the needs of a planned installation. It’s silly to go through the dangerous process of deleting a partition only to recreate it when all that’s necessary to eliminate the old installation is to reformat the existing partition, thus creating a fresh new filesystem that replaces the old.

All that said, a bootloader has a somewhat different role in a UEFI environment than in legacy BIOS with MBR. UEFI is orders of magnitude smarter than a legacy BIOS. Rather than a BIOS transferring control directly to a bootloader on an MBR, the UEFI firmware provides, among other things, a special pre-boot environment that allows to select among possible bootloaders via the binaries hosted on an ESP partition’s FAT filesystem. Ideally, each installed OS will have its own directory on the ESP, and it is the software installed in these directories that loads the individual bootloader hosted on each OS installation. If one OS is removed from the system, it needn’t disturb the bootloaders hosted on the others.

I say needn’t because the evolution isn’t complete. All openSUSE installations by default use the same ESP directory name opensuse, so installations of multiple Leap and/or TW versions should include additional steps taken to preserve bootability when one on them is removed or damaged. This is the same with Ubuntu and its many derivatives that use the same directory name ubuntu regardless of distro name or version. There is a workaround provided to avoid these issues, GRUB_DISTRIBUTOR= in the file /etc/default/grub. It suffices for the admin to include a unique name in each installation to avoid boot failure resulting from using default directory names on the ESP filesystem. As of now, openSUSE’s YaST installer has yet to facilitate this customization. The admin must use a text editor to do it until bug 1101756 gets fixed.

My point is every time you install any os on EFI booting machines things are added to the UEFI(BIOS and things are added to the EFI boot partition. These things do not magically disappear because you removed or over write an OS with a different OS.

Ah, ok I see. Are you saying I can burn the DVD to a USB and reinstall over the existing partition/filesystem?

All that said, a bootloader has a somewhat different role in a UEFI environment than in legacy BIOS with MBR. UEFI is orders of magnitude smarter than a legacy BIOS. Rather than a BIOS transferring control directly to a bootloader on an MBR, the UEFI firmware provides, among other things, a special pre-boot environment that allows to select among possible bootloaders via the binaries hosted on an ESP partition’s FAT filesystem. Ideally, each installed OS will have its own directory on the ESP, and it is the software installed in these directories that loads the individual bootloader hosted on each OS installation. If one OS is removed from the system, it needn’t disturb the bootloaders hosted on the others.

I say needn’t because the evolution isn’t complete. All openSUSE installations by default use the same ESP directory name opensuse, so installations of multiple Leap and/or TW versions should include additional steps taken to preserve bootability when one on them is removed or damaged. This is the same with Ubuntu and its many derivatives that use the same directory name ubuntu regardless of distro name or version. There is a workaround provided to avoid these issues, GRUB_DISTRIBUTOR= in the file /etc/default/grub. It suffices for the admin to include a unique name in each installation to avoid boot failure resulting from using default directory names on the ESP filesystem. As of now, openSUSE’s YaST installer has yet to facilitate this customization. The admin must use a text editor to do it until bug 1101756 gets fixed.

Thanks for that info, much appreciated.

Hmmm … I think I understand what you’re saying now. thanks for your reply.

That is just one of several powers of the installation system.

Technically I wouldn’t use the word “over” the way you used it. Over really means reusing the existing filesystem, letting the installer replace and add files as it sees fit, much like upgrading, a process which includes also removing files. This technical use of “over” is always frowned upon at least, or outright refused by the installer, but is allowed over objection by openSUSE’s installer. A better word would be replace, which involves reformatting the existing filesystem, then only adding files constituting a bootloader, operating system and applications.

Ok, think I got it, but just to be entirely clear, are you certain I can just “replace”; reformat the existing filesystem with the new one? Have you done this before? Actually, that makes perfect sense given the fact Yast installer have such advanced features, and I did suspect that doing what you suggest might be possible too, and if I understood correctly what you said, it is. Thank you very much for such valuable info. :slight_smile:

Absolutely. It’s an old screenshot, but the form has changed little since it was captured: SUSE Paste I had no luck finding a recent one on the web.

Got it! And after having seen this **“Reg. Linux User #211409 *** multibooting since 1992” **in your signature, I believe you should know a thing or two about that. Thank you very much for your help! :slight_smile: