#2829 PR merged: Set USB_DEVICE_PARTED_LABEL to match format-workflow.sh¶
Labels: enhancement, cleanup, fixed / solved / done,
minor bug
jsmeix opened issue at 2022-06-24 06:28:¶
-
Type: Bug Fix
-
Impact: Normal
-
Reference to related issue (URL):
https://github.com/rear/rear/pull/2828#issuecomment-1164590100
- How was this pull request tested?
Tested on openSUSE Leap 15.3 laptop with BIOS, see
https://github.com/rear/rear/pull/2829#issuecomment-1165460982
and on Red Hat with BIOS, see
https://github.com/rear/rear/pull/2829#issuecomment-1165470884
and on on RHEL 8 with UEFI, see
https://github.com/rear/rear/pull/2829#issuecomment-1165570472
and on openSUSE Leap 15.3 laptop with UEFI, see
https://github.com/rear/rear/pull/2829#issuecomment-1166925033
and subsequent comments
- Brief description of the changes in this pull request:
In format/USB/default/300_format_usb_disk.sh
set USB_DEVICE_PARTED_LABEL to match format-workflow.sh
which means when a format workflow option -b/--bios or -e/--efi was
specified
set USB_DEVICE_PARTED_LABEL to "msdos" or "gpt" accordingly
and when no format workflow option -b/--bios or -e/--efi was specified
it means hybrid boot supporting BIOS and UEFI by default
so USB_DEVICE_PARTED_LABEL must be set to "gpt".
jsmeix commented at 2022-06-24 06:58:¶
It is only a "minor bug" because current ReaR
does usually not "just work out of the box",
cf. "Inappropriate expectations" in
https://en.opensuse.org/SDB:Disaster_Recovery
So the need to explicitly specify the right
USB_DEVICE_PARTED_LABEL="gpt"
in etc/rear/local.conf is OK in current ReaR.
The minor bug is that the old default setting
USB_DEVICE_PARTED_LABEL="msdos"
conflicts with the new default behaviour of what
usr/share/rear/lib/format-workflow.sh
does which is now UEFI and BIOS dual boot
see
https://github.com/rear/rear/issues/2698
jsmeix commented at 2022-06-24 07:27:¶
I fear now things fail in
prep/USB/Linux-i386/340_find_mbr_bin.sh
because with the changes in this pull request
USB_DEVICE_PARTED_LABEL is not set during "rear mkrescue".
Sigh - so many subtle interdependencies everywhere...
jsmeix commented at 2022-06-24 08:15:¶
With my two last commits I try to make it work again
by default at least in some reasonable way
as far as I currently could do it up to now,
see my new description in default.conf
jsmeix commented at 2022-06-24 11:00:¶
I tested on my openSUSE Leap 15.3 homeoffice laptop with BIOS
that with this changes the new default works for me with BIOS
so there should be no regressions with the new default
hybrid UEFI and BIOS dual boot.
I use USB_DEVICE_FILESYSTEM_PERCENTAGE=10 only
to make testing faster with my 500GB USB disk.
# grep -v '^#' etc/rear/local.conf
...
OUTPUT=USB
USB_DEVICE_FILESYSTEM_PERCENTAGE=10
BACKUP=NETFS
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
...
# usr/sbin/rear -D format /dev/sdb
...
Running 'format' stage ======================
USB or disk device /dev/sdb is not formatted with ext2/3/4 or btrfs filesystem
Formatting /dev/sdb will remove all currently existing data on that whole device
UserInput -I USB_DEVICE_CONFIRM_FORMAT needed in /root/rear.github.master/usr/share/rear/format/USB/default/200_check_usb_layout.sh line 62
Type exactly 'Yes' to format /dev/sdb with ext3 filesystem
(default 'No' timeout 300 seconds)
Yes
UserInput: No choices - result is 'Yes'
Repartitioning /dev/sdb
Creating partition table of type gpt on /dev/sdb
Making a BIOS bootable device /dev/sdb
Creating BIOS boot partition /dev/sdb1
Setting 'bios_grub' flag on BIOS boot partition /dev/sdb1
Making an EFI bootable device /dev/sdb
Creating EFI system partition /dev/sdb2 with size 1024 MiB aligned at 8 MiB
Setting 'esp' flag on EFI partition /dev/sdb2
Creating ReaR data partition /dev/sdb3 up to 10% of /dev/sdb
Setting 'legacy_boot' flag on ReaR data partition /dev/sdb3
Creating vfat filesystem on EFI system partition on /dev/sdb2
Creating ext3 filesystem with label 'REAR-000' on ReaR data partition /dev/sdb3
Adjusting filesystem parameters on ReaR data partition /dev/sdb3
Exiting rear format (PID 10744) and its descendant processes ...
# parted -s /dev/sdb unit MiB print
Model: TOSHIBA External USB 3.0 (scsi)
Disk /dev/sdb: 476940MiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 0.02MiB 8.00MiB 7.98MiB primary bios_grub
2 8.00MiB 1032MiB 1024MiB fat32 primary boot, esp
3 1032MiB 47694MiB 46662MiB ext3 primary legacy_boot
# usr/sbin/rear -D mkrescue
...
Running 'output' stage ======================
Saved /root/rear.github.master/var/log/rear/rear-linux-h9wr.log as rear/linux-h9wr/20220624.1223/rear-linux-h9wr.log
Making /dev/sdb bootable with syslinux/extlinux
Writing syslinux MBR /usr/share/syslinux/gptmbr.bin of type gpt to /dev/sdb
Exiting rear mkrescue (PID 12843) and its descendant processes ...
# usr/sbin/rear -D mkbackup
...
Saved /root/rear.github.master/var/log/rear/rear-linux-h9wr.log as rear/linux-h9wr/20220624.1225/rear-linux-h9wr.log
No need to update syslinux on /dev/sdb that has version 4.04
Running 'backup' stage ======================
Making backup (using backup method NETFS)
...
Exiting rear mkbackup (PID 5448) and its descendant processes ...
# mount /dev/sdb3 /tmp/sdb3
# find /tmp/sdb3
/tmp/sdb3
/tmp/sdb3/boot
/tmp/sdb3/boot/syslinux
/tmp/sdb3/boot/syslinux/cpuid.c32
/tmp/sdb3/boot/syslinux/hdt.c32
/tmp/sdb3/boot/syslinux/cat.c32
/tmp/sdb3/boot/syslinux/poweroff.com
/tmp/sdb3/boot/syslinux/reboot.c32
/tmp/sdb3/boot/syslinux/rear.help
/tmp/sdb3/boot/syslinux/pci.ids
/tmp/sdb3/boot/syslinux/config.c32
/tmp/sdb3/boot/syslinux/menu.c32
/tmp/sdb3/boot/syslinux/cmd.c32
/tmp/sdb3/boot/syslinux/ldlinux.sys
/tmp/sdb3/boot/syslinux/sysdump.c32
/tmp/sdb3/boot/syslinux/ls.c32
/tmp/sdb3/boot/syslinux/vesamenu.c32
/tmp/sdb3/boot/syslinux/host.c32
/tmp/sdb3/boot/syslinux/message
/tmp/sdb3/boot/syslinux/disk.c32
/tmp/sdb3/boot/syslinux/kbdmap.c32
/tmp/sdb3/boot/syslinux/chain.c32
/tmp/sdb3/boot/syslinux/extlinux.conf
/tmp/sdb3/boot/syslinux/rosh.c32
/tmp/sdb3/boot/syslinux/lua.c32
/tmp/sdb3/lost+found
/tmp/sdb3/rear
/tmp/sdb3/rear/syslinux.cfg
/tmp/sdb3/rear/linux-h9wr
/tmp/sdb3/rear/linux-h9wr/20220624.1225
/tmp/sdb3/rear/linux-h9wr/20220624.1225/backup.log
/tmp/sdb3/rear/linux-h9wr/20220624.1225/syslinux.cfg
/tmp/sdb3/rear/linux-h9wr/20220624.1225/kernel
/tmp/sdb3/rear/linux-h9wr/20220624.1225/initrd.cgz
/tmp/sdb3/rear/linux-h9wr/20220624.1225/rear-linux-h9wr.log
/tmp/sdb3/rear/linux-h9wr/20220624.1225/backup.tar.gz
/tmp/sdb3/rear/linux-h9wr/20220624.1223
/tmp/sdb3/rear/linux-h9wr/20220624.1223/syslinux.cfg
/tmp/sdb3/rear/linux-h9wr/20220624.1223/kernel
/tmp/sdb3/rear/linux-h9wr/20220624.1223/initrd.cgz
/tmp/sdb3/rear/linux-h9wr/20220624.1223/rear-linux-h9wr.log
/tmp/sdb3/linux-h9wr
/tmp/sdb3/linux-h9wr/.lockfile
I can boot the ReaR recovery from that USB disk
on another rather old laptop that only supports BIOS
and the booted ReaR recovery seems to work normally for me
(i.e. logged in as 'root' and tried this or that commands).
But I cannot actually test "rear recover" because I want
to keep what there currently is on that old laptop.
Currently I cannot test UEFI because I don't have
sufficient test machines available for testing in homeoffice
(currently I need my newer UEFI laptop for other work).
lzaoral commented at 2022-06-24 11:13:¶
@jsmeix thanks! I've also tested this PR in the BIOS setting and formatting works and rescue boots and recovers fine. I'm testing EFI and I'll report with the results soon.
jsmeix commented at 2022-06-24 11:41:¶
@lzaoral
thank you so much for your testing!
It helps so much when at least one other person verifies things.
Now I am rather confident that we don't introduce bad regressions
with the new default hybrid UEFI and BIOS dual boot.
I will document possible consequences of that change
in our release notes for ReaR 2.7
which are currently (unfinished) at
https://github.com/rear/rear.github.com/blob/jsmeix-release-notes-2-7/documentation/release-notes-2-7.md
I tried to boot from my above made USB disk also
on my newer UEFI laptop but I failed to specify
in its rather limited "InsydeH2O UEFI BIOS" [sic!]
(see
https://www.insyde.com/products
they call their UEFI firmware "BIOS")
how to boot from my USB disk.
I have openSUSE Leap 15.3 installed on this laptop
from a USB stick so it must be possible to boot
from an appropriately made USB stick.
My blind guess is the reason is that my current USB disk
is not ready for EFI boot in particular because its ESP is empty:
# mount /dev/sdb2 /tmp/sdb2
# find /tmp/sdb2 -ls
1 4 drwxr-xr-x 2 root root 4096 Jan 1 1970 /tmp/sdb2
I will try out how things behave with
USB_BOOTLOADER="grub"
pcahyna commented at 2022-06-24 11:50:¶
my current USB disk
is not ready for EFI boot in particular because its ESP is empty
this does not look good - does the master branch code (without your change) behave the same way?
jsmeix commented at 2022-06-24 13:01:¶
With my last two commits here I implemented
https://github.com/rear/rear/pull/2829/files#r906006257
lzaoral commented at 2022-06-24 13:22:¶
@jsmeix EFI seems to work both with hybrid and --efi USB layout
(though I tested it without the two latest commits). Rescue image boots
fine and the recovered OS also seems to work.
my current USB disk
is not ready for EFI boot in particular because its ESP is empty
I've tested it on RHEL 8 and the ESP always contained all the necessary files so maybe is this problem openSUSE specific? ESP on RHEL 8:
# tree /mnt/rear-esp/
/mnt/rear-esp/
└── EFI
└── BOOT
├── BOOTX64.efi
├── grub.cfg
├── initrd.cgz
└── kernel
I've also tested -b layout on a BIOS machine with latest HEADwithout
USB_DEVICE_PARTED_LABEL being set and everything worked fine.
jsmeix commented at 2022-06-24 13:37:¶
@lzaoral
again very many thanks for your UEFI testing!
I don't have sufficient UEFI testing hardware
so I cannot sufficiently test UEFI booting.
But that is OK for me because I cannot do
all and everything alone for ReaR in openSUSE and
OUTPUT=USB is not much used in business environments.
So whether or not OUTPUT=USB "just works" with UEFI
has currently no high priority regarding SLES customers
(which may instantly change when a SLES issue appears
from a customer with an official SUSE support contract).
Currently for me the topmost important thing is that
our new UEFI and BIOS dual boot default for OUTPUT=USB
does not cause major regressions.
jsmeix commented at 2022-06-24 13:49:¶
@pcahyna
regarding your
https://github.com/rear/rear/pull/2829#issuecomment-1165497740
also with master branch code (without the changes here)
the ESP is empty for me
jsmeix commented at 2022-06-24 13:50:¶
@pcahyna @lzaoral
weekend is approaching so I leave now.
I wish you a relaxed and recovering weekend!
jsmeix commented at 2022-06-27 06:22:¶
I am testing on my newer openSUSE Leap 15.3 homeoffice laptop with
UEFI
that with this changes the new default works for me with UEFI:
# cat etc/rear/local.conf
...
OUTPUT=USB
USB_DEVICE_FILESYSTEM_PERCENTAGE=10
BACKUP=NETFS
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
...
# usr/sbin/rear -D format /dev/sda
Relax-and-Recover 2.6 / Git
Running rear format (PID 6894 date 2022-06-27 08:08:50)
Command line options: usr/sbin/rear -D format /dev/sda
Using log file: /root/rear.github.master/var/log/rear/rear-linux.log
Using build area: /var/tmp/rear.KvhzPepOK8mSWkO
Running 'init' stage ======================
Running workflow format on the normal/original system
Running 'format' stage ======================
USB or disk device /dev/sda is not formatted with ext2/3/4 or btrfs filesystem
Formatting /dev/sda will remove all currently existing data on that whole device
UserInput -I USB_DEVICE_CONFIRM_FORMAT needed in /root/rear.github.master/usr/share/rear/format/USB/default/200_check_usb_layout.sh line 62
Type exactly 'Yes' to format /dev/sda with ext3 filesystem
(default 'No' timeout 300 seconds)
Yes
UserInput: No choices - result is 'Yes'
Repartitioning /dev/sda
Creating partition table of type gpt on /dev/sda
Making a BIOS bootable device /dev/sda
Creating BIOS boot partition /dev/sda1
Setting 'bios_grub' flag on BIOS boot partition /dev/sda1
Making an EFI bootable device /dev/sda
Creating EFI system partition /dev/sda2 with size 1024 MiB aligned at 8 MiB
Setting 'esp' flag on EFI partition /dev/sda2
Creating ReaR data partition /dev/sda3 up to 10% of /dev/sda
Setting 'legacy_boot' flag on ReaR data partition /dev/sda3
Creating vfat filesystem on EFI system partition on /dev/sda2
Creating ext3 filesystem with label 'REAR-000' on ReaR data partition /dev/sda3
Adjusting filesystem parameters on ReaR data partition /dev/sda3
Exiting rear format (PID 6894) and its descendant processes ...
# parted -s /dev/sda unit MiB print
Model: TOSHIBA External USB 3.0 (scsi)
Disk /dev/sda: 476940MiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 0.02MiB 8.00MiB 7.98MiB primary bios_grub
2 8.00MiB 1032MiB 1024MiB fat32 primary boot, esp
3 1032MiB 47694MiB 46662MiB ext3 primary legacy_boot
# mount /dev/sda2 /tmp/sda2
# find /tmp/sda2
/tmp/sda2
# mount /dev/sda3 /tmp/sda3
# find /tmp/sda3
/tmp/sda3
/tmp/sda3/lost+found
# umount /tmp/sda2 /tmp/sda3
# usr/sbin/rear -D mkrescue
...
Running 'prep' stage ======================
Found EFI system partition /dev/nvme0n1p1 on /boot/efi type vfat
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
...
Running 'rescue' stage ======================
...
Trying to find what to use as UEFI bootloader...
Trying to find a 'well known file' to be used as UEFI bootloader...
Using '/boot/efi/EFI/opensuse/grubx64.efi' as UEFI bootloader file
...
Running 'output' stage ======================
Configuring EFI partition '/dev/disk/by-label/REAR-EFI' for EFI boot with 'grubx64.efi'
Configuring GRUB2 for EFI boot
Configuring GRUB2 kernel /EFI/BOOT/kernel
Configuring GRUB2 initrd /EFI/BOOT/initrd.cgz
Configuring GRUB2 root device as 'search --no-floppy --set=root --label REAR-EFI'
GRUB2 modules to load: cryptodisk ext2 fat gcry_rijndael gcry_sha256 luks part_gpt part_msdos
Saved /root/rear.github.master/var/log/rear/rear-linux.log as rear/linux/20220627.0811/rear-linux.log
Making /dev/sda bootable with syslinux/extlinux
Writing syslinux MBR /usr/share/syslinux/gptmbr.bin of type gpt to /dev/sda
Exiting rear mkrescue (PID 7666) and its descendant processes ...
# mount /dev/sda2 /tmp/sda2
# find /tmp/sda2
/tmp/sda2
/tmp/sda2/EFI
/tmp/sda2/EFI/BOOT
/tmp/sda2/EFI/BOOT/BOOTX64.efi
/tmp/sda2/EFI/BOOT/kernel
/tmp/sda2/EFI/BOOT/initrd.cgz
/tmp/sda2/EFI/BOOT/grub.cfg
# mount /dev/sda3 /tmp/sda3
# find /tmp/sda3
/tmp/sda3
/tmp/sda3/lost+found
/tmp/sda3/linux
/tmp/sda3/linux/.lockfile
/tmp/sda3/rear
/tmp/sda3/rear/linux
/tmp/sda3/rear/linux/20220627.0811
/tmp/sda3/rear/linux/20220627.0811/syslinux.cfg
/tmp/sda3/rear/linux/20220627.0811/kernel
/tmp/sda3/rear/linux/20220627.0811/rear-linux.log
/tmp/sda3/rear/linux/20220627.0811/initrd.cgz
/tmp/sda3/rear/syslinux.cfg
/tmp/sda3/boot
/tmp/sda3/boot/syslinux
/tmp/sda3/boot/syslinux/config.c32
/tmp/sda3/boot/syslinux/disk.c32
/tmp/sda3/boot/syslinux/reboot.c32
/tmp/sda3/boot/syslinux/cat.c32
/tmp/sda3/boot/syslinux/message
/tmp/sda3/boot/syslinux/chain.c32
/tmp/sda3/boot/syslinux/lua.c32
/tmp/sda3/boot/syslinux/cpuid.c32
/tmp/sda3/boot/syslinux/menu.c32
/tmp/sda3/boot/syslinux/rear.help
/tmp/sda3/boot/syslinux/sysdump.c32
/tmp/sda3/boot/syslinux/kbdmap.c32
/tmp/sda3/boot/syslinux/ldlinux.sys
/tmp/sda3/boot/syslinux/pci.ids
/tmp/sda3/boot/syslinux/poweroff.com
/tmp/sda3/boot/syslinux/vesamenu.c32
/tmp/sda3/boot/syslinux/cmd.c32
/tmp/sda3/boot/syslinux/hdt.c32
/tmp/sda3/boot/syslinux/extlinux.conf
/tmp/sda3/boot/syslinux/rosh.c32
/tmp/sda3/boot/syslinux/ls.c32
/tmp/sda3/boot/syslinux/host.c32
# umount /tmp/sda2 /tmp/sda3
# lsblk -ipo NAME,TRAN,TYPE,FSTYPE,LABEL,SIZE /dev/sda
NAME TRAN TYPE FSTYPE LABEL SIZE
/dev/sda usb disk 465.8G
|-/dev/sda1 part 8M
|-/dev/sda2 part vfat REAR-EFI 1G
`-/dev/sda3 part ext3 REAR-000 45.6G
jsmeix commented at 2022-06-27 07:27:¶
Booting that same newer homeoffice laptop with UEFI
from the USB disk in UEFI mode works for me.
The USB disk is automatically listed in the
boot menu of the laptop's firmware.
When I boot from the USB disk I get the GRUB2 boot menu.
On that laptop it did not work out of the box
to start up the ReaR recovery system
because after some kernel boot messages
there was no further output at the boot message
Found device /dev/ttyS0.
but I still noticed some USB disk access activity noise.
I guessed it is perhaps only a graphics driver issue
(i.e. a kernel mode setting issue)
because that laptop has a separated Nvidia GPU
and an AMD CPU with integrated AMD graphics
so I guessed the actual issue is that I only
do no longer see any further output on the console.
So I did another boot attempt and
in the GRUB2 boot menu I edited the boot entry:
I added the kernel command line parameters
nomodeset vga=normal
(into the 'linux' line of the the boot entry)
and with that the ReaR recovery system startup looks normal.
I don't know if both kernel command line parameters are needed.
Perhaps only 'nomodeset' or only 'vga=normal' is sufficient.
I try that out later.
The booted ReaR recovery seems to work normally for me
(i.e. logged in as 'root' and tried this or that commands).
But I cannot actually test "rear recover"
because I need that laptop for my normal work.
Regarding kernel command line parameter
vga=normal
see
https://github.com/rear/rear/pull/2791
where we tried to set it everywhere when booting
the ReaR recovery system but it seems 'vga=normal'
is missing when booting from USB via GRUB2.
Furhermore we should think about if additionally
the kernel command line parameter
nomodeset
may make sense in general when booting the ReaR recovery system
because in general the ReaR recovery system does not need
any sophisticated graphical mode so sticking to plain default
traditional text console mode should be sufficient and
perhaps enforcing that via 'nomodeset vga=normal' could
make booting the ReaR recovery system more fail-safe.
But this would be a separated issue for ReaR 2.8
that does not belong to this pull request.
jsmeix commented at 2022-06-27 07:36:¶
Sigh - last Friday somehow I overlooked another place where
the value of USB_DEVICE_PARTED_LABEL is used:
It is also used in output/USB/Linux-i386/850_make_USB_bootable.sh
LogPrint "Writing syslinux MBR $SYSLINUX_MBR_BIN of type $USB_DEVICE_PARTED_LABEL to $RAW_USB_DEVICE"
So I will change prep/USB/Linux-i386/340_find_mbr_bin.sh
to set USB_DEVICE_PARTED_LABEL to the right value
via the current 'lsblk' automatism in this pull request
and use a user specified value only as fallback
when the 'lsblk' automatism doesn't work (on older systems).
jsmeix commented at 2022-06-27 08:55:¶
The hybrid boot USB disk that I made
on newer homeoffice laptop with UEFI in
https://github.com/rear/rear/pull/2829#issuecomment-1166925033
booted well also on my rather old laptop that only supports BIOS.
In a second test I also added 'nomodeset'
('vga=normal' was already there)
to the SYSLINUX/EXTLINUX boot entry
(via the [Tab] key in the SYSLINUX/EXTLINUX boot menu)
and it made no difference how booting looks and
how the running ReaR recovery system looks
on that rather old laptop that only supports BIOS.
jsmeix commented at 2022-06-27 12:19:¶
With latest commit
https://github.com/rear/rear/pull/2829/commits/0ad6be092a033a154287db69829c66727e55ed71
things look explicable to me for the first time
when I create a USB disk for ReaR
on my homeoffice laptop with BIOS
in debug mode:
# usr/sbin/rear -D format /dev/sdb
...
Repartitioning /dev/sdb
Creating partition table of type gpt on /dev/sdb
Making a BIOS bootable device /dev/sdb
Creating BIOS boot partition /dev/sdb1
Setting 'bios_grub' flag on BIOS boot partition /dev/sdb1
Making an EFI bootable device /dev/sdb
Creating EFI system partition /dev/sdb2 with size 1024 MiB aligned at 8 MiB
Setting 'esp' flag on EFI partition /dev/sdb2
Creating ReaR data partition /dev/sdb3 up to 10% of /dev/sdb
Setting 'legacy_boot' flag on ReaR data partition /dev/sdb3
Creating vfat filesystem on EFI system partition on /dev/sdb2
Creating ext3 filesystem with label 'REAR-000' on ReaR data partition /dev/sdb3
Adjusting filesystem parameters on ReaR data partition /dev/sdb3
Exiting rear format (PID 25034) and its descendant processes ...
# usr/sbin/rear -D mkrescue
...
Running 'output' stage ======================
Skip configuring EFI partition '/dev/disk/by-label/REAR-EFI' for EFI boot (USING_UEFI_BOOTLOADER is not 'true')
...
Making /dev/sdb bootable with syslinux/extlinux
Writing syslinux MBR /usr/share/syslinux/gptmbr.bin of type gpt to /dev/sdb
Exiting rear mkrescue (PID 25721) and its descendant processes ...
jsmeix commented at 2022-06-28 10:34:¶
Using my USB disk "as is" which I made above in
https://github.com/rear/rear/pull/2829#issuecomment-1167282206
on my newer homeoffice laptop with UEFI
(without doing a new "rear format")
things look promising during "rear -D mkrescue":
# lsblk -ipo NAME,TRAN,TYPE,FSTYPE,LABEL,SIZE /dev/sda
NAME TRAN TYPE FSTYPE LABEL SIZE
/dev/sda usb disk 465.8G
|-/dev/sda1 part 8M
|-/dev/sda2 part vfat REAR-EFI 1G
`-/dev/sda3 part ext3 REAR-000 45.6G
# usr/sbin/rear -D mkrescue
...
Running 'prep' stage ======================
Found EFI system partition /dev/nvme0n1p1 on /boot/efi type vfat
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
...
Running 'rescue' stage ======================
...
Trying to find what to use as UEFI bootloader...
Trying to find a 'well known file' to be used as UEFI bootloader...
Using '/boot/efi/EFI/opensuse/grubx64.efi' as UEFI bootloader file
...
Running 'output' stage ======================
Configuring EFI partition '/dev/disk/by-label/REAR-EFI' for EFI boot with 'grubx64.efi'
Configuring GRUB2 for EFI boot
Configuring GRUB2 kernel /EFI/BOOT/kernel
Configuring GRUB2 initrd /EFI/BOOT/initrd.cgz
Configuring GRUB2 root device as 'search --no-floppy --set=root --label REAR-EFI'
GRUB2 modules to load: cryptodisk ext2 fat gcry_rijndael gcry_sha256 luks part_gpt part_msdos
...
No need to update syslinux on /dev/sda that has version 4.04
Exiting rear mkrescue (PID 8206) and its descendant processes ...
# mount /dev/sda2 /tmp/sda2
# find /tmp/sda2
/tmp/sda2
/tmp/sda2/EFI
/tmp/sda2/EFI/BOOT
/tmp/sda2/EFI/BOOT/BOOTX64.efi
/tmp/sda2/EFI/BOOT/kernel
/tmp/sda2/EFI/BOOT/initrd.cgz
/tmp/sda2/EFI/BOOT/grub.cfg
# cat /tmp/sda2/EFI/BOOT/grub.cfg
search --no-floppy --set=root --label REAR-EFI
insmod all_video
set gfxpayload=keep
insmod part_gpt
insmod part_msdos
insmod ext2
set timeout="300"
set default="chainloader"
set fallback="chainloader"
echo 'Switching to GRUB2 boot menu...'
sleep --verbose --interruptible 3
menuentry "Relax-and-Recover (BIOS or UEFI without Secure Boot)" --id=rear {
insmod gzio
insmod xzio
echo 'Loading kernel /EFI/BOOT/kernel ...'
linux /EFI/BOOT/kernel root=UUID=f71b20bf-dd1b-4d6f-94a4-0819c9a3f1dc selinux=0
echo 'Loading initial ramdisk /EFI/BOOT/initrd.cgz ...'
initrd /EFI/BOOT/initrd.cgz
}
menuentry "Relax-and-Recover (UEFI and Secure Boot)" --id=rear_secure_boot {
insmod gzio
insmod xzio
echo 'Loading kernel /EFI/BOOT/kernel ...'
linuxefi /EFI/BOOT/kernel root=UUID=f71b20bf-dd1b-4d6f-94a4-0819c9a3f1dc selinux=0
echo 'Loading initial ramdisk /EFI/BOOT/initrd.cgz ...'
initrdefi /EFI/BOOT/initrd.cgz
}
menuentry "Boot next EFI" --id=chainloader {
insmod chain
search --fs-uuid --no-floppy --set=esp EEA5-D588
chainloader ($esp)/EFI/opensuse/grubx64.efi
}
menuentry "Reboot" --id=reboot {
reboot
}
menuentry "Exit to EFI shell" --id=exit {
exit
}
One thing that might look a bit inconsistent is
Running 'prep' stage ======================
Found EFI system partition /dev/nvme0n1p1 on /boot/efi type vfat
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
versus
Running 'output' stage ======================
Configuring EFI partition '/dev/disk/by-label/REAR-EFI' for EFI boot with 'grubx64.efi'
i.e. it checks if there is an ESP on the original system
to set USING_UEFI_BOOTLOADER=1 but later it checks
if there is an ESP on the USB disk to set up EFI booting on the USB
disk.
I am not an EFI expert but I think this is not inconsistent
but exactly right because to set up EFI booting on the USB disk
an EFI application is needed and for that a prerequirement is
that there is an ESP on the original system
where such an EFI application can be found.
In rescue/default/850_save_sysfs_uefi_vars.sh
UEFI_BOOTLOADER is set to such a found EFI application
inside the ESP on the original system and later
in output/USB/Linux-i386/100_create_efiboot.sh
that UEFI_BOOTLOADER is copied into the ESP on the USB disk.
My USB disk contents on the "REAR-000" data partition:
# mount /dev/sda3 /tmp/sda3
# find /tmp/sda3
/tmp/sda3
/tmp/sda3/rear
/tmp/sda3/rear/linux-h9wr
/tmp/sda3/rear/linux-h9wr/20220627.1408
/tmp/sda3/rear/linux-h9wr/20220627.1408/kernel
/tmp/sda3/rear/linux-h9wr/20220627.1408/initrd.cgz
/tmp/sda3/rear/linux-h9wr/20220627.1408/rear-linux-h9wr.log
/tmp/sda3/rear/linux-h9wr/20220627.1408/syslinux.cfg
/tmp/sda3/rear/syslinux.cfg
/tmp/sda3/rear/linux
/tmp/sda3/rear/linux/20220628.1157
/tmp/sda3/rear/linux/20220628.1157/rear-linux.log
/tmp/sda3/rear/linux/20220628.1157/kernel
/tmp/sda3/rear/linux/20220628.1157/initrd.cgz
/tmp/sda3/rear/linux/20220628.1157/syslinux.cfg
/tmp/sda3/linux-h9wr
/tmp/sda3/linux-h9wr/.lockfile
/tmp/sda3/boot
/tmp/sda3/boot/syslinux
/tmp/sda3/boot/syslinux/config.c32
/tmp/sda3/boot/syslinux/cpuid.c32
/tmp/sda3/boot/syslinux/ldlinux.sys
/tmp/sda3/boot/syslinux/disk.c32
/tmp/sda3/boot/syslinux/cat.c32
/tmp/sda3/boot/syslinux/kbdmap.c32
/tmp/sda3/boot/syslinux/sysdump.c32
/tmp/sda3/boot/syslinux/rosh.c32
/tmp/sda3/boot/syslinux/host.c32
/tmp/sda3/boot/syslinux/lua.c32
/tmp/sda3/boot/syslinux/rear.help
/tmp/sda3/boot/syslinux/reboot.c32
/tmp/sda3/boot/syslinux/extlinux.conf
/tmp/sda3/boot/syslinux/poweroff.com
/tmp/sda3/boot/syslinux/menu.c32
/tmp/sda3/boot/syslinux/message
/tmp/sda3/boot/syslinux/hdt.c32
/tmp/sda3/boot/syslinux/pci.ids
/tmp/sda3/boot/syslinux/cmd.c32
/tmp/sda3/boot/syslinux/chain.c32
/tmp/sda3/boot/syslinux/vesamenu.c32
/tmp/sda3/boot/syslinux/ls.c32
/tmp/sda3/lost+found
/tmp/sda3/linux
/tmp/sda3/linux/.lockfile
jsmeix commented at 2022-06-28 11:00:¶
I tried booting from the above in
https://github.com/rear/rear/pull/2829#issuecomment-1168547117
made USB disk on my newer homeoffice laptop with UEFI:
In the GRUB2 boot menu I edited the boot entry:
I added the kernel command line parameter 'vga=normal'
(into the 'linux' line of the the boot entry)
but with only that during ReaR recovery system startup
there was no further output at the boot message
"Found device /dev/ttyS0."
so 'vga=normal' alone does not help, cf. above
https://github.com/rear/rear/pull/2829#issuecomment-1166985075
But adding only the kernel command line parameter 'nomodeset'
is sufficient to let the ReaR recovery system startup look normal.
Again the booted ReaR recovery seems to work normally for me
(i.e. logged in as 'root' and tried this or that commands).
jsmeix commented at 2022-06-28 11:40:¶
Also I tried booting from the above in
https://github.com/rear/rear/pull/2829#issuecomment-1168547117
made USB disk on my rather old laptop that only supports BIOS
and the booted ReaR recovery seems to work normally for me
(i.e. logged in as 'root' and tried this or that commands).
With SYSLINUX/EXTLINUX that is used as bootloader for BIOS
I can select in the SYSLINUX/EXTLINUX boot menu
which one of the two ReaR recovery systems to boot
/tmp/sda3/rear/linux-h9wr
/tmp/sda3/rear/linux-h9wr/20220627.1408
/tmp/sda3/rear/linux-h9wr/20220627.1408/kernel
/tmp/sda3/rear/linux-h9wr/20220627.1408/initrd.cgz
/tmp/sda3/rear/linux-h9wr/20220627.1408/rear-linux-h9wr.log
/tmp/sda3/rear/linux-h9wr/20220627.1408/syslinux.cfg
or
/tmp/sda3/rear/linux/20220628.1157
/tmp/sda3/rear/linux/20220628.1157/rear-linux.log
/tmp/sda3/rear/linux/20220628.1157/kernel
/tmp/sda3/rear/linux/20220628.1157/initrd.cgz
/tmp/sda3/rear/linux/20220628.1157/syslinux.cfg
This is currently not possible with UEFI booting
where GRUB2 is used as bootloader, see item '(b)' in
https://github.com/rear/rear/issues/2666
and
https://github.com/rear/rear/issues/2818
jsmeix commented at 2022-06-28 11:46:¶
@lzaoral @pcahyna @rear/contributors
because things work sufficiently well for me
according to my personal tests above
I would like to merge it tomorrow afternoon
unless there are objections.
[Export of Github issue for rear/rear.]