Leap 15.2 Grub error on virtualized machine after repos update??

Hi all.

I have a bit of an issue here.

I’m working on adapting a website based software: as such, I needed the whole LAMPS, but I didn’t want that on my main machine eating resources when not necessary.

As such, I created (actually, used an already existing) virtual(box) machine with LAMPS installed, and just installed the new software to start the modifications. It was working as a charm for my testing purposes.

I’ve left it working for a few days straight for no reason, and since it was bothering me for not finding a repository, I gone into yast and removed packman, added it back and told it to update the habilitated repositories.

After, I told packagekit to update its available updates list (I’m quite certain I did not tell it to update anything), and left it working, since I had to work on other stuff.

When I came back now, I found a black screen. Restarted the whole virtualbox and the virtual machine, and got just:

GRUB Loading..
Welcome to GRUB!

error: file '/boot/grub2/i386-pc' not found.
error: file '/' not found.
Entering rescue mode...
grub rescue>

Now, the thing is that it did not occur to me to backup the modifications I was doing on the software running inside the virtual machine! :beat-up:

Anybody has any idea on how can I try to save this (virtual) machine and raise it back from its (virtual) death? :stuck_out_tongue:

Thanks a lot in advance for any suggestions!

New info: found the following tutorial:


set command outputs this:


ls command outputs this:

(hd0) (hd0,gpt3), (hd0,gpt2) (hd0,gpt1) (cd)

The tutorial then suggests the commands “set prefix” and “set root”, however it does warn that “this has to be done according to your own drive name”. However, I’m not getting how to “divine” which of the partitions should I chose… :’( Any ideas?

Sounds like you just need to sort out your partition structure. You could boot with an iso such as “gparted-live-1.3.1-1-amd64.iso”. Or boot into a recovery iso (or use the command prompt from gparted live) and list the block devices:

lsblk -l

Hi Julina!

Thanks. First I tried it on the grub recovery itself and did not wok (obviously), then I tried the rescue system from the live installation CD:

loop0   7:0    0   82M  1 loop
loop1   7:1    0 13.4M  1 loop
loop2   7:2    0 59.4M  1 loop /mounts/mp_0000
loop3   7:3    0 46.1M  1 loop /mounts/mp_0001
loop4   7:4    0  4.1M  1 loop /mounts/mp_0002
loop5   7:5    0   82M  1 loop /parts/mp_0000
sda     8:0    0   25G  0 disk
sda1    8:1    0    8M  0 part
sda2    8:2    0   23G  0 part
sda3    8:3    0    2G  0 part
sr0    11:0    1    4G  0 rom

But I’m not used to this sort of failure so, what should I do now?

Looks like the partition sda2 is your main partition and that grub is pointing to it.

In the past when I have had grub problems I have booted into a recovery disk, chrooted to the installed system and then used YaST from the command line to reinstall Grub. This is a link that you may find useful:


and this:


Seems that I can’t even mount it:

#mount /dev/sda2 /mnt
mount.bin: /mnt: wrong fs type, bad option, bad superblock on /dev/sda2, missing codepage or helper program, or other error.

Any ideas? :frowning:

Just guessing

sda1 => ESP
sda2 => SWAP
sda3 => /

Did you try sda3 as well?

However if you used btrfs for your root partition you will need a GRUB version that can handle it. I don’t know if the gparted LIVE iso does have such a GRUB version.



Given the partition sizes:

sda 8:0 0 25G 0 disks
da1 8:1 0 8M 0 part
sda2 8:2 0 23G 0 part
sda3 8:3 0 2G 0 part

I think it is likely to be sda1 is EFI, sda2 is the main and sda3 is swap. Which would agree with Grub’s configuration. Worth trying the others I guess but a broken root partition would explain the initial problem. I know very little about repairing broken file systems, so will back off and leave others to comment.

cat /proc/filesystems

Will list the filesystem types supported by the kernel (I know that’s not the same as Grub but you did have a working system and an update won’t have changed the filesystem type I hope!). A Gparted live CD will try and identify the filesystem on the various partitions which may give more clues.

Hi! Just tried sda3, and explicit said it is the swap.

However, it indeed is btrfs. I’m using the recovery system from the opensuse leap installation DVD (not the gparted live iso), shouldn’t it be compatible with btrfs since its kind of the “official” fs on leap 15.2?

just entered the command and indeed btrfs fs is to be suported.

Seems that all goes down to a somehow broken root partition or something similar, as JulinaB mentioned… :frowning:

Any thoughts on how to try to recover that?


Bouncing the thread back to the top of the listing: please, anybody has any suggestions on how to repair broken file systems (btrfs)?

I mean, simply starting over a whole new (virtual) machine is not the optimal solution in my case here…

Any help would be appreciated…

Thanks a lot in advance!

I do not use btrfs so i can’t help you. Sorry!

But you can

  1. search the forum. If i recall correctly there are threads on repairing btrfs
    . 1. create a new thread with “How to repair a btrfs
    file system” (or something similar) as title. That is more likely to draw the attention you are looking for.



Thanks, I’ll try a new thread (your suggestion on searching already gave me a few more line of sight ahead… :slight_smile: