Previous Boot Selection Fails After Power Outage During Shutdown

Hi everyone:

I was shutting down after a session when I encountered a power outage before the shutdown completed.
Now when I select the same disk drive option to boot, I get the BIOS main screen instead of boot options.
The other O/S boot disk entries still work as before.

Anything come to mind?

Yes, you can repair the boot-loader from a OMLx ISO Live or from one of the other operating systems. The steps to do so are pretty specific and they are here.

Ben (et al):

Following the sequence of the provided instructions:

Continuing the discussion from Fix broken boot-loader:

Now we mount the root partition in Konsole:
# mount >partition device name< >destination directory<
Like this example:
# mount /dev/sda2 /mnt

The Konsole response is:

mount: mnt: mount point does not exist.
dmesg(1) more information after failed mount system call.

Checking KDE Partition Manager shows:

Mount point: (none found)

Please advise.

The /mnt directory is part of the basesystem. If you run ls -lh / in Konsole (terminal) you should see:

[ben79@2410-f2fs ~]$ ls -lh /
total 43K
lrwxrwxrwx   1 root root    7 Jun 26  2022 bin -> usr/bin
dr-xr-xr-x   4 root root 3.5K Nov 12 20:30 boot
drwxr-xr-x  19 root root 3.3K Nov 14 07:41 dev
drwxr-xr-x 119 root root 8.0K Nov 12 20:30 etc
drwxr-xr-x   5 root root 3.5K Oct 29 14:14 home
drwxr-xr-x   2 root root 3.5K Jun 26  2022 initrd
lrwxrwxrwx   1 root root    7 Jun 26  2022 lib -> usr/lib
lrwxrwxrwx   1 root root    9 Jun 26  2022 lib64 -> usr/lib64
lrwxrwxrwx   1 root root   10 Jun 26  2022 libx32 -> usr/libx32
drwxr-xr-x   2 root root 3.5K Jun 26  2022 media
drwxr-xr-x   2 root root 3.5K Jun 26  2022 mnt
drwxr-xr-x   4 root root 3.5K Oct  2 05:38 opt
dr-xr-xr-x 243 root root    0 Nov 14 07:40 proc
dr-xr-x---   5 root root 3.5K Nov 12 20:32 root
drwxr-xr-x  40 root root  960 Nov 14 07:41 run
lrwxrwxrwx   1 root root    7 Jun 26  2022 sbin -> usr/bin
drwxr-xr-x   2 root root 3.5K Jun 26  2022 srv
dr-xr-xr-x  12 root root    0 Nov 14 07:40 sys
drwxrwxrwt  14 root root  360 Nov 14 07:41 tmp
drwxr-xr-x  13 root root 3.5K Oct  2 05:38 usr
drwxr-xr-x  17 root root 3.5K Oct  2 05:45 var

All of those directories listed on the far right are installed with any OMLx system install. You can see that the directory mnt is listed between media and opt.

To help further I would need to see the actual Konsole (terminal) output. It is best to post all of the output from the beginning.

The following example show from within my Cooker system mounting my ROME partiton and then chrooting into /mnt to access the ROME system.

[ben79@2489-cooker ~]$ sudo mount /dev/nvme0n1p5 /mnt
[ben79@2489-cooker ~]$ sudo chroot /mnt
[root@2489-cooker /]#

Note how everything to the left of the root prompt (#) changed after the chroot or change root command indicating that I am now in a different root system. Then run cat /etc/release to verify that I am in fact chrooted into my ROME system:

[root@2489-cooker /]# cat /etc/release
OpenMandriva Lx release 23.11 (ROME) Rolling for znver1

I have personally used the steps to fix boot loader in that article about 6 times in the last month in the course of testing various things.

Thanks Ben.
I’ll check this out and get back to you with the results.


Please excuse the possible confusion, I now realize I should have mentioned this before:

I have 4 physical SATA drives on this machine, and rather than multiple drives & OS’s being able to boot from the same shared boot loader on any drive, I want each drive to boot independently by selecting it from the BIOS drive boot selection list at POST. (My apologies, it slipped my mind… sorry.)

With this in mind, would it be possible to use the Partition Properties pop-up screen in KDE Partition Manager to assign mount points and set them up to boot individually?
(None of the 4 drives have assigned mount points or boot flags presently.)


UEFI or Legacy boot?

If the drive is not seen at POST you would have a different problem that I would not know about.

The mount command only relates to the procedure for fixing the broken boot-loader. When the boot-loader is fixed then systemd will mount whatever the file /etc/fstab tells it to mount.

If the drive is seen at POST then you would still need to chroot in to the / partition of the OS on that drive and run the grub2-install command. If the system is UEFI that is what the instructions in that article are for. If it is Legacy boot then I think the same steps will work. Either way if you have one OS on the drive then you are installing grub2 boot-loader from your / partition but to the drive itself. In other words if ROME / partition is /dev/sdc3 you install the boot-loader with grub2-install /dev/sdc. But you run that command from /dev/sdc3.

That explanation assumes a standard install where all system directories are under the root partition. Does not matter if you have a separate /home, that has nothing to do with this.

I hope this makes sense. I also hope I more or less understand the actual problem correctly.

This part makes me wonder where are trying to mount from. If it is an OM ISO I know there is a /mnt directory on our ISO’s. The mnt directory needs to exist on whatever OS you are trying to mount your ROME / partition to. Or you can create it with:

$ sudo mkdir /mnt

Don’t worry… you/re making perfect sense, pal… (thanks!)

The drive/os combinations appeared in the boot selection list shown as both. (I selected the UEFI version, the legacy version gave “reboot & insert proper boot device” message.)

Boot drive entries list remains unchanged, the drives & os selections are still visible as before, but selecting & entering them used to boot into the selected drive/os, but now they all lead back to the BIOS settings home page.(Same result using any selection from the BIOS boot override option.)
All directories are standard mount under root.

I’m really primarily interested ingetting into these boot drive partitions so that I can see and read what might be worth keeping from my home directory… documents. photos, downloads, etc. If I can retrieve whatever I might wabt from there, I’d just as soon install the l. (I think I’d go with Rome and Cooker on two separate drives, and tell the installer to wipe and take over the entire drive as its own. (They sem to lke that!)atest OS versions from scratch
What would be the preferred method to

Finally copied all non-replaceable files and re-installed, so no further action necessary here.
Thanks for the help.

Well, I’m back again.
The problem is recurring, but only after updating the system:

  1. I re-installed the system, booting the live Lx rolling x86_64 Rome build 2293 from a UEFI USB boot key drive (used this same key build many times on different machines - no problems)

  2. Installer shows EFI & GPT, I chose to erase the entire disk, swap with hibernate, EXT4 file system, not encrypted. (typical.)

  3. Installation completed normally, checked the “Restart now” box and clicked “Done”.

  4. After confirming basic OS functionality, I used the OM shutdown menu to restart and power off multiple times, restarts again, no problem.

  5. Followed the OM Rome Release Notes method and CLI string to update via Konsole, completes normally.

  6. After update, will no longer restart, every attempt to restart sends me back to the BIOS setup

  7. Tried boot override via BIOS, still no joy… I can see the installation via live boot’s Partition Manager, but its like there is no boot sequence, no matter what approach I take, always goes to either the BIOS setup, or the “Insert boot medium…” message.

I have repeated this re-installation process three times, with the exact same result:
As long as I do not update, no problem… if I update, no boot.

I’ve never encountered this before, although I have upgraded OM Lx on this same machine, same BIOS, same USB key, same drive, using the same Konsole CLI string method for all the previous releases back to Lx 4.! successfully.
Please help.
Any suggestions, please advise.
Thank you.

ISO 2293 is from August. When you update it there was probably an upgrade to grub2 that results in this problem. When discovered we told users they could fix the boot-loader fairly easily with this post. We had multiple users report successfully fixing their boot-loader with that article. I encountered this problem and had to fix boot-loader on multiple test systems.

The easiest thing to do would be to use a newer ROME ISO and avoid the problem all together.

Edit: For latest ROME ISOs look here and go to the Main containers:.

Thanks, Ben.

Previously, I had always removed the live USB key after installation to prevent the BIOS boot sequence from loading the live version again, so I never discovered this until now:

If I reinsert the live boot key, I can find and boot the HD installation by selecting the appropriate “Boot GRUB UEFI loader” selection from the “Boot from UEFI images” main menu selection, if that is of any help to you.

I’ll download the latest build and install it again. (I thought 2293 was the most recent.) Hopefully that will take care of it.

Before I close, I want to give my heartfelt thanks again to you and everyone else on the OpenMandriva team and community for all you do:

I enthusiastically recommend this as my all-time favorite main go-to general purpose Linux distribution…
…and you guys are definitely an essential part, if not THE main reason.

:sunglasses: :+1:
Have a great night.

Thanks for the kind words.

I am sorry you have been having difficulties and am not sure my first response was the best. But we just keep learning.

You’re more than welcome, Ben.
And thanks for the kind assistance!


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.