#2944 Issue closed: Deprecate MBR/BIOS boot in favour of UEFI boot?¶
Labels: discuss / RFC, won't fix / can't fix / obsolete
schlomo opened issue at 2023-02-22 09:06:¶
Question to @rear/contributors and the public: Who still needs MBR / BIOS booting in 2023?
Maybe the time has come to simplify the next ReaR release to support only UEFI booting and use that to unify the boot code between ISO and USB/disk booting?
Of course all the other boot methods that use just kernel and initrd like PXE won't be affected.
This might also help #2884 #2843 #2698 #2648 #2938 and all the other syslinux-related bug reports
On the other hand:
sadly modern UEFI is quite rare for the hardware pool at our customers sice they tend to have special
hardware and keep it for at least 10years. I need all the legacy features for some machines while for
some I need the modern ones.
Originally posted by @DEvil0000 in https://github.com/rear/rear/issues/2698#issuecomment-946945265
@DEvil0000 can you provide some insights to help with the question of this issue? Can those "special hardware" cases be happy with using equally old ReaR versions or do they actually have to use or would benefit from using the most recent ReaR version?
jsmeix commented at 2023-02-22 10:59:¶
As far as I know MBR and BIOS are still
often used on virtual machines and
I assume they will be still often used there
for some (possibly even longer) time in the future.
Furthermore I don't know how much older (server) hardware is in use
where newer Linux distributions get installed nevertheless
(e.g. because the old hardware still "just works")
so newer ReaR versions are also needed there.
Finally I guess MBR and BIOS are still often used on
special hardware, e.g. some kind of embedded systems
where old and well known MBR and BIOS are still
perfectly sufficient for what is needed in practice.
For example I remember a case some years ago
where ReaR is used in offshore wind turbines.
Perhaps in some years they upgrade their OS there
and then they may also need a matching new ReaR?
schlomo commented at 2023-02-22 11:04:¶
All virtualisation hosts and all hardware (both enterprise and consumer) sold in the last 10 years support UEFI booting. True is that not everybody uses it, but the tech supports it.
Embedded system based on x86_64 or i386 indeed might only support
MBR boot, but then everybody using embedded systems usually also knows
how to create custom boot media.
And, again, ReaR 2.7 will continue to work for those users
pcahyna commented at 2023-02-22 11:46:¶
Most of VMs I have used emulate BIOS, not UEFI. The hypervisor may
support UEFI, but if you got a machine with BIOS and you don't have
rights to request what you want from the hypervisor (because it is some
other team that provides already configured VMs to you), you are out of
luck.
I am using BIOS much more than UEFI at work , so I would be negatively
affected by the change.
didacog commented at 2023-02-22 12:27:¶
Stop supporting BIOS/MBR and only support UEFI is a start for other problems, because are other platforms besides UEFI... We are working on homogenization of ReaR booting from DRLM. Well... we started few years ago using GRUB2 for PXE, but i think all the booting can be done using GRUB2 also for ISO and USB. We are working on it anyway, so when we finish our testings and possible implementations, we may send a PR to use a new "multi-platform" boot method using GRUB2 the way we are figuring it out from DRLM project. So this way we do not need to deprecate any platform. just homogenize the booting in ReaR. How it sounds to you guys?
schlomo commented at 2023-02-22 12:49:¶
Wow @didacog that sounds really great!
Maybe adding a "new" unified boot solution alongside and seeing how that works out before we remove the old version is a good idea, after all we did the same with the layout code that was optional in the very beginning.
jsmeix commented at 2023-02-22 12:49:¶
Simply put:
I do not want to lose current users of ReaR.
I would prefer to get more and more users of ReaR.
We need many users because only few will contribute to ReaR.
Why removing unmaintained code where we don't know if it still works?
If it still works - good!
If it doesn't work but nobody uses it - doesn't matter in practice.
If it doesn't work but nobody who uses it reports issues - who cares?
If it doesn't work but someone who needs it only complains here - bad!
If it doesn't work and someone who needs it contributes a fix - good!
In contrast first deprecating then removing is OK.
First declare old things deprecated and
show the user that it is planned to get removed
then wait some reasonable time for user feedback.
If there was no negative user feedback,
then we can safely remove code.
schlomo commented at 2023-02-22 12:57:¶
OK, a convincing argument.
How about we add a "DeprecationError" function that takes a hint and aborts with a suitable explanation that if they don't reach out to us and explain the need for keeping it - and sponsoring something - we will eventually remove that. Maybe also combined with a "X is deprecated, please use Y instead" hint.
Users can then set something like DISABLE_DEPRECATION_ERRORS=true to
express their wish to use that code nevertheless (all power to the
user...).
jsmeix commented at 2023-02-22 13:02:¶
@didacog
do I understand your proposal right that it is basically about
to use GRUB2 as "the one and only" common bootloader in all cases?
If yes I do very much appreciate it (because as booting noob I only
understand GRUB2 a bit but not the other bootloaders).
GRUB2 for OUTPUT=USB is already implemented
which was mostly contributed by @DEvil0000
This or that does not yet work perfectly well there
but usable basic functionality already works
(it worked even for me).
I like to get rid of SYSLINUX/EXTLINUX as USB disk bootloader
and use only GRUB2 when GRUB2 works sufficiently well, see
https://github.com/rear/rear/pull/2829#discussion_r906045476
In general regarding OUTPUT=USB booting see
https://github.com/rear/rear/issues/2648
and
https://github.com/rear/rear/issues/2666
and
https://github.com/rear/rear/issues/2698
jsmeix commented at 2023-02-22 13:05:¶
A "DeprecationError" function would be perfectly fine!
Cf. my offhanded proposal with same intent behind
(but different implementation):
https://github.com/rear/rear/pull/2937#issuecomment-1439773886
didacog commented at 2023-02-22 13:19:¶
Wow @didacog that sounds really great!
Maybe adding a "new" unified boot solution alongside and seeing how that works out before we remove the old version is a good idea, after all we did the same with the layout code that was optional in the very beginning.
Yes this is the idea @schlomo. If agree, from DRLM project, we will work on it more focused in standard ReaR thing and not kind of DRLM new boot method.
didacog commented at 2023-02-22 13:20:¶
@didacog do I understand your proposal right that it is basically about to use GRUB2 as "the one and only" common bootloader in all cases? If yes I do very much appreciate it (because as booting noob I only understand GRUB2 a bit but not the other bootloaders).
GRUB2 for OUTPUT=USB is already implemented which was mostly contributed by @DEvil0000 This or that does not yet work perfectly well there but usable basic functionality already works (it worked even for me).
I like to get rid of SYSLINUX/EXTLINUX as USB disk bootloader and use only GRUB2 when GRUB2 works sufficiently well, see #2829 (comment)
In general regarding OUTPUT=USB booting see #2648 and #2666 and #2698
Yes @jsmeix that is the point of my proposal.
DEvil0000 commented at 2023-02-22 15:33:¶
@DEvil0000 can you provide some insights to help with the question of this issue?
I agree from a technical perspective but sadly this does not match
business/customers perspective.
Some recent edge/embedded/special hardware does not support uefi. Since
we need to support hardware for 10 years this requirement will stay in
my case for the next ~4-8 years.
Also rebooting OR changing bios configuration at all is not always a
real option. Some customers do not like "any" changes to a running
system. Customers would possibly even need to re-certificate a system
then which is a no-no.
On virtualized environments we have little to no say in those settings
but we still need to provide such a solution due to requirements. No
matter if a customer or a 3rd party provides the virtualization
platform.
So please do not consider removing it the next years ;)
All virtualisation hosts and all hardware (both enterprise and consumer) sold in the last 10 years support UEFI booting. True is that not everybody uses it, but the tech supports it.
This is not true, some recent edge/embedded/special hardware does not support uefi. Why should it since bios works fine in may be trusted or even certified to do so.
We are working on it anyway, so when we finish our testings and possible implementations, we may send a PR to use a new "multi-platform" boot method using GRUB2 the way we are figuring it out from DRLM project.
Sounds great!
maslo64 commented at 2023-02-23 06:28:¶
Hello @schlomo , all,
just yesterday I performed disaster recovery of SLES on HP Gen 8 servers
with ReaR with OBDR(no UEFI). I never know exactly what kind of HW I'll
get. Some managers(even technical) do love their Gen8/6/5 servers, and
we do love ReaR because we can always restore. My customer has clusters
in 20+ countries ,backed up by ReaR , all booting from BIOS. None of our
VMs using EFI yet, SLES nor Red Hat. I'm only one from team of ~40
people, so there are definitely use cases for ReaR and BIOS here.
guru4712 commented at 2023-02-23 09:05:¶
I definitely agree with DEvil0000 as
stated in
https://github.com/rear/rear/issues/2944#issuecomment-1440265307.
And I would like to recall that there exist issues specifically to EFI
boot still unresolved like
https://github.com/rear/rear/issues/2864#issuecomment-1294511558.
Imho, Fujitsu is not a rare, exotic vendor, so one could exspect REAR to
work on it, too.
jsmeix commented at 2023-02-23 09:17:¶
@maslo64
thank you that you mentioned OBDR in your comment!
We were considering to deprecate OBDR in ReaR 2.7, see
https://github.com/rear/rear/issues/35#issuecomment-909168157
and
https://github.com/rear/rear/issues/2637
because noone of us at ReaR upstream has a tape device
so we can neither properly maintain OBDR code, see
https://github.com/rear/rear/pull/2625#issuecomment-859335712
nor properly help users with OBDR issues, see
https://github.com/rear/rear/issues/1868
But it seems now you @maslo64 implicitly told us
that our old unmaintained OBDR code still "just works"
at least for your particular use case
which is a good example of the case
Why removing unmaintained code where we don't know if it still works?
If it still works - good!
that I listed above in
https://github.com/rear/rear/issues/2944#issuecomment-1439964279
So perhaps the bottom line is:
Keep unmaintained code
unless you know for sure
it can no longer be useful.
DEvil0000 commented at 2023-02-26 00:27:¶
To provide some more HW references:
For reference Supermicro still sells some boards with BIOS only support
- no UEFI. Yes, not many but if you happen to face a machine with one of
those..
PC-Engines boards only support BIOS - without exception I think.
HP only got UEFI working well recently - at some patch stage of G8 if I
remember correctly.
Guess this UEFI struggle is true for most HW manufacturers for
edge/embedded/smaller versions.
schlomo commented at 2023-03-06 12:14:¶
Huge thanks for everybody who added their voice here, it is clear now that BIOS boot will be a ReaR feature for many more years to come.
pcahyna commented at 2023-03-08 16:59:¶
@maslo64
just yesterday I performed disaster recovery of SLES on HP Gen 8 servers with ReaR with OBDR(no UEFI).
that's interesting - did you use OBDR to boot ReaR? Did it work? I am asking because by looking at the code (no OBDR hardware available) I found that the OBDR support is likely broken. #2637 . If so, what ReaR version have you used?
[Export of Github issue for rear/rear.]