#2303 PR merged: Enhanced recovery system BIOS boot default settings for USB and ISO (related to issue 2276

Labels: enhancement, documentation, fixed / solved / done

jsmeix opened issue at 2019-12-19 16:25:

For OUTPUT=ISO the user can now explicitly specify
what to boot by default when booting the ISO on BIOS systems via
ISO_DEFAULT="boothd0" to boot from the first disk and
ISO_DEFAULT="boothd1" to boot from the second disk.

For OUTPUT=USB the user can now explicitly specify
what to boot by default when booting the disk on BIOS systems via
USB_BIOS_BOOT_DEFAULT="boothd0" to boot from the first disk.
The default USB_BIOS_BOOT_DEFAULT="" boots the second disk.

Those things are now (hopefully correctly) explained in default.conf

Additionally usr/share/rear/conf/templates/rear.help
is now plain ASCII according to "Character encoding" in
https://github.com/rear/rear/wiki/Coding-Style
to avoid that this text may show unexpected when the
SYSLINUX boot stuff is shown to the user on whatever
possibly unusual remote console or on whatever special
system management user interface (I had some personal
"interesting user experience" with some Java based tingy ;-)

jsmeix commented at 2019-12-19 16:29:

@rear/contributors
when there are no objections
I would like to merge it tomorrow afternoon.

pcahyna commented at 2019-12-19 17:42:

@jsmeix this functionality is useful (cc @chlupnoha who will probably make use of it), but shouldn't it be an opportunity to unify those settings? Why to have one option for USB disks, another for CD images, when both do essentially the same thing? Even why to distinguish BIOS and UEFI? I propose just BOOT_DEFAULT to cover all supported cases (ISO_DEFAULT would remain for compatibility of course.) Similar comment applies to ISO_RECOVER_MODE, which does not seem to be really ISO specific, but of course this can be left for later.

jsmeix commented at 2019-12-20 08:48:

@pcahyna
on the one hand I fully agree with you in general
BUT
on the other hand because I am not at all an expert in this area
(the more I do with booting the more I know how little I know)
I must change the currently working things in careful little steps.
There are so many subtle interdependencies in ReaR that
I cannot imagine what may break when I change something.
My little step by little step way is my attempt to get a bit better
understanding how things actually work in ReaR while I am doing
those little steps so that I can a little bit better avoid regressions.
If I understood all ReaR code I would...
(cf. https://github.com/rear/rear/pull/2286#issuecomment-558624424)

Regarding why to distinguish BIOS and UEFI?

My personal answer from my (non booting expert) point of view is:
We distinguish BIOS and UEFI for ReaR config variables because
the current ReaR code is completely separated for BIOS and UEFI.

For example I wonder if BOOT_DEFAULT="boothd1" would make sense
for UEFI - is boothd1 a value that can be actually used also for UEFI?

Perhaps someting more generic like BOOT_DEFAULT="first_disk" (or disk1)
could make sense both for BIOS and UEFI - but I don't know if that is true.

Is "boot disk enumeration" a really meaningful concept for UEFI?

For example on my openSUSE Leap 15.0 system I get

# efibootmgr -v
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,0016,0017,0014,001A,0012,0013,0015,0010
Boot0000* opensuse-secureboot   HD(1,GPT,841a03d5-4e52-4634-b21a-43935c88f5af,0x800,0xfa000)/File(\EFI\opensuse\shim.efi)
Boot0010  Diskette Drive        BBS(Floppy,Diskette Drive,0x0)..BO
Boot0012* SAMSUNG SSD SM951 M.2 256G    BBS(HD,P0: SAMSUNG SSD SM951 M.2 256G,0x0)..BO
Boot0013* USB Storage Device    BBS(USB,USB Storage Device,0x0)..BO
Boot0014* CD/DVD/CD-RW Drive    BBS(CDROM,P0: PLDS DVD+/-RW DH-16AES    ,0x0)..BO
Boot0015* Onboard NIC   BBS(Network,IBA GE Slot 00C8 v1550,0x0)..BO
Boot0016* Onboard NIC(IPV4)     PciRoot(0x0)/Pci(0x19,0x0)/MAC(64006a64c006,0)/IPv4(0.0.0.0:0<->0.0.0.0:0,0,0)..BO
Boot0017* Onboard NIC(IPV6)     PciRoot(0x0)/Pci(0x19,0x0)/MAC(64006a64c006,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot001A* WDC WD10EZEX-75M2NA0          BBS(HD,P0: WDC WD10EZEX-75M2NA0      ,0x0)..BO

So the BootNNNN values have some kind of enumeration
but that enumeration does not look as if it matches what
the BIOS boot disk enumeration is.

I think when one has UEFI firmware with legacy BIOS support
one can specify the boot device ordering for UEFI differently
and separated from the boot device ordering for legacy BIOS.

Also in my above example the BootOrder list is different
compared to the "natural" ordering of the BootNNNN values
(according to the NNNN suffix).

Regarding ISO_RECOVER_MODE:

I noticed that special config variable "by accident" while I was
enhancing the description about ISO_DEFAULT in default.conf
and I was also wondering why ISO_RECOVER_MODE
is specific for OUTPUT=ISO and not a generic thingy.

Also here my personal assumtion is that the reason behind is
that the code for ISO_RECOVER_MODE is separated from
the other cases - or in other words:

A generic functionality to provide predefined ReaR recovery system
boot menue entries for some "common recovery system boot cases"
is not yet implemented in ReaR.

What is implemented in ReaR is only a single separated special case
to boot the recovery system with one predefined kernel command line
option in case of OUTPUT=ISO so the matching config variable
was correctly named to be ISO specific.

The current generic way for such things is that the user must
manually add non-standard kernel command line options.
(By the way: Is that also possible in case of UEFI?)

Finally:

At least some of the above is again the same old consequence
of how the OUTPUT=USB stuff was implemeted in ReaR:

The whole USB stuff is basically some kind of "add-on hack"
for a special use case that is not well integrated
with how the rest of ReaR works.

Cf.
https://github.com/rear/rear/issues/2171
therein A side note: in
https://github.com/rear/rear/issues/2171#issuecomment-509143476
and
https://github.com/rear/rear/issues/1166#issuecomment-272868388
and issues like
https://github.com/rear/rear/issues/1164
and probably some more...

jsmeix commented at 2019-12-20 09:01:

@chlupnoha
could you explain your ReaR use case so that I could get
a better understanding what our users do with ReaR?

jsmeix commented at 2019-12-20 11:04:

Now it is after-noon...

jsmeix commented at 2019-12-20 13:25:

I had also tested the ISO case and it worked for me.

[Export of Github issue for rear/rear.]