#828 Issue closed: Unknown -e flag with genisoimage under Debian

Labels: enhancement, fixed / solved / done

erkannt opened issue at 2016-05-10 08:36:

  • Relax-and-Recover 1.18 / Git
  • Debian GNU/Linux 8.4 (jessie)
  • Dell Poweredge R330

Built and installed deb-package from current master with make deb OFFICIAL=1.18.
Tried running rear -v mkrescue with the following conf:

### write the rescue initramfs to USB and update the USB bootloader
OUTPUT=USB

### create a backup using the internal NETFS method, using 'tar'
BACKUP=NETFS

### write both rescue image and backup to the device labeled REAR-000
BACKUP_URL=usb:///dev/disk/by-label/REAR-000

### From /usr/share/rear/conf/Debian
# Add here the Debian ia64 specials which are not general ia64, e.g.
# agetty vs. getty
REQUIRED_PROGS=(
"${REQUIRED_PROGS[@]}"
getty
)

PROGS=(
"${PROGS[@]}"
)

COPY_AS_IS=( "${COPY_AS_IS[@]}"  )

This fails when creating ISO image.

2016-05-10 10:26:57 Including output/ISO/Linux-i386/81_prepare_multiple_iso.sh
2016-05-10 10:26:57 Including output/ISO/Linux-i386/82_create_iso_image.sh
2016-05-10 10:26:57 Starting '/usr/bin/genisoimage'
2016-05-10 10:26:57 Making ISO image
2016-05-10 10:26:57 Including ISO UEFI boot (as triggered by USING_UEFI_BOOTLOADER=1)
/usr/bin/genisoimage: option '-e' is ambiguous; possibilities: '--eltorito-boot' '--exchange' '--ethershare' '--exclude-list' '--exclude' '--eltorito-catalog' '--eltorito-alt-boot'
Usage: genisoimage [options] -o file directory ...

Use genisoimage -help
to get a list of valid options.

Report problems to debburn-devel@lists.alioth.debian.org.
2016-05-10 10:26:57 ERROR: Could not create ISO image (with /usr/bin/genisoimage)
=== Stack trace ===
Trace 0: /usr/sbin/rear:410 main
Trace 1: /usr/share/rear/lib/mkrescue-workflow.sh:35 WORKFLOW_mkrescue
Trace 2: /usr/share/rear/lib/framework-functions.sh:85 SourceStage
Trace 3: /usr/share/rear/lib/framework-functions.sh:45 Source
Trace 4: /usr/share/rear/output/ISO/Linux-i386/82_create_iso_image.sh:22 source
Trace 5: /usr/share/rear/lib/_input-output-functions.sh:150 StopIfError
Message: Could not create ISO image (with /usr/bin/genisoimage)

This error has come up previously on OpenSUSE #804. Here it was solved by using ebiso. But this is on Debian where genisoimage should work if I understand this post correctly.

gozora commented at 2016-05-10 08:41:

@erkannt what version of genisoimage are you using?
I'm running genisoimage 1.1.11 on my Ubuntu and this one should be fine ...

erkannt commented at 2016-05-10 08:45:

I'm also running genisoimage 1.1.11 (Linux).
The man page and -help both don't mention any -e option.

gozora commented at 2016-05-10 08:49:

that is really strange, because if I run:

# /usr/bin/genisoimage -e
/usr/bin/genisoimage: option requires an argument -- 'e'
Usage: genisoimage [options] -o file directory ...

Use genisoimage -help
to get a list of valid options.

Report problems to debburn-devel@lists.alioth.debian.org.

No ambiguous warning ...

Do you have -efi-boot option available?

erkannt commented at 2016-05-10 08:55:

➜  ~ genisoimage -e
genisoimage: option '-e' is ambiguous; possibilities: '--eltorito-boot' '--exchange' '--ethershare' '--exclude-list' '--exclude' '--eltorito-catalog' '--eltorito-alt-boot'

➜  ~ genisoimage -efi-boot
genisoimage: unrecognized option '-efi-boot'

Very strange indeed.

gozora commented at 2016-05-10 09:03:

All this EFI boot wars drives me nuts, I personally don't see a reason for such big difference despite same version number is used.
I guess Ubuntu guys did little something to make EFI boot work on their version. Unfortunately I don't have currently any Debian distro to check deeper.
Maybe you can try to compile ebiso? (we don't have deb packages yet, as I thought that EFI boot works fine on Debian).

gozora commented at 2016-05-10 09:07:

One more thing I just realized ... You are using OUTPUT=USB ...
Can you just test with OUTPUT=ISO ?

erkannt commented at 2016-05-10 10:12:

OUTPUT=ISO results in the same error.
When trying to determine the reason for the difference between Ubuntu and Debian I found the following workaround. This issue also appeared in Mondo and some stage apperently.

http://trac.mondorescue.org/ticket/782

I manually changed -e to --eltorito-boot in /usr/share/rear/output/ISO/Linux-i386/82_create_iso_image.sh.

Would it be sensible to include such a workaround in the defaul/Debian.conf?

gozora commented at 2016-05-10 10:18:

That is interesting, however I'm not sure that --eltorito-boot does the same thing as --efi-boot...
Did you try to boot from ISO image created using --eltorito-boot option?

gozora commented at 2016-05-10 10:20:

and maybe one more question that I should ask at the very begging. :-)
Are you using EFI boot or Legacy boot on your Dell Poweredge R330?

erkannt commented at 2016-05-10 15:47:

I currently am using EFI boot, but have no qualms is switching to BIOS boot.

I was able to boot from the created ISO when mounting it as a virtual drive via iDRAC.
I was not able to boot from the created USB Drive. It didn't show up as a boot option.

gozora commented at 2016-05-10 20:00:

If you really can switch to legacy boot, my humble advice would be DO SO AND NEVER LOOK BACK ;-), you will save lot of trouble to your self ...
I did a bit of experimenting with ReaR on USB and observed that rear format creates ext/btrs like file system during initialization and as native EFI FS is FAT, I'd say that ReaR does not support EFI boot on USB device.
@jsmeix @gdha @schlomo can you confirm?

jsmeix commented at 2016-05-11 07:44:

I am afraid my knowledge in general about UEFI
is very limited which means in general I cannot
answer questions regarding UEFI - usually it is me
who has questions about UEFI.

From my very limited own experience with UEFI
I do fully agree with @gozora that if one can use
traditional BIOS then use BIOS (and simply relax and wait
until UEFI is generally well supported - except you really like
to deal with various "technically interesting" issues - ideally
when you also can provide GitHub pull requests that fix
issues with UEFI in rear ;-)

@gozora
I have a probably stupid question (which proves
that I really don't know about UEFI):

What exactly do you mean with "ReaR on USB ... rear format ...
ReaR does not support EFI boot on USB device"?

Shouldn't it work generically to let "rear mkrescue" create
a UEFI bootable ISO image (e.g. via "ebiso") and then
burn or dump that onto a CD or DVD or USB stick
to get a UEFI bootable CD or DVD or USB stick?

Isn't it a different way to use "rear format"?

Regarding "rear format":

What I found documented about it:
README.adoc reads (excerpts):

create a bootable USB backup

doc/rear-release-notes.txt reads (excerpts):

External USB booting now uses extlinux instead of syslinux,
and therefore, the USB disk must first be formatted with
an ext2, ext3, ext4 or btrfs based file system

doc/user-guide/04-scenarios.adoc reads (excerpts):

To prepare your USB device for use with Relax-and-Recover, do:
rear format /dev/sdX
This will create a single partition, make it bootable, format it
with ext3, label it REAR-000

It seems nothing is documented about BIOS versus UEFI
regarding "rear format" so that one must inspect
the sources (fortunately rear is fee software so that
one can inspect the sources ;-)

lib/format-workflow.sh reads (excerpts):

# Usage: rear -v format -- -h /dev/
# By default 1 partition will be created with ext3 format and label REAR-000
# With the --efi toggle you get 2 partitions (vfat and ext3) so we are able
# to make this USB UEFI bootable afterwards

It seems with "rear format --efi /dev/sdX"
one should get a UEFI bootable USB device.

But I never tried that myself.

gozora commented at 2016-05-11 08:10:

@jsmeix
To settle things down I'm very far from being UEFI expert and to my top UEFI knowledge belongs being able to use pager when displaying help (it is help -b btw) and changing colors (cls <0-9>) ;-).

From what I've understood UEFI recognizes (by default) only FAT file systems. Means that if you plug in any device that does not contain FAT and trigger map in UEFI shell, you will not able to see its content, hence not able to boot.
So as I firstly triggered rear format and saw the outcome I was quite sure that UEFI will not be able to boot from such formatted USB..

information about rear format --efi is totally new to me, it looks like it could really work due added vfat partition ...
I'll certainly give it a try later today.

Thanks for pointing it out!

jsmeix commented at 2016-05-11 08:36:

I love "git blame" for "assignment of guilt" ;-)

$ git blame usr/share/rear/lib/format-workflow.sh
...
9fa2faaf (Gratien D'haese  2015-06-05 16:43:13 +0200  4) # Usage: rear -v format -- -h /dev/
9fa2faaf (Gratien D'haese  2015-06-05 16:43:13 +0200  5) # By default 1 partition will be created with ext3 format and label REAR-000
9fa2faaf (Gratien D'haese  2015-06-05 16:43:13 +0200  6) # With the --efi toggle you get 2 partitions (vfat and ext3) so we are able
9fa2faaf (Gratien D'haese  2015-06-05 16:43:13 +0200  7) # to make this USB UEFI bootable afterwards
...
9fa2faaf (Gratien D'haese  2015-06-05 16:43:13 +0200 26)             (-e|--efi) EFI=y;;
$ git log | grep -A7 9fa2faaf 
commit 9fa2faaf9d59fec679e68645963365ae41598441
Author: Gratien D'haese 
Date:   Fri Jun 5 16:43:13 2015 +0200
    Added some clarification on how to use the options in the format workflow.
    Added an --efi toggle to create an UEFI bootable disk (partitions only for the moment)
    issue #593

which refers to https://github.com/rear/rear/issues/593
but it seems that issue in not yet the actual issue
where UEFI boot support was added to "rear format".

But the "partitions only for the moment" may indicate that
UEFI boot support is perhaps not yet fully implemented
for "rear format --efi".

It seems it is @gdha who knows the real details here...

gdha commented at 2016-05-11 10:06:

@jsmeix @gozora UEFI USB booting is not supported for the moment - I started with it (the format part only), but stopped as there was no real reason to continue with this as ebiso could do the job for SLES. See also #603.

jsmeix commented at 2016-05-11 12:47:

@gdha
many thanks for your prompt reply.

FYI:
I did not find https://github.com/rear/rear/issues/603 because I have no idea
how I could find related but not implemented GitHub issues
because such issues are not mentioned in the git commit log
or in a source file (as long as nothing is implemented).

carragom commented at 2016-07-29 18:52:

Hey there,

Using Debian 8 and rear-1.17.2. The same issue with option -e is visible. To solve it I installed xorriso and set added ISO_MKISOFS_BIN=/usr/bin/xorrisofs to my /etc/rear/local.conf file. Now the error is gone and the backup works. I still have to test if the image actually boot in UEFI. I'll test it and get back with that info.

In the mean time, maybe the Debian version should depend on xorriso instead of genisoimage and ship ISO_MKISOFS_BIN=/usr/bin/xorrisofs in default.conf?

Cheers.

gdha commented at 2016-08-09 12:20:

@gozora @jsmeix What are your thoughts on above proposal around using xorriso instead of genisoimage when dealing with UEFi on Debian?

gozora commented at 2016-08-09 12:39:

In general that should not do any harm, considering that xorriso really works fine.

jsmeix commented at 2016-08-10 14:35:

I am not a Debian or Ubuntu user but in general
I think using xorriso for now only on Debian or Ubuntu
looks like a good step into the right direction
in particular because at SUSE we also had
an (internal) request to support xorriso in rear.

jsmeix commented at 2016-08-10 14:38:

@carragom
according to your https://github.com/rear/rear/issues/828#issuecomment-236264004
it seems you got it working so that I would like to ask you
to make a GitHub pull request with your changes
so that we have at least a starting point for
some kind of general xorriso support in rear.

Don't be afraid to contribute to Relax-and-Recover
even if your contribution is only a first attempt, cf.
https://github.com/rear/rear/wiki/Coding-Style

jsmeix commented at 2016-08-15 14:54:

With https://github.com/rear/rear/pull/962 merged
I consider this issue as fixed.

Signum commented at 2018-12-16 16:10:

It is not fixed for me unfortunately. I am backing up a Debian 9 system installed in UEFI mode. And I also get:

/usr/bin/genisoimage: option '-e' is ambiguous; possibilities: '--eltorito-boot' '--exchange' '--ethershare' '--exclude-list' '--exclude' '--eltorito-catalog' '--eltorito-alt-boot'

carragom's workaround (https://github.com/rear/rear/issues/828#issuecomment-236264004) works for me. But shouldn't the default be sane even for UEFI?

genisoimage here is

# genisoimage --version
genisoimage 1.1.11 (Linux)

gdha commented at 2018-12-17 07:25:

@Signum why not create a dedicated config file for Debian? Use rear dump to find out which config file would be appropriate for this purpose? You could add ISO_MKISOFS_BIN=/usr/bin/xorrisofs line to the new config file.

jsmeix commented at 2018-12-17 08:37:

Only FYI a general addendum:

In ReaR basically all is bash scripts, in particular config files
are also bash scripts that get sourced (and executed).

Therefore one can do arbitrary bash scripting in config files as needed
to distinguish different cases for example in etc/rear/local.conf things like

if CONDITION_IT_IS_A_DEBIAN_9_SYSTEM ; then
    ISO_MKISOFS_BIN="/usr/bin/xorrisofs"
fi

One must consider that etc/rear/local.conf is also used during "rear recover"
where etc/rear/local.conf is sourced within the rather minimal environment
in the running ReaR recovery system so that things like
CONDITION_IT_IS_A_DEBIAN_9_SYSTEM must be sufficiently fail-safe
that can be also evaluated within the recovery system - regardless that
ISO_MKISOFS_BIN is not needed within the recovery system
but evaluating CONDITION_IT_IS_A_DEBIAN_9_SYSTEM must
not cause a fatal error (it can of course result a non-zero return code).

[Export of Github issue for rear/rear.]