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:
Welcome to GRUB!
error: file '/boot/grub2/i386-pc' not found.
error: file '/' not found.
Entering rescue mode...
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?
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:
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:
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.
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…
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.