Have you backed up the files on ~/ folder (home) on this drive? If not, I would suggest you do so before wiping it all out and reinstalling.
How to back up my home folder ~/
If you don’t have anything there, feel free to skip this part.
Actually, I reinstalled OpenMandriva on its drive roughly two months ago.
I still question why I keep loosing only the "“openmandriva: PO: SPCC Solid State Disk” F12 option on its SSD but not the similar F12 boot option on the (separate) Zorin SSD?
Thank you again for your kind assistance!
I have no way to know what the differences are between the two.
Thank you WilsonPhillips,
This issue, at least as I have presented it, is not a trivial one.
I really do appreciate each of your kind suggestions.
Thanks again!
1 Like
Well, if you do not want to reinstall OM on the drive, let’s see what your partitions are on the drive.
lsblk -ao path,label,uuid,fstype
Thank you! Will do but could take a couple of days. (Out-of-town guest).
Kind regards!
The following are the results of the terminal command you suggested. I am pretty sure that SDA is my OpenMandriva SSD and SDB is my (also connected for this test) Zorin SSD. The NVME (T500) is my windows M.2 drive.
Thank you for your generous help!
[sdr@openmandriva-x8664 ~]$ lsblk -ao path,label,uuid,fstype
PATH LABEL UUID FSTYPE
/dev/loop0
/dev/loop1
/dev/loop2
/dev/loop3
/dev/loop4
/dev/loop5
/dev/loop6
/dev/loop7
/dev/sda
/dev/sda1 F972-C836 vfat
/dev/sda2 247dab2c-76af-4391-877f-31ef70566f8a ext4
/dev/sdb
/dev/sdb1 369B-816F vfat
/dev/sdb2 99e4fea5-eb53-48c6-ac0b-05696c7dc569 ext4
/dev/sr0
/dev/zram0 zram0 51671118-fc9a-4307-be61-755386ba8e8c swap
/dev/nvme0n1
/dev/nvme0n1p1
/dev/nvme0n1p2 521E-D495 vfat
/dev/nvme0n1p3 T500_SSD CC3A5EC38B83713E ntfs
[sdr@openmandriva-x8664 ~]$
Please use Markdown to wrap code and output so it reads better.
lsblk -ao path,label,uuid,fstype
PATH LABEL UUID FSTYPE
/dev/loop0
/dev/loop1
/dev/loop2
/dev/loop3
/dev/loop4
/dev/loop5
/dev/loop6
/dev/loop7
/dev/sda
/dev/sda1 F972-C836 vfat
/dev/sda2 247dab2c-76af-4391-877f-31ef70566f8a ext4
/dev/sdb
/dev/sdb1 369B-816F vfat
/dev/sdb2 99e4fea5-eb53-48c6-ac0b-05696c7dc569 ext4
/dev/sr0
/dev/zram0 zram0 51671118-fc9a-4307-be61-755386ba8e8c swap
/dev/nvme0n1
/dev/nvme0n1p1
/dev/nvme0n1p2 521E-D495 vfat
/dev/nvme0n1p3 T500_SSD CC3A5EC38B83713E ntfs
If you don’t know how to do that, the forum tutorial goes over it.
We cannot go with “pretty sure” for this. Please unplug the Zorin drive and run the command again. Please paste your code as code. This requires 3 back tics before and after. ` is the key to the left of the 1 and above the tab key.
Thank you. Easy enough. I trust that this produces the desired format:
PATH LABEL UUID FSTYPE
/dev/loop0
/dev/loop1
/dev/loop2
/dev/loop3
/dev/loop4
/dev/loop5
/dev/loop6
/dev/loop7
/dev/sda
/dev/sda1 369B-816F vfat
/dev/sda2 99e4fea5-eb53-48c6-ac0b-05696c7dc569 ext4
/dev/sr0
/dev/zram0 zram0 f1d543ce-6bab-4a79-a3b3-e2e8b4cb497b swap
/dev/nvme0n1
/dev/nvme0n1p1
/dev/nvme0n1p2 521E-D495 vfat
/dev/nvme0n1p3 T500_SSD CC3A5EC38B83713E ntfs
[sdr@openmandriva-x8664 ~]$ ```A solution, without a complete reinstall, to my issue appears elusive.
Ben79’s suggestion, sudo update-grub2 then sudo grub2-install /dev/sda,
run from an OpenMandriva terminal, has not solved it.
I intend to install OpenMandriva another SSD and see if the problem “follows” and appears on it.
Thank you all for your very kind help.
Hi, I do not have a solution but just wanted to add that I have similar issue dual-booting with Windows. However, it is not OpenMandriva but openSUSE that refuses to boot once I have booted into Windows.
- I have a Ventoy drive with iso files of different distros; it boots fine every time.
- I have a USB key where I have installed Fedora Silverblue. It kinda boots; in the sense sometimes it boots sometimes it goes into blue color screen with ‘MOK installation’ or something. If I select ‘continue to boot’, it boots OK.
- I have openSUSE Leap installed on another USB key. This one has booted once or twice out of many many attempts I made to boot into. I must add that openSUSE key is encrypted, with separate unencrypted /boot partition.
Also in my case:
- Secure boot is disabled.
- Boot priority is set to boot from external USB drives first and last option is internal Windows drive.
- Each of the USB keys have their own EFI partition.
Considering that Ventoy boots just fine and Silverblue once in a while goes into ‘MOK’ screen, the issue could be EFI/Grub related.
I’m planning to check two things.
- install systemd-boot and see if it gives better result than grub (?!).
- Mine also has ‘fastboot’ or ‘quickboot’ enabled. Will disable it and see if it helps.
MOK is updating the keys for the TPM. Maybe some are using it and some are not.
1 Like
Thank you all for your generous technical help.
For what it’s worth:
I installed OpenMandriva onto a new (second) SSD in my laptop.
This laptop is MBR, not UEFI.
Everything boots and works fine, time after time, on my MBR laptop.
I also have an older MBR desktop. This new installation also boots fine there too.
My original OpenMandriva installation (my “problem” installation) is on a UEFI PC.
I therefore cannot test this (new) second MBR SSD installation on my original (UEFI) PC.
I hope that this information might be of some help.
Thanks again for all of your kind assistance.
Spencer
Glad you are keeping OpenMandriva installed, one way or the other. 
In my case, the issue resolved by using systemd-boot. Now the openSUSE install (dual) boots without any issue.
For what it is worth, following are my observations:
- all the distros that were dual booting fine, had common entry in /boot/efi: a ‘BOOT’ directory with ‘BOOTX64.EFI’ file (and similar files for other architectures supported like BOOTIA32.EFI etc).
- they also had directory (by distro name like ‘ubuntu’, ‘fedora’ or just ‘grub’) that contained a ‘grubx64.efi’.
- some had an additional ‘shimx64.efi’, some didn’t.
- both openSUSE (problematic one in my case) and openmandriva (currently running) only have one directory under /boot/efi, ‘opensuse’ and ‘openmandriva’ resp., with one file inside, ‘grubx64.efi’.
I had already installed systemd-boot by this time, otherwise I would have manually created a ‘BOOT’ directory and copied ‘grubx64.efi’ into it as ‘BOOTX64.EFI’ in order to test.
1 Like
I do not know if this relates to the OP’s issue or not.
I do not know about multi-booting with Windows. I only use OMLx at present but I do multi-boot the different versions of OMLx on my laptop. I only use ext4 or xfs file system types for this. Using btrfs and f2fs do not work well with multi-booting OMLx. But I have not tested this for well over a year. I lost interest in trying to get the problems with multi-booting btrfs or f2fs to work in OMLx and decided to let other people fight that battle.
The easy way is to find what works and use that.
Also users find that say dual-booting openSuSE and OMLx does not work because of the openSuSE implementation of btrfs. Or is it OM’s implementation? Don’t know.
1 Like
My first thought is that grub is not installed to the same drive as OM. Has this been ruled out? I read the whole thread but might have missed something.
Thank you all for your kind assistance.
- My OpenMandriva installation is not dual boot. It is installed onto its own SSD.
- “Boot Repair” (htt**://help.ubuntu.c**/community/Boot-Repair) restores UEFI OpenMandriva’s ability to boot but this option disappears after I boot Windows (which is installed on a separate SSD).
- The “Boot Repair” summary message always begins with “An error occurred during the repair.*
Error: no grub.efi generated for OpenMandriva Lx 25.04 (25.04). Please report this message to boot.repair@gmail.com”* - In the future, when I have the time, I will likely try wiping and reinstalling OpenMandriva.
Again, thank you all for your generous support!
2 Likes