#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.]

#2829 PR merged: Set USB_DEVICE_PARTED_LABEL to match format-workflow.sh¶