#2817 Issue closed: Setting the bootloader¶
Labels: support / question, no-issue-activity
danboid opened issue at 2022-06-06 10:46:¶
I have a few machines where sda and the first few disks are GPT formatted then the OS disks are something like sdh and sdi etc and these use GRUB2 installed in a BIOS partition to boot. Because of this, rear incorrectly chooses to use EFI as the bootloader for backup and restore purposes which will cause the USB rear disk to fail to boot.
I cannot find any documentation on how to manually define the bootloader
type to use so I had to read the source code. The user has to create a
file /etc/sysconfig/bootloader containing:
LOADER_TYPE="grub2"
To force rear to use BIOS grub recovery.
I think this is a very important point to note and so I think this should be covered in the README / Quickstart guide but I wanted to discuss it here first because maybe we should expose this as a command line option or make it possible to specify this in the main rear config file because I think /etc/sysconfig/bootloader is specific to Suse Linux. The /etc/sysconfig dir doesn't exist at all by default under Ubuntu so its a bit messy having to create that dir/file for this one setting.
danboid commented at 2022-06-06 11:59:¶
Looking into this a bit more, I think I should actually be using
LOADER_TYPE="GRUB"
Because that is the string I see if I check the output of a command like:
dd if=/dev/sdh bs=512 count=4 | strings > boottest
These machines are definitely using grub2 as their bootloader but they
return GRUB so why is there also a grub2 bootloader setting? Does it
make any difference? Should I recreate my backups using
LOADER_TYPE="GRUB"? I would've thought GRUB would've been used for
GRUB 1.x?
pcahyna commented at 2022-06-06 12:38:¶
Hello, I am curious about what is happening with firmware detection. It
seems that you are saying that ReaR detects it should use an EFI
bootloader, because it sees that the first disks have an EFI partition
label. Are you sure about that? IIRC ReaR detects EFI according to the
content of /sys/firmware, but maybe I have misunderstood.
danboid commented at 2022-06-06 12:44:¶
The script that checks for EFI vs BIOS is rear/layout/save/default/445_guess_bootloader.sh
It takes a dd sample of the first 4 blocks of all your disks (starting
with /dev/hd* and /dev/sd*) then greps the strings output of those
boot blocks for GRUB/GRUB2 etc UNLESS you have a
/etc/sysconfig/bootloader file present to override the auto detection.
So it seems that for most people whatever partitioning you have on
/dev/sda dictates what rear will presume to be your firmware type.
pcahyna commented at 2022-06-06 14:28:¶
Thank you for the pointer! According to the code, you should be able to
set the bootloader manually using the BOOTLOADER configuration
variable (it is even documented for this purpose in
/usr/share/rear/conf/default.conf).
pcahyna commented at 2022-06-06 14:41:¶
So it seems that for most people whatever partitioning you have on /dev/sda dictates what rear will presume to be your firmware type
Why is this the case? Does having a GPT on /dev/sda imply that
rear/layout/save/default/445_guess_bootloader.sh detects GRUB2-EFI ?
Also, according to your original description, it seems that your problem
is that the USB rescue disk fails to boot (" which will cause the USB
rear disk to fail to boot"). If so, I don't see how a misdetection in
rear/layout/save/default/445_guess_bootloader.sh can lead to this
problem, because the result of this detection is apparently not being
used in the decision what bootloader to install on the rescue disk
(another variable is used for that purpose: USING_UEFI_BOOTLOADER,
which is determined in a different way in
usr/share/rear/prep/default/320_include_uefi_env.sh ). Can you please
describe in detail what problem exactly are you having and what are you
doing to create the rescue disk? Also, what ReaR version are you using?
danboid commented at 2022-06-06 15:38:¶
These questions are because I've not tried using rear to do a restore on any of these machines yet and so I'm concerned that if I don't get the various UEFI settings correct then it will fail to re-install the bootloader (GRUB), won't boot the USB recovery or maybe the restore will fail completely? There is probably a way I can do a no-op restore that tells me what it would do when restoring without actually doing a restore right?
You're right, I was unaware that BOOTLOADER could already be set in the main rear config. I presume I should configure that to "GRUB"? I presume "grub2" is used in older versions of grub2 or in a non-Ubuntu OS.
I find it strange that the BOOTLOADER setting has no effect on
USING_UEFI_BOOTLOADER. This implies that LOADER could be set to GRUB
(BIOS) yet USING_UEFI_BOOTLOADER could be true?
My UEFI server that I'm trying to back up with GRUB isn't using secure boot. I'm running Ubuntu 20.04 and using the rear package from the 20.04 repos. The USB disks are 1 TB and so don't need to use UEFI to access space above 2 TB.
pcahyna commented at 2022-06-06 17:03:¶
I've not tried using rear to do a restore on any of these machines yet
Can you please describe what issue are you having, or is this report purely a result of code analysis? Or, do you see anything in the ReaR log that makes you think the rescue image or backup is somehow wrong? If so, please include the relevant log snippet.
Concerning
There is probably a way I can do a no-op restore
not sure about that, but you can definitely boot the rescue USB without performing a restore to check whether it is at least bootable, and you can try a restore to clean disks (disconnect the current disks, and connect clean disks of the same size and perform a real restore to them). Alternatively, you can restore to a new machine (preferably as identical as possible to the machine that you are backing up).
danboid commented at 2022-06-06 17:11:¶
Can you please describe what issue are you having, or is this report purely a result of code analysis? Or, do you see anything in the ReaR log that makes you think the rescue image or backup is somehow wrong? If so, please include the relevant log snippet.
I've already explained the root cause of my doubt and the reason I opened this ticket. I have a few machines that are UEFI capable but I have set them up to use BIOS boot because their OS disks are using mdadm software RAID which works best with BIOS GRUB booting. However, when I run rear with its default config it detects the bootloader as being EFI instead of GRUB. This makes me think it might not backup, restore or fail to both correctly.
So what difference does EFI vs GRUB make to rear? It must make a difference somewhere or else why are there scripts to detect it? Or am I worrying about nothing because it doesn't matter and rear can successfully restore a EFI image to a BIOS machine (I doubt it)?
Should rear be able to successfully restore my software RAID10 config? To do that rear would need to know to re-install GRUB on the relevant disks.
Its a shame there is no dummy restore option because I don't have a spare set of disks to do a pretend restore with so I'd like to be reassured I have used the right settings.
jsmeix commented at 2022-06-07 09:03:¶
@danboid
you must try out and verify for each one of your machines
that "rear recover" actually works for you.
See in particular the section
"Inappropriate expectations" in
https://en.opensuse.org/SDB:Disaster_Recovery
and therein in particular the sub section
"No disaster recovery without testing and continuous validation"
jsmeix commented at 2022-06-07 09:07:¶
@danboid
see
https://github.com/rear/rear/blob/master/.github/ISSUE_TEMPLATE.md
what info we ususally need to be able to understand
how things look like on your particular system.
You get this when you click on the [New issue] button on
https://github.com/rear/rear/issues
jsmeix commented at 2022-06-07 09:18:¶
Regarding bootloader and ReaR:
There are two related but separated bootloader parts in ReaR:
A)
The bootloader that is used on the ReaR rescue/recovery system
B)
The bootloader that is used on the original system where "rear
mkrescue/mkbackup" is run and that needs to be reinstalled during "rear
recover" on the recreated target system on replacement hardware
Unfortunately the various bootloader and EFI related
user config variables that are described in
usr/share/rear/conf/default.conf
do not clearly distinguish between the two cases
so things get rather tricky if bootloader specific
settings are needed for special cases.
pcahyna commented at 2022-06-07 09:20:¶
@danboid
I've already explained the root cause of my doubt and the reason I opened this ticket.
You have said:
rear incorrectly chooses to use EFI as the bootloader for backup and restore purposes
but you have not said how do you know what ReaR chooses. I suppose you found out reading a log or in the program output, so please add the part of log file or output that makes you think so (the log preferably created using the -D option).
danboid commented at 2022-06-07 09:20:¶
Am I correct in assuming then that rear cannot restore a mdraid (RAID 10) config?
pcahyna commented at 2022-06-07 09:22:¶
Your assumption is generally not correct, I have tested that config recently (not for the boot disk though).
EDIT: I have not tested either a configuration like yours where "the OS disks are something like sdh and sdi etc" so it may well behave incorrectly, but is is not like RAID10 is unsupported in general.
danboid commented at 2022-06-07 09:25:¶
but you have not said how do you know what ReaR chooses. I suppose you found out reading a log or in the program output, so please add the part of log file or output that makes you think so (the log preferably created using the -D option).
I run
rear mkbackup
And that prints something like
Using guessed bootloader EFI for 'rear recover' (found in first bytes on $disk_device with GPT BIOS boot partiion)
danboid commented at 2022-06-07 09:29:¶
For example, sda-sdg are a ZFS pool then disks sdh-sdk are mdraid array. Does rear remember which disks it should be restoring to or will it prompt me when I run the recover? Will it then re-install GRUB on each one of the disks in the mdraid array after restoring?
pcahyna commented at 2022-06-07 09:33:¶
And that prints something like
Using guessed bootloader EFI for 'rear recover' (found in first bytes on $disk_device with GPT BIOS boot partiion)
This message comes from
usr/share/rear/layout/save/default/445_guess_bootloader.sh, which sets
the bootloader to be reinstalled (case B), not the bootloader on the USB
rescue disk.
danboid commented at 2022-06-07 09:35:¶
And that prints something like
Using guessed bootloader EFI for 'rear recover' (found in first bytes on $disk_device with GPT BIOS boot partiion)This message comes from
usr/share/rear/layout/save/default/445_guess_bootloader.sh, which sets the bootloader to be reinstalled (case B), not the bootloader on the USB rescue disk.
Yes, thats what I thought it was and it rear doesn't detect it correctly so I expect it would fail to restore correctly too.
pcahyna commented at 2022-06-07 09:39:¶
For example, sda-sdg are a ZFS pool then disks sdh-sdk are mdraid array. Does rear remember which disks it should be restoring to or will it prompt me when I run the recover?
If the disks have the same names and same sizes, it should remember them (I believe it still prompts you to confirm disk mapping). But it needs to be tested for your specific case.
Will it then re-install GRUB on each one of the disks in the mdraid array after restoring?
It reinstalls GRUB on the MBR of disks that contain the /boot partition, not sure about the details though.
danboid commented at 2022-06-07 09:44:¶
For mdraid arrays, GRUB needs to installed on each disk within the array. I might have to do that bit myself if rear doesn't do it for me.
pcahyna commented at 2022-06-07 09:46:¶
Unfortunately the various bootloader and EFI related
user config variables that are described in
usr/share/rear/conf/default.conf
do not clearly distinguish between the two cases
so things get rather tricky if bootloader specific
settings are needed for special cases.
I think that BOOTLOADER is meant for case B and
USING_UEFI_BOOTLOADER is meant for case A. But
usr/share/rear/finalize/Linux-i386/660_install_grub2.sh is using
USING_UEFI_BOOTLOADER, despite being intended to handle case B. Even
more confusingly, a comment in the script says "The solution is to
specify the BOOTLOADER config variable", but the script does not use
that variable.
pcahyna commented at 2022-06-07 09:49:¶
For mdraid arrays, GRUB needs to installed on each disk within the array. I might have to do that bit myself if rear doesn't do it for me.
ReaR has a dependency resolution for storage components, so it installs
GRUB to every device that /boot resides on (including devices that are
RAID components) - so this should work.
danboid commented at 2022-06-07 09:56:¶
That's good news about the GRUB installation.
OK so my conclusion here is that rears detection of the host system firmware isn't very reliable so we should add a bit about the need to configure the BOOTLOADER variable to the README and not have this hidden away for those who read the config file in full to discover.
danboid commented at 2022-06-07 09:59:¶
I suppose my config is a niche case where the first disk doesn't reflect your firmware but I think this will still be common enough a issue to make mention of it in the README.
Something like
"Users booting using BIOS but who don't have their OS disk as their first disk will need to set the BOOTLOADER variable to configure your choice of bootloader correctly. rears choice of bootloader is otherwise auto detected by the layout of the first disk it sees."
jsmeix commented at 2022-06-07 10:07:¶
Regarding
https://github.com/rear/rear/issues/2817#issuecomment-1148442822
For mdraid arrays, GRUB needs to installed on each disk within the array
I assume you actually mean nowadays GRUB2 and not GRUB legacy.
In theory this should work via the code in
usr/share/rear/finalize/Linux-i386/660_install_grub2.sh
In practice it did sometimes not work automatically for my RAID1 tests
(I guess in particular when I experimented with recreating
on a bit different disks - but I don't remember the details).
But it always worked for me by setting GRUB2_INSTALL_DEVICES
to what I need (see its description in default.conf)
jsmeix commented at 2022-06-07 10:31:¶
Regarding
https://github.com/rear/rear/issues/2817#issuecomment-1148445475
usr/share/rear/finalize/Linux-i386/660_install_grub2.sh
...
a comment in the script says
"The solution is to specify the BOOTLOADER config variable",
but the script does not use that variable.
Each end evey time when I have to deal with our bootloader
related config variables I get confused and then
each end evey time I have to dig in our code
to get some vague idea how all that might be meant to work.
In this case
# find usr/sbin/rear usr/share/rear -type f | xargs grep 'BOOTLOADER' | egrep -v '_BOOTLOADER|NOBOOTLOADER'
shows that other finalize/Linux-i386/6*_install_*.sh
scripts check the BOOTLOADER variable, in particular
finalize/Linux-i386/630_install_grub.sh does
test "GRUB" = "$BOOTLOADER" || return 0
so it seems finalize/Linux-i386/660_install_grub2.sh
does not check BOOTLOADER because it is used as fallback
to install the nowadays most often used bootloader
unless the BOOTLOADER variable tells otherwise.
So I think
"The solution is to specify the BOOTLOADER config variable"
means:
To avoid that whatever automatisms in ReaR
may set a wrong BOOTLOADER value
the solution is to specify the BOOTLOADER config variable
to the actually right bootloader.
jsmeix commented at 2022-06-07 10:46:¶
Via
https://github.com/rear/rear/commit/33c6cc6f6ff1f8608f7227f70da2a2f2b6b532e3
I explain in finalize/Linux-i386/660_install_grub2.sh
that this script is also used as fallback to install
the nowadays most often used bootloader GRUB2
unless the BOOTLOADER variable tells to install another bootloader
(other bootloader install scripts check the BOOTLOADER variable).
Hopefully my assumption from my above
https://github.com/rear/rear/issues/2817#issuecomment-1148488339
is right so this really is how that code is actually meant.
pcahyna commented at 2022-06-07 10:50:¶
that was my understanding as well: the script does depend on
BOOTLOADER indirectly (via NOBOOTLOADER), because other scripts
check BOOTLOADER and then set NOBOOTLOADER.
danboid commented at 2022-06-07 12:29:¶
@jsmeix
It seems that because of my slightly unusual disk config, I have to
configure BOOTLOADER. Can you confirm setting BOOTLOADER to GRUB
does the same as grub2? Do you know why we have multiple variables for
GRUB? Does rear even support GRUB 1.x, 0.99 or whatever the legacy GRUB
version was? Not that I need to use that, but its part of my question
about manually setting BOOTLOADER. I also ask because on my grub2 using
machines they report as being GRUB according to strings.
EDIT
When I say 'they report as' I mean when I manually run the command that rear uses in its scripts, not what rear decides it is.
github-actions commented at 2022-08-07 03:13:¶
Stale issue message
[Export of Github issue for rear/rear.]