#2896 Issue closed: Ubuntu 22.04: rear recover: "Failed to install GRUB2 on /dev/vda" (no BIOS Boot Partition)¶
Labels: support / question, no-issue-activity
will-code-for-pizza opened issue at 2022-12-05 18:22:¶
Relax-and-Recover (ReaR) Issue Template¶
Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):
-
ReaR version ("/usr/sbin/rear -V"):
Relax-and-Recover 2.7-git.0.0.unknown / 2022-12-05 -
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
PRETTY_NAME="Ubuntu 22.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.1 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
- ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
GRUB2_INSTALL_DEVICES="/dev/vda"
### write the rescue initramfs to USB and update the USB bootloader
OUTPUT=ISO
### create a backup using the internal NETFS method, using 'tar'
BACKUP=NETFS
### write both rescue image and backup to the device labeled REAR-000
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
#USB_DEVICE_FILESYSTEM=ext4
-
Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
KVM Guest -
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
inux rear-test 5.15.0-56-generic #62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux -
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
Grub2 -
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
QCOW2 -
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
NAME KNAME PKNAME TRAN TYPE FSTYPE LABEL SIZE MOUNTPOINT
/dev/sr0 /dev/sr0 sata rom udf REAR-ISO 616.5M
/dev/vda /dev/vda disk 25G
|-/dev/vda1 /dev/vda1 /dev/vda part vfat 487M /mnt/local/boot/efi
`-/dev/vda2 /dev/vda2 /dev/vda part ext4 24.5G /mnt/local
/dev/vdb /dev/vdb disk 40G
|-/dev/vdb1 /dev/vdb1 /dev/vdb part 8M
|-/dev/vdb2 /dev/vdb2 /dev/vdb part vfat REAR-EFI 1G
`-/dev/vdb3 /dev/vdb3 /dev/vdb part ext3 REAR-000 39G
- Description of the issue (ideally so that others can reproduce it):
User confirmed to proceed with 'recover'
Start system layout restoration.
Disk '/dev/vda': creating 'gpt' partition table
Disk '/dev/vda': creating partition number 1 with name ''vda1''
Disk '/dev/vda': creating partition number 2 with name ''vda2''
Creating filesystem of type ext4 with mount point / on /dev/vda2.
Mounting filesystem /
Creating filesystem of type vfat with mount point /boot/efi on /dev/vda1.
Mounting filesystem /boot/efi
Disk layout created.
Restoring from '/var/tmp/rear.RkCSPwAlwlupS5M/outputfs/rear-test/backup.tar.gz' (restore log in /var/lib/rear/restore/recover.backup.tar.gz.1647.restore.log) ...
Restored 11239 MiB [avg. 56141 KiB/sec] OK
Restored 11239 MiB in 206 seconds [avg. 55868 KiB/sec]
Restoring finished (verify backup restore log messages in /var/lib/rear/restore/recover.backup.tar.gz.1647.restore.log)
Created SELinux /mnt/local/.autorelabel file : after reboot SELinux will relabel all files
Recreating directories (with permissions) from /var/lib/rear/recovery/directories_permissions_owner_group
Migrating disk-by-id mappings in certain restored files in /mnt/local to current disk-by-id mappings ...
Updated initramfs with new drivers for this system.
Installing GRUB2 boot loader...
Installing GRUB2 on /dev/vda (specified in GRUB2_INSTALL_DEVICES)
Failed to install GRUB2 on /dev/vda
WARNING:
For this system
Ubuntu/22.04 on Linux-i386 (based on Debian/22.04/i386)
there is no code to install a boot loader on the recovered system
or the code that we have failed to install the boot loader correctly.
Please contribute appropriate code to the Relax-and-Recover project,
see http://relax-and-recover.org/development/
Take a look at the scripts in /usr/share/rear/finalize - for example
for PC architectures like x86 and x86_64 see the script
/usr/share/rear/finalize/Linux-i386/660_install_grub2.sh
and for POWER architectures like ppc64le see the script
/usr/share/rear/finalize/Linux-ppc64le/660_install_grub2.sh
---------------------------------------------------
| IF YOU DO NOT INSTALL A BOOT LOADER MANUALLY, |
| THEN YOUR SYSTEM WILL NOT BE ABLE TO BOOT. |
---------------------------------------------------
You can use 'chroot /mnt/local bash --login'
to change into the recovered system and
manually install a boot loader therein.
Finished 'recover'. The target system is mounted at '/mnt/local'.
Exiting rear recover (PID 1647) and its descendant processes ...
Running exit tasks
-
Workaround, if any:
-
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
jsmeix commented at 2022-12-06 12:09:¶
@will-code-for-pizza
without a "rear -D recover" debug log file
we at ReaR upstream cannot guess why it
"Failed to install GRUB2 on /dev/vda".
This error message comes from
usr/share/rear/finalize/Linux-i386/660_install_grub2.sh
for current ReaR upstream GitHub masetr code at
https://github.com/rear/rear/blob/master/usr/share/rear/finalize/Linux-i386/660_install_grub2.sh#L105
if ! chroot $TARGET_FS_ROOT /bin/bash --login -c "$grub_name-install $grub2_install_device" ; then
LogPrintError "Failed to install GRUB2 on $grub2_install_device"
so what failed was the command
chroot $TARGET_FS_ROOT /bin/bash --login -c "$grub_name-install $grub2_install_device"
With "rear -D recover" there should be sufficient debug messages
in the ReaR log file in particular some (error) messages of
grub2-install or grub-install (what $grub_name-install evaluates to)
that hopefully point to the root cause wha it fails.
This code worked well for me for my tests
but I am not a Ubuntu user so when things are
different on Ubuntu there is not much what I can do
in practice (I won't find time to install Ubuntu
and try out how things behave there).
jsmeix commented at 2022-12-06 12:14:¶
@will-code-for-pizza
FYI:
See the section
"Debugging issues with Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery
that reads (excerpts)
When "rear -d -D recover" fails,
you need to save the log file
out of the ReaR recovery system
(where "rear -d -D recover" was run
and where it had failed) before you
shut down the ReaR recovery system
...
See the "First steps with Relax-and-Recover"
section above how to access the ReaR recovery
system from remote via ssh so that you can
use 'scp' to get files out of the ReaR recovery
system.
The "First steps with Relax-and-Recover" section
reads (excerpt)
SSH_ROOT_PASSWORD="rear"
Never use your original root password here.
See also the SSH_ROOT_PASSWORD description in default.conf
e.g. online for ReaR 2.7 at
https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/conf/default.conf#L1861
will-code-for-pizza commented at 2022-12-08 08:59:¶
Thanks for this hint...
I think, this is the interesting part of the log:
Found linux image: /boot/vmlinuz-5.15.0-43-generic
Found initrd image: /boot/initrd.img-5.15.0-43-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
done
++ test /dev/vda
++ grub2_install_failed=no
++ for grub2_install_device in $GRUB2_INSTALL_DEVICES
++ test -s ''
++ LogPrint 'Installing GRUB2 on /dev/vda (specified in GRUB2_INSTALL_DEVICES)'
++ Log 'Installing GRUB2 on /dev/vda (specified in GRUB2_INSTALL_DEVICES)'
++ test -w /var/log/rear/rear-rear-test.log
++ echo '2022-12-08 09:35:27.961000022 Installing GRUB2 on /dev/vda (specified in GRUB2_INSTALL_DEVICES)'
2022-12-08 09:35:27.961000022 Installing GRUB2 on /dev/vda (specified in GRUB2_INSTALL_DEVICES)
++ Print 'Installing GRUB2 on /dev/vda (specified in GRUB2_INSTALL_DEVICES)'
++ chroot /mnt/local /bin/bash --login -c 'grub-install /dev/vda'
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.
++ LogPrintError 'Failed to install GRUB2 on /dev/vda'
++ Log 'Failed to install GRUB2 on /dev/vda'
++ test -w /var/log/rear/rear-rear-test.log
++ echo '2022-12-08 09:35:32.915349993 Failed to install GRUB2 on /dev/vda'
2022-12-08 09:35:32.915349993 Failed to install GRUB2 on /dev/vda
++ PrintError 'Failed to install GRUB2 on /dev/vda'
++ grub2_install_failed=yes
If I try a
RESCUE rear-test:/var/log/rear # grub-install /dev/vda
Installing for i386-pc platform.
grub-install: warning: cannot open directory `/usr/share/locale': No such file or directory.
grub-install: error: failed to get canonical path of `none'.
it seems, that some grub related packages are missing.
So f.e. grub-efi-amd64-signed os-prober # Alternative: grub-efi-amd64
???
Cheers.
will-code-for-pizza commented at 2022-12-08 09:19:¶
RESCUE rear-test:~ # grub-install --root-directory=/mnt/local --efi-directory=/mnt/local/boot/efi /dev/vda
Installing for i386-pc platform.
grub-install: warning: cannot open directory `/usr/share/locale': No such file or directory.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.
will-code-for-pizza commented at 2022-12-08 11:38:¶
RESCUE rear-test:/usr/share/rear/finalize/Linux-i386 # mkdir /usr/share/locale
RESCUE rear-test:/usr/share/rear/finalize/Linux-i386 # grub-install --root-directory=/mnt/local --efi-directory=/mnt/local/boot/efi /dev/vda
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.
jsmeix commented at 2022-12-08 12:14:¶
The issus is that ReaR calls in
usr/share/rear/finalize/Linux-i386/660_install_grub2.sh
chroot /mnt/local /bin/bash --login -c 'grub-install /dev/vda'
which fails in your case with
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.
So it seems Ubuntu 22.04 installs itself without a BIOS Boot Partition
which is needed by grub-install /dev/vda.
I am neither a booting expert nor am I a Ubuntu user
so I cannot tell how Ubuntu 22.04 bootloader setup is done
so that it works on the original system.
What puzzles me is that GRUB2 talks about a BIOS Boot Partition
while there is /boot/efi mounted on /dev/vda1 which indicates
that UEFI is used with an EFI system partition (ESP) /dev/vda1
and I think that BIOS and UEFI somewhat contradict each other
but I am not a sufficient booting expert to make educated
statements here - in particular not off the top of my head.
From my current point of view I think ReaR may need some
Ubuntu specific enhancements so that the bootloader setup
at the end of "rear recover" also works on Ubuntu 22.04.
will-code-for-pizza commented at 2022-12-08 12:55:¶
@jsmeix , thanks for your support...
Probably, the "This GPT partition label contains no BIOS boot partition" message suggests that the rescue media was booted in legacy BIOS style, and as a result, it will wind up trying to install a BIOS version of GRUB onto a GPT-partitioned disk.
It' s just a suggestion. My crystal ball is in the wash right now :-(
Cause I use a KVM VM for testing, I will search now for how to activate
EFI boot mechanism for ISO.
Probably this would fix it.
Thanks a lot so far.
jsmeix commented at 2022-12-08 14:13:¶
@will-code-for-pizza
as far as I know the ReaR recovery medium must use the same
booting mechanism (either BIOS or UEFI) as the original system
otherwise it is not possible to intstall the right booting mechanism
(i.e. the same as on the original system) during "rear recover".
When you use UEFI on your original sytem
but "rear mkrescue" creates a ReaR recovery medium
with BIOS booting mechanism you may have to explicitly
specify things like
USING_UEFI_BOOTLOADER
UEFI_BOOTLOADER
and when you use UEFI with Secure Boot
you may have to additionally specify
SECURE_BOOT_BOOTLOADER
In general see usr/share/rear/conf/default.conf
for various things that are described therein
which are related to [U]EFI (and Secure Boot).
DEvil0000 commented at 2022-12-13 15:43:¶
@jsmeix since my changes to format and grub install it should be possible to create a recover media with one method of your choice or both boot methods (bios/uefi). The uefi case however is buggy see #2883
@will-code-for-pizza what was your rear format command used? or does
iso mode not require that command?
also you may need more grub packages depending on what you try to
achieve.
jsmeix commented at 2022-12-14 14:04:¶
Whoops!
Now I see it: OUTPUT=ISO with BACKUP_URL=usb:...
@DEvil0000 thank you to mention rear format and "iso mode"!
I think
OUTPUT=ISO
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
does not "just work", cf.
https://github.com/rear/rear/issues/2210
What should work is
OUTPUT=USB
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
cf.
https://relax-and-recover.org/documentation/getting-started
and see what I had tested e.g. in
https://github.com/rear/rear/pull/2829
where I had tested OUTPUT=USB with BIOS and UEFI
and
https://github.com/rear/rear/pull/2662
but there I had only tested OUTPUT=USB with BIOS.
Alternatively there is
OUTPUT=RAWDISK
see its description in usr/share/rear/conf/default.conf
and
https://github.com/rear/rear/issues/2698
DEvil0000 commented at 2022-12-15 13:32:¶
I don't think I ever tested the combination of OUTPUT=ISO with
BACKUP_URL=usb:... but I think this should be valid.
I would in such a case expect a ISO getting build and then written to a
device with dd using the device in BACKUP_URL. If this combination
is not valid we should document it/print a log line.
I am however not sure if this is the actual issue since it is very similar to USB related issues I faced when testing UEFI see #2883
jsmeix commented at 2022-12-15 14:33:¶
Some general info:
Our various ReaR recovery system bootloader setup things
are long grown rather complicated / convoluted pieces of code
that behave different depending on "these or those" conditions.
As far as I can remember I never tested the combination
of OUTPUT=ISO with BACKUP_URL=usb:... and I don't know
whether or not that combination should work or had ever worked
(if I knew it cannot work I would add a check and error out
when a user specified this combination).
As far as I can remember I only tested
mostly OUTPUT=ISO with BACKUP_URL=nfs:...
and less often OUTPUT=USB with BACKUP_URL=usb:...
the latter mostly with BIOS and only a bit with UEFI, cf.
https://github.com/rear/rear/pull/2829#issuecomment-1165584336
Furthermore I am not a Ubuntu user
(and I won't find time to test things on Ubuntu) and
we at ReaR upstream do not have an active maintainer who uses Ubuntu
(and it seems Canonical is not sufficiently interested in ReaR)
so ReaR support for Ubuntu can be only as good as voluntary
contributors who use Ubuntu contribute - which is much appreciated!
jsmeix commented at 2022-12-15 14:39:¶
As far as I see from plain looking at what is written in
https://github.com/rear/rear/issues/2883
grub-install: error: cannot find EFI directory
the error message there at least looks to me
as if the issue there is a different one.
But I am not a sufficient booting expert
(and even less an UEFI and/or Secure Boot expert)
to make educated statements here.
jsmeix commented at 2022-12-15 14:41:¶
@will-code-for-pizza
could you try out if the patch from @DEvil0000 in
https://github.com/rear/rear/issues/2883#issuecomment-1302006263
makes things works for you?
will-code-for-pizza commented at 2022-12-26 17:06:¶
@jsmeix , thanks for your support...
Probably, the "This GPT partition label contains no BIOS boot partition" message suggests that the rescue media was booted in legacy BIOS style, and as a result, it will wind up trying to install a BIOS version of GRUB onto a GPT-partitioned disk.
It' s just a suggestion. My crystal ball is in the wash right now :-(
Cause I use a KVM VM for testing, I will search now for how to activate EFI boot mechanism for ISO. Probably this would fix it.
Thanks a lot so far.
Hi together, after beeing ill for 2 weeks, I found time to test and my specific problem depends on the boot/EFI config of my virtual machine... :-(
Sorry for bothering you because of an environmental issue.
will-code-for-pizza commented at 2022-12-26 17:07:¶
@will-code-for-pizza
could you try out if the patch from @DEvil0000 in #2883 (comment) makes things works for you?
I will try this on a physical machine these days.
github-actions commented at 2023-03-04 02:34:¶
Stale issue message
[Export of Github issue for rear/rear.]