timeshift icon indicating copy to clipboard operation
timeshift copied to clipboard

Restore not working on Fedora 30

Open Cyvain87 opened this issue 5 years ago • 7 comments

Describe the bug No option to reinstall grub2 avaliable and restoring snapshots causes a variety of issues.

To Reproduce 1.Create snapshot in fedora 30 2. Attempt to restore snapshot that was created

Expected behavior Reinstall grub2 bootloader not greyed out and being selectable. No issues when restoring snapshot.

System:

  • Fedora 30 UEFI
  • Gnome
  • v18.6.1-4 & v19.01

Cyvain87 avatar May 11 '19 19:05 Cyvain87

A similar issue here, restoring appears to work fine as long as the restore image is based on the same Kernel version. I notice at the end of the restoration prompt, I get text along the lines of update-grub: command not found.

Fedora updates GRUB (on my system at least) using this command as root: grub2-mkconfig -o '/boot/efi/EFI/fedora/grub.cfg'.

Would it be possible to have Timeshift detect Fedora and update using the grub2-mkconfig method? Thanks for your time and help.

ultraviolet-1986 avatar Oct 04 '19 10:10 ultraviolet-1986

I have just noticed the same error message (update-grub: command not found) when testing a Timeshift restore on Fedora 32 Workstation. It looks like the restore was successful anyway. I really would like to use & rely on Timeshift but this issue was reported 1 year ago. That doesn't inspire confidence.

paidhi avatar Jul 01 '20 05:07 paidhi

It depends on whether the system uses BIOS or UEFI boot. For UEFI boot, the Fedora docs say to use grub2-mkconfig to update /boot/efi/EFI/fedora/grub.cfg, whereas the Red Hat docs say to use it to update /boot/efi/EFI/redhat/grub.cfg (note the fedora vs. redhat in the directory naming). They both say to update /boot/grub2/grub.cfg for BIOS boot.

The current Timeshift code actually tries to handle Red Hat and Fedora (note target_distro.dist_type is "redhat" for both Red Hat and Fedora) but it assumes BIOS boot. Well, kinda - in fact this code will work for some UEFI boot users too, since out of the box /boot/efi/EFI/{redhat|fedora}/grub.cfg pulls in /boot/grub2/grub.cfg since it just contains something like:

search --no-floppy --fs-uuid --set=dev <your-UUID>
set prefix=($dev)/grub2
export $prefix
configfile $prefix/grub.cfg

The issue is that - due to the Fedora and Red Hat docs linked above, and due to the advice given in forums etc. - many users with UEFI systems (and presumably scripts run on UEFI systems) use grub2-mkconfig to directly update the grub.cfg file under /boot/efi/EFI, and so that file no longer pulls in /boot/grub2/grub.cfg. Since Timeshift currently only updates /boot/grub2/grub.cfg it's these users that are bitten by this issue.

jwatt avatar Jun 19 '21 21:06 jwatt

Regarding the update-grub: command not found error message, update-grub was actually being invoked in addition to grub2-mkconfig and so was really a separate issue. Regardless, 6531f6c6cdca3808ffe53c25dfbcdf22a3eb014e should get rid of that too.

jwatt avatar Jun 19 '21 21:06 jwatt

It depends on whether the system uses BIOS or UEFI boot. For UEFI boot, the Fedora docs say to use grub2-mkconfig to update /boot/efi/EFI/fedora/grub.cfg, whereas the Red Hat docs say to use it to update /boot/efi/EFI/redhat/grub.cfg (note the fedora vs. redhat in the directory naming). They both say to update /boot/grub2/grub.cfg for BIOS boot.

The current Timeshift code actually tries to handle Red Hat and Fedora (note target_distro.dist_type is "redhat" for both Red Hat and Fedora) but it assumes BIOS boot. Well, kinda - in fact this code will work for some UEFI boot users too, since out of the box /boot/efi/EFI/{redhat|fedora}/grub.cfg pulls in /boot/grub2/grub.cfg since it just contains something like:

search --no-floppy --fs-uuid --set=dev <your-UUID>
set prefix=($dev)/grub2
export $prefix
configfile $prefix/grub.cfg

The issue is that - due to the Fedora and Red Hat docs linked above, and due to the advice given in forums etc. - many users with UEFI systems (and presumably scripts run on UEFI systems) use grub2-mkconfig to directly update the grub.cfg file under /boot/efi/EFI, and so that file no longer pulls in /boot/grub2/grub.cfg. Since Timeshift currently only updates /boot/grub2/grub.cfg it's these users that are bitten by this issue.

With Fedora 34 the command to update GRUB has changed: grub2-mkconfig -o /boot/grub2/grub.cfg.

paidhi avatar Jun 21 '21 07:06 paidhi

Thank you. I'd just discovered that, and how to reset the grub.cfg under /boot/efi to its "unified" contents.

Perhaps the pragmatic way forward is to only take the first patch (to fix the if-else) and just accept that this bug exists for Fedora 33 for the remaining six months of its supported lifetime?

jwatt avatar Jun 21 '21 08:06 jwatt

@jwatt

Perhaps the pragmatic way forward is to only take the first patch (to fix the if-else) and just accept that this bug exists for Fedora 33 for the remaining six months of its supported lifetime?

Except that RHEL/CentOS/Rocky etc. 8 are much longer-lived. I do understand that Timeshift isn't supported on these distros (fixed with #873!), nevertheless it seems a shame to leave the bug. I know it's messier, but I think it would be better to change is_efi to old_rhel_efi or something.

Actually, might be better to have a separate function for determining the grub.cfg location.

randallpittman avatar Mar 01 '22 20:03 randallpittman