New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ReaR does not preserve Grub install location #2003
Comments
@jsmeix I've dared to assign you since we are dealing here with SuSE ;-), hope you don't mind ;-). V. |
IMHO one sufficient thing would be to patch /mnt/local/etc/default/grub_installdevice with information from V. |
I know about this kind of issue since a longer time As far as I know "rear recover" basically installs GRUB2 into MBR What I implemented as a generic way to give the user final power @gozora Did you re-run "rear mkbackup" after you did the You need to re-do "rear mkbackup" and re-test "rear recover" But I think this does not affect the target location whereto |
@gozora
During Then Nevertheless it seems there is also a generic bug in ReaR I think what is not right is to let "rear recover" silently change |
By the way: |
I don't see any easy way how to completely and correctly fix this problem. V. |
Sweet, this makes my idea in #2003 (comment) obsolete ... |
I assume the root cause is what is described in the section
Perhaps it is possible to find something that indicates |
@gozora
so that you should (theoretically) have been informed Based on that another idea how to deal with such issues is @gozora |
Third offhanded idea how to reasonably guess In layout/save/default/445_guess_bootloader.sh the code part
guesses what bootloader is used by inspecting certain disk devices If it finds signs of GRUB2 being installed on more than one disk device |
@jsmeix don't waste your time too much on this one. It can be rather easy to fix in running system. I'll take a look on Grub installation code and see if there is some way, how it can be enhanced. V. |
Stale issue message |
ReaR version ("/usr/sbin/rear -V"):
Relax-and-Recover 2.4 / Git
OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):
SUSE Linux Enterprise Server for SAP Applications 12 SP2
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
VirtualBox VM
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
x86 compatible
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
BIOS/GRUB
Storage (lokal disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
Local (no multipath)
Description of the issue (ideally so that others can reproduce it):
GRUB that was originally installed on
/boot
(/dev/sda1) is reinstalled onrear recover
to MBR (/dev/sda) which caused unbootable system after upgrade from SLE12-SP2->SLE2-SP3:This behavior should not apply to installations where GRUB is installed to MBR during OS installation.
yast bootloader->OK
to reinstall bootloader to its original location (/boot
) or update/etc/default/grub_installdevice
To reflect new location of boot loader installed by
rear recover
This is issue is reproducible as follows:
/boot
partition during OS installationzypper dist-upgrade
The text was updated successfully, but these errors were encountered: