Grub restore - all guides fail

Support
1

After filling my system-disk grub broke, and boots into grub restore.
I’m now on live usb. And all the guides I’ve looked up just fails. At different places of the guide.

The most common guides start with:

sudo manjaro-chroot -a

I do it and get

==> ERROR: No Linux partitions detected!

Even though the system know there is a linux system when doing fdisk.

sudo fdisk -l
Device          Start        End    Sectors   Size Type
/dev/nvme0n1p1   4096     618495     614400   300M EFI System
/dev/nvme0n1p2 618496 1953520064 1952901569 931.2G Linux filesystem

So I’ve followed this to do it manually:

sudo mount /dev/nvme0n1p2 /mnt 
sudo mount /dev/nvme0n1p1 /mnt/boot/efi

And they get mounted:

lsblk -f 
nvme0n1                                                                                                    
├─nvme0n1p1 vfat     FAT32                             A427-7EAA                             299.1M     0% /mnt/boot/efi
└─nvme0n1p2 ext4     1.0                               50ae7e7f-ef2e-4c29-ba2d-b07fe77206c7  868.4G     0% /mnt

but when I try to install grub (guide says “tarket is the disk (not a partition)” so I target the disk.

grub-install --force --target=i386-pc --recheck --boot-directory=/boot /dev/nvme0n1

I get this error:

grub-install: error: failed to get canonical path of `overlay'.

If I try guide from here Restore the GRUB Bootloader on Manjaro Linux. Usefull when your fresh windows install eats your grub and can not boot into your linux installation, or for some how your grub is missing · GitHub
and only run grub-install i get error “cannot find EFI directory.”

grub-install /dev/nvme0n1                                                                                                                                                                        
Installing for x86_64-efi platform.
grub-install: error: cannot find EFI directory.

grub-install /dev/nvme0n1p1                                                                                                                                                                      
Installing for x86_64-efi platform.
grub-install: error: cannot find EFI directory.

grub-install /dev/nvme0n1p2                                                                                                                                                                      
Installing for x86_64-efi platform.
grub-install: error: cannot find EFI directory.

I’ve used several different sources, and it always errors somewhere.
Also tried guide directly from grub rescue menu, but there’s to many partitions named anonymously to guess which one it is.

Why doesn’t manajro-chroot understand that there’s a linux partition, when fdisk understand there is?

Moderator edit: In the future, please use proper formatting: [HowTo] Post command output and file content as formatted text

2

first: there is a typo in the path here (you put a space between /boot and /dev/nvme0n1:
it looks like this without that space, with a syntactically correct path
--boot-directory=/boot/dev/nvme0n1

and:
you seem to have an efi system - so the command is the wrong one anyway

and further:
you need to be in chroot to do this - that’s what the guide you linked to says

It looks like you did target the USB you booted from …

and even further:
your system disk seems to be is completely empty:
nvme0n1p2 ext4 1.0 50ae7e7f-ef2e-4c29-ba2d-b07fe77206c7 868.4G 0% /mnt

no wonder manjaro-chroot failed

There is no system to chroot into anymore on this disk.

2 Likes
3

I manged to install grub now using this guide:

And now it starts in grub cli, instead of grub rescue.
But there it stops, get “can’t fine file error” or something like that when doing the
grub>linux /boot/vmlinuz root=/dev/nvme0n1p1

Thanks, yeah I copy pasted it from konsole in sections to the browser. I think that’s the issue here, tried it a little to many times and at different boots to have done the same misstake every time.

Humhumhum.
When entering the that disk from live-usb /home/myuser/ only has my “mounts” directory where I put my /etc/fstabs mounts. Everything else is gone…
Only remains is that and the folders of the apps installed with snap in /var/lib/snapd/snap - but they are all empty…

4

Yes - there is no system anymore.
However you made that happen …
You can stop trying to fix grub and focus on reinstalling and employing the backup of your personal files which you hopefully have.

5

Ironically it was trying to make backups that made this happen.
Timeshift filled the disk, crashed the system, and here we are.
Guess it must’ve copied links somehow that when removing /timeshift to make up space it removed the original content as well.

So no backups of the stuff stored on there. And I don’t think I will try making backups again using timeshift.

6

I seem to recall that you said you configured timeshift to back up your and root’s personal files - and excluded everything else.
That is the opposite of what timeshift is intended for - which is: to back up the system, excluding personal data.

On my system, the system files occupy maybe ~15 GB
The rest is hundreds of GB of personal stuff (videos, VM images, documents, pictures …).
A backup of this onto the very same disk would of course quickly fill it up
when the starting point is at 65% capacity already used.

Use it for system files as intended - many people do without problems …

Create a separate partition for $HOME when you install - this makes it easier to make backups and harder to screw up doing them … :sunglasses:

2 Likes
7

Yeah. Well, I won’t do.
If it can destroy my system, I won’t use it.
Especially since it’s point is to do the exact opposite.
Fool me once…
Thankfully most important stuff is saved on harddrives or servers, and not on system drive. If it was real important stuff I was backing up, and it does reversed, ouch. Now it’s just bothersome and will probably run on the other OS until I manage to bother, perhaps some time in the future.

My wild guess is it decided to restore with 0’s when I deleted /run/timeshift while timeshift gui was open. It’s the only thing I can see some sense in.

edit:quoted wrong

8

Because at this point, there was only an empty linux file system on the partition
but no actual Linux system anymore.

chroot … tries to change the file system root from the system you used to boot
to the system on that disk
which is not present anymore - no system to change the system root to.

3 Likes
9

It seems to me that you have been randomly using commands without actually understanding what they do. I can see what you wanted to do, but what you actually did was totally reckless.

As I see it, the predicament that you now find yourself in has only a few possible resolutions:

1. [Consideration] A complete reinstall of Manjaro.
2. [Consideration] Is Manjaro the Right Distribution For You.

2 Likes
10

Nah… In my first year (and manjaro was my first linux and still is) I installed new 3 times minimum.
Number 1. is fine, but don’t take number 2. too serious.

11

It was GUI timeshift, so zero commands.
Maybe that was a mistake.
Don’t really see how another distro would have prevented the same outcome.
There’s always a hail mary included no matter what one does and where one set their own control and put it on others previous work. Up to buying a service and Down to building your own processor.

Removing /run/timeshift without deeper research was duuumb yes. But couldn’t in my wildest fantasy see how it would destroy all data on the drive. And still don’t, and believe most people a lot more knowledgeable than me in this area also don’t - feels like that could not happen anymore if that was the case.

I’m really curious about it though.

12

No, it wasn’t.
How you used it was a mistake.

I may just have found a reason for what happened to you (at least a possible one):

When timeshift is not active, all mounts are normal.

[jo@jo-xfce4 ~]$ mount | grep vda1
/dev/vda1 on / type ext4 (rw,noatime)

When it is active (the GUI is open or perhaps automatic mode is set up), it looks like this:

[jo@jo-xfce4 ~]$ mount | grep vda1
/dev/vda1 on / type ext4 (rw,noatime)
/dev/vda1 on /run/timeshift/1489/backup type ext4 (rw,relatime)

So:
the / filesystem is mounted at /
and below /run/timeshift as well

I guess what can happen is:
remove the contents of /run/timeshift → remove the contents of / as well?

Maybe bad design, maybe user error, maybe both.

Just don’t directly mess with the snapshots while the program is active and the to be backed up filesystem is in use.
Go through the program.

The actual timeshift snapshots are stored under:
/timeshift
on the same disk without further configuration

Remove those - all you’ll lose is your snapshots.
Not your whole system along with it.

I guess the lesson here is:
understand what you are doing - don’t just remove stuff (as root, no less)
unless you understand the implications.

2 Likes
13

In the future, please use proper formatting. I’ve done it for you this time.

14

Something in lines is what I believe to have happened. I still don’t understand how. But cleaning all cache in run/timeshift might confuse timeshift that it’s restoring, without anything to restore with.

There is no indication in the GUI that anything is active, like telling you it’s backuping or restoring, and filled the disk without me really starting anything other than setting paths and interval, so it might very well have started to backup again as soon as I deleted /timeshift, and always being active when open, and thus go crazy when /run/timeshift deleted.

Well well. Mistakes were made, as many times before, and learned to use manual rsync commands next time I try to backup something and stay away from automated addons like timeshift, when the time comes where I get the energy to set up the system anew.

Thanks for the detective work / speculation.

15

No problem - I don’t use that program, so I will not and cannot really confirm.
But what I notice is that behavior - when I invoked it in a VM to test it.

You can play around and thereby confirm/disprove this - and thereby learn about the workings of the thing.

As soon as the program is started - and the GUI is there - there is that mount in /run/timeshift.

It’s not there when the program isn’t started.

The actual snapshots are in /timeshift
once the program is done, this will be the only access point.

I think the settings in the GUI tell you where the snapshots are/go to.