New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rear should automatically use ebiso if UEFI bootloader is found on SLES/OpenSUSE/… #3084
Comments
I asked Ralph from SUSE some weeks ago to contact @jsmeix from SUSE directly. |
@thomas-merz So I can neither comment whether or not it is possible Could you explain your reason why configuring ReaR |
Hello @jsmeix , I just wanted that someone Rear-related from SUSE is aware of this and got no reaction since opening this issue… Regarding your question: We see that Rear is already aware of "this is system has been booted with EFI" and it should know that But why should the user (or admin of many systems) be responsible to tell Rear what it already knows? Please think of your customers that have many systems - some EFI and some not - and need to configure this! So please let sysadmins "relax" by letting Rear do what needs to be done 😃 Maybe @schlomo oder @gdha can explain because I found both very interested in this discussion: https://relax-and-recover.org/rear-user-guide/issues/2015-09-18.657.pr.merged.html |
@thomas-merz It is not that I don't understand why you request All I say here is that currently I cannot implement it
see also my Simply put: Something (hopefully) more constructive: Regarding Do I understand it right that your actual issue is If my assumtion is right, here a general note ReaR config files are read via 'source'.
cf. If you can distinguish your systems that boot with UEFI |
"Challenge accepted" - let's see if I find some time to have a look and try a PR…
We use a config management (sorry, not SUSE Manager, but Puppet) so we just have to set an entry in a YAML file for the hosts with EFI to inform Puppet that this host needs another line in site.conf. That's really not impossible to do. But… I thought that if Rear already knows about EFI it could or it should already use the right tool - automatically.
I understand, but to make it more complicated: Please give me some time to have a look into it and if a PR might be possible to make and if you can adopt/adapt it… |
@thomas-merz Your PR does not need to be some kind of "general solution". The basically only mandatory condition for a PR is Of course I will help you as good as I can. Many thanks in advance for your contribution! |
@thomas-merz Based on my testing of UEFI booting
see default.conf online for ReaR 2.7 at So perhaps 'ebiso' has meanwhile become obsoleted by 'xorrisofs'? @thomas-merz On my SLES15-SP4 system I have the RPM package
|
If SUSE ships xorriso and it works, it would be the best option. Otherwise it possibly could be enough to add ebiso to the line rear/usr/share/rear/conf/default.conf Line 1023 in 7c5c9bc
|
@pcahyna What I found at its upstream location This is my primary problem: But there is the general problem that |
I will test with |
Yesterday and today I tested UEFI booting with OUTPUT=ISO I did not use the ReaR 2.7 release
Yesterday I tested without Secure Boot Today I tested with Secure Boot For Secure Boot I specify in etc/rear/local.conf
cf. My whole etc/rear/local.conf
Excerpts from my today's "rear -D mkbackup":
Excerpts from my today's "rear -D recover":
After reeboot of the recreated system Reeboot of the recreated system works with Secure Boot enabled
is visible for a short time (about one second or so). |
@jsmeix |
@gdha
See also |
@rear/contributors To avoid misunderstandings: |
With I also tested booting the ISO that |
@thomas-merz I will adapt the ReaR upstream documentation soon. |
So shall we close this issue or do you need it as a reminder for updating docu(s)? |
I like to keep it open until I adapted |
Can it be that the "problem" is that SUSE LINUX installs by default So we could solve the problem by adding a dependency on If we don't want to add such a dependency then I'd like us to add auto-detection for In any case, I would expect from ReaR to work well out-of-the-box even for SUSE LINUX and UEFI is the standard boot method for most systems nowadays. |
When xorriso works sufficiently well In contrast ebiso is no such kind of standard software. |
Regarding adding a RPM dependency in Certainly doable but as far as I see at first glance |
@jsmeix the same could be said of any other dependencies in the spec file, but in practice the situation is not that bad, we have had
in the RHEL spec since RHEL 7, so this change would be ok (even preferred) on all RHEL versions since then, also on Fedora. |
Is a hard RPM requirement i.e. I assume Do RHEL and Fedora support RPM Cf. |
I am working on it. Mostly done, actually. Can anyone test the ISO part, please? |
ReaR version ("/usr/sbin/rear -V"): Relax-and-Recover 2.7 / 2022-07-13
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"): SUSE Linux Enterprise Server 15 SP4
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
No site.conf at all.
Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR): VMware
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device): x86
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot): UEFI
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe): local disk(s)
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
ERROR: Could not create ISO image (with /usr/bin/mkisofs)
Workaround, if any:
Setting
ISO_MKISOFS_BIN=/usr/bin/ebiso
insite.conf
via https://www.suse.com/support/kb/doc/?id=000019856Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
rear.log
==> Please let rear automatically use ebiso if UEFI bootloader is found, so that no one has to explicit set it.
The text was updated successfully, but these errors were encountered: