[Mondo-devel] SIGABRT signal received from OS - at 'Loading filelist' - help!

[B. S.]

Hello all. Help please!

I did a really dumb thing and deleted some mysql files I shouldn't have.
Since I run mondoarchive nightly, I'm looking to restore them from the
backup.

Kubuntu 12.04 LTS:

# lsb_release -a
LSB Version:
core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch
Distributor ID: Ubuntu
Description: Ubuntu 12.04.5 LTS
Release: 12.04
Codename: precise

# uname -a
Linux testwmedia 3.13.0-74-generic #118~precise1-Ubuntu SMP Fri Dec 18
10:38:55 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Running mondorescue from the command line, interactive interface, to
restore from iso files elsewhere on the system.

SIGABRT signal received from OS
Abort - probably failed assertion. I'm sleeping for a few seconds so you
can re <rest lost in screen>

- screenshot attached
- mondorestore.log attached


As near as I can figure, at line 216 (SIGABRT), abort happens on:

DBG4: [TH=12565]
../src/mondorestore/mondo-rstr-tools.c->process_filelist_and_biggielist#1130:
grep -E '^/dev/.*' /tmp/mondo.tmp.5ZxNc0/tmp/biggielist.txt >
/tmp/mondo.tmp.5ZxNc0/tmp/filelist.imagedevs
DBG3: [Main]
../src/mondorestore/mondo-rstr-tools.c->process_filelist_and_biggielist
INFO: Loading filelist
SIGABRT signal received from OS
INFO: Abort - probably failed assertion. I'm sleeping for a few seconds
so you can read the message.
DBG1: [Main] ../common/newt-specific.c->fatal_error#304: Fatal error
received - 'MondoRescue is terminating in response to a signal from the OS'

By pressing Ctrl-S at this point I was able to slip over to /tmp and
take a copy of the mondo temporary files (mondo.scratch.*, mondo.tmp.*,
etc.), so I can run the grep and see it results in an empty file.

Any suggestions as to what I'm doing wrong / is wrong with the os / I
can do to better sleuth out the problem?

e.g. I've found in the past that a mistaken command line left a space at
the beginning of a path or archive name will cause similar aborts.
[Short option format vs long.] (And I'm not entirely certain that using
a link dirname doesn't cause difficulty, e.g. ln -s
/mnt/somewhere/quite/long/dirname /mybackupdir) If I can divine such
fiddly bits correctly, mondorescue usually just runs tickety-boo.

Suggestions?

TIA

[Bruno Cornec]

Post by B. S.
I did a really dumb thing and deleted some mysql files I shouldn't
have. Since I run mondoarchive nightly, I'm looking to restore them
from the backup.

If mondorestore doesn't work for you (and I'll have a look at the log to
fix that in a coming version), you can get meanwhile your files directly
from the media. Follow the procedure at
http://trac.mondorescue.org/wiki/Documentation#Manualrestoration

Post by B. S.
e.g. I've found in the past that a mistaken command line left a space
at the beginning of a path or archive name will cause similar aborts.
[Short option format vs long.] (And I'm not entirely certain that
using a link dirname doesn't cause difficulty, e.g. ln -s
/mnt/somewhere/quite/long/dirname /mybackupdir) If I can divine such
fiddly bits correctly, mondorescue usually just runs tickety-boo.

THere is indeed an error with path computation, but that's a minor issue
in your case as your input is taken anyway as it seems.

Bruno.

[B. S.]

Post by Bruno Cornec

Post by B. S.
I did a really dumb thing and deleted some mysql files I shouldn't
have. Since I run mondoarchive nightly, I'm looking to restore them
from the backup.

If mondorestore doesn't work for you (and I'll have a look at the log to
fix that in a coming version), you can get meanwhile your files directly
from the media. Follow the procedure at
http://trac.mondorescue.org/wiki/Documentation#Manualrestoration

.
.
.

Thanks!

Knew there would be a manual method, worst case. Thanks for the link,
saves me mucho time.

I have since been able to recreate an empty mysql file to let me get on
with my day (it was a log table).

However, this 'experience' pointed out, as you noted, that going
forwards I'm not going to be able to restore from my nightly backups
until this parsing problem gets resolved. Which is to say ... thus I'm
keenly interested in addressing the issue going forwards, but there is
no emergency any more.

- I was able to bring up the restore list of another system, and on that
system also fail to bring up the list for this system, so I was able to
verify no program installation issue, and issue only exists with this
system. (i.e. It's particular filelist.)

I was able to run debug 99, and things fall over parsing line 32129 of
filelist.full - on a filename 280 characters long.

DBG6: [Main] libmondo-filelist.c->add_string_at_node#768:
/home/myuserid/.local/share/icc/Backup/Acer Acer P216H (2013-08-26
22-02) {Whitepoint as measured, daylight, testchart file - photo}
3xCurve+MTX Profile Type, HQ Profile Quality, 2.2 Calibration Quality
(ColorHug) - Whitepoint , Mode 08, Curve 2.2, Whitepoint , Mode 08,
Curve 2.2, White-Black level -, Rate 4.0 already in tree
INFO: SIGABRT signal received from OS

I can see other files with braces got parsed correctly, so I don't
expect there is a problem with the brackets. However, since this is deep
within filelist.c, I'm not sure what more I can do to help debug things.
(Can't say as I'm keen on posting internal details to the public internet.)

I assume the SIGABRT is from some buffer overflow / trying to write to
memory not assigned to it, but I'm WAGging here.

I wonder if there isn't value in a mondorestore 'mode' of 'extract file
list to temporary file' - such would not only limit the size of the
logic haystack to be examined here, but generally one would be able to
check out ... is the file I want in this backup? No, try the night
before's, and so on.

------------------------------------------------------------------------------

[B. S.]

.
.
.

Post by B. S.
I assume the SIGABRT is from some buffer overflow / trying to write to
memory not assigned to it, but I'm WAGging here.

One item, in the mean time ...

Once the SIGABRT happens, well, curses has left the screen in its
strange state. No echo, cursor, etc.

Is there a way to return the console to the 'normal' state?

I tried a 'google' of "allintext: curses site:mondorescue.org" with no
joy. Perhaps this would be a useful answer in the FAQ?

------------------------------------------------------------------------------

[Bruno Cornec]

Post by B. S.
Is there a way to return the console to the 'normal' state?

Try typing reset
If you don't see anything try typing: echo ^V^O (CTRL-V and CTRL-O) and
then reset

Bruno.

[B. S.]

FWIW, same SIGABRT when using the testing version, mondoarchive
v3.2.220151218023212-r3492.

Post by B. S.

Post by Bruno Cornec

Post by B. S.
I did a really dumb thing and deleted some mysql files I shouldn't
have. Since I run mondoarchive nightly, I'm looking to restore them
from the backup.

If mondorestore doesn't work for you (and I'll have a look at the log to
fix that in a coming version), you can get meanwhile your files directly
from the media. Follow the procedure at
http://trac.mondorescue.org/wiki/Documentation#Manualrestoration

.
.
.
Thanks!
Knew there would be a manual method, worst case. Thanks for the link,
saves me mucho time.
I have since been able to recreate an empty mysql file to let me get on
with my day (it was a log table).
However, this 'experience' pointed out, as you noted, that going
forwards I'm not going to be able to restore from my nightly backups
until this parsing problem gets resolved. Which is to say ... thus I'm
keenly interested in addressing the issue going forwards, but there is
no emergency any more.
- I was able to bring up the restore list of another system, and on that
system also fail to bring up the list for this system, so I was able to
verify no program installation issue, and issue only exists with this
system. (i.e. It's particular filelist.)
I was able to run debug 99, and things fall over parsing line 32129 of
filelist.full - on a filename 280 characters long.
/home/myuserid/.local/share/icc/Backup/Acer Acer P216H (2013-08-26
22-02) {Whitepoint as measured, daylight, testchart file - photo}
3xCurve+MTX Profile Type, HQ Profile Quality, 2.2 Calibration Quality
(ColorHug) - Whitepoint , Mode 08, Curve 2.2, Whitepoint , Mode 08,
Curve 2.2, White-Black level -, Rate 4.0 already in tree
INFO: SIGABRT signal received from OS
I can see other files with braces got parsed correctly, so I don't
expect there is a problem with the brackets. However, since this is deep
within filelist.c, I'm not sure what more I can do to help debug things.
(Can't say as I'm keen on posting internal details to the public internet.)
I assume the SIGABRT is from some buffer overflow / trying to write to
memory not assigned to it, but I'm WAGging here.
I wonder if there isn't value in a mondorestore 'mode' of 'extract file
list to temporary file' - such would not only limit the size of the
logic haystack to be examined here, but generally one would be able to
check out ... is the file I want in this backup? No, try the night
before's, and so on.

------------------------------------------------------------------------------

[B. S.]

Looks like something got overlooked, version wise, somewhere.

I see at ftp://ftp.mondorescue.org/test/ubuntu/12.04/
libmondorescue-perl_3.2.220160324203526-0_all.deb

Yet my system reports:

Get: 1 ftp://ftp.mondorescue.org/test/ubuntu/ 12.04/contrib
libmondorescue-perl all 3.2.220160324014634-0 [61.6 kB]
Err ftp://ftp.mondorescue.org/test/ubuntu/ 12.04/contrib
libmondorescue-perl all 3.2.220160324014634-0
Unable to fetch file, server said 'Failed to open file. '
0% [Working]E: Failed to fetch
ftp://ftp.mondorescue.org/test/ubuntu/12.04/libmondorescue-perl_3.2.220160324014634-0_all.deb:
Unable to fetch file, server said 'Failed to open file. '

...14634 above vs. ...03526 at ftp:

Something get missed in some file somewhere?

[B. S.]

Something's amiss somewhere - "Unable to fetch file, server said 'Failed
to open file. '".

Getting:

Kubuntu 12.04 -

The following packages will be upgraded:
libmondorescue-perl mindi mondo
3 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 1,120 kB of archives. After unpacking 34.8 kB will be used.
Do you want to continue? [Y/n/?] y
WARNING: untrusted versions of the following packages will be installed!

Untrusted packages could compromise your system's security.
You should only proceed with the installation if you are certain that
this is what you want to do.

mindi libmondorescue-perl mondo

Do you want to ignore this warning and proceed anyway?
To continue, enter "Yes"; to abort, enter "No": Yes
Get: 1 ftp://ftp.mondorescue.org/ubuntu/ 12.04/contrib
libmondorescue-perl all 3.2.3-1 [68.2 kB]
Err ftp://ftp.mondorescue.org/ubuntu/ 12.04/contrib libmondorescue-perl
all 3.2.3-1
Unable to fetch file, server said 'Failed to open file. '
Get: 2 ftp://ftp.mondorescue.org/ubuntu/ 12.04/contrib mindi amd64
3.0.3-1 [213 kB]
Err ftp://ftp.mondorescue.org/ubuntu/ 12.04/contrib mindi amd64 3.0.3-1
Unable to fetch file, server said 'Failed to open file. '
Get: 3 ftp://ftp.mondorescue.org/ubuntu/ 12.04/contrib mondo amd64
3.2.3-1 [839 kB]
Err ftp://ftp.mondorescue.org/ubuntu/ 12.04/contrib mondo amd64 3.2.3-1
Unable to fetch file, server said 'Failed to open file. '
0% [Working]E: Failed to fetch
ftp://ftp.mondorescue.org/ubuntu/12.04/libmondorescue-perl_3.2.3-1_all.deb:
Unable to fetch file, server said 'Failed to open file. '

E: Failed to fetch
ftp://ftp.mondorescue.org/ubuntu/12.04/libmondorescue-perl_3.2.3-1_all.deb:
Unable to fetch file, server said 'Failed to open file. '


Kubuntu 14.04:

# aptitude upgrade
The following packages will be upgraded:
libmondorescue-perl mindi mondo
3 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 669 kB of archives. After unpacking 0 B will be used.
Do you want to continue? [Y/n/?] y
WARNING: untrusted versions of the following packages will be installed!

Untrusted packages could compromise your system's security.
You should only proceed with the installation if you are certain that
this is what you want to do.

libmondorescue-perl mindi mondo

Do you want to ignore this warning and proceed anyway?
To continue, enter "Yes"; to abort, enter "No": Yes
Get: 1 ftp://ftp.mondorescue.org//ubuntu/ 14.04/contrib
libmondorescue-perl all 3.2.3-1 [66.8 kB]
Err ftp://ftp.mondorescue.org//ubuntu/ 14.04/contrib libmondorescue-perl
all 3.2.3-1
Unable to fetch file, server said 'Failed to open file. '
Get: 2 ftp://ftp.mondorescue.org//ubuntu/ 14.04/contrib mindi i386
3.0.3-1 [188 kB]
Err ftp://ftp.mondorescue.org//ubuntu/ 14.04/contrib mindi i386 3.0.3-1
Unable to fetch file, server said 'Failed to open file. '
Get: 3 ftp://ftp.mondorescue.org//ubuntu/ 14.04/contrib mondo i386
3.2.3-1 [414 kB]
Err ftp://ftp.mondorescue.org//ubuntu/ 14.04/contrib mondo i386 3.2.3-1
Unable to fetch file, server said 'Failed to open file. '
0% [Working]E: Failed to fetch
ftp://ftp.mondorescue.org//ubuntu/14.04/libmondorescue-perl_3.2.3-1_all.deb:
Unable to fetch file, server said 'Failed to open file. '

[Bruno Cornec]

Hello,

Official version is still being generated. Please wait for the announcement before upgrading.

Best regards,
Bruno.

Post by B. S.
Something's amiss somewhere - "Unable to fetch file, server said 'Failed
to open file. '".
Kubuntu 12.04 -
libmondorescue-perl mindi mondo
3 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 1,120 kB of archives. After unpacking 34.8 kB will be used.
Do you want to continue? [Y/n/?] y
WARNING: untrusted versions of the following packages will be installed!
Untrusted packages could compromise your system's security.
You should only proceed with the installation if you are certain that
this is what you want to do.
mindi libmondorescue-perl mondo
Do you want to ignore this warning and proceed anyway?
To continue, enter "Yes"; to abort, enter "No": Yes
Get: 1 ftp://ftp.mondorescue.org/ubuntu/ 12.04/contrib
libmondorescue-perl all 3.2.3-1 [68.2 kB]
Err ftp://ftp.mondorescue.org/ubuntu/ 12.04/contrib libmondorescue-perl
all 3.2.3-1
Unable to fetch file, server said 'Failed to open file. '
Get: 2 ftp://ftp.mondorescue.org/ubuntu/ 12.04/contrib mindi amd64
3.0.3-1 [213 kB]
Err ftp://ftp.mondorescue.org/ubuntu/ 12.04/contrib mindi amd64 3.0.3-1
Unable to fetch file, server said 'Failed to open file. '
Get: 3 ftp://ftp.mondorescue.org/ubuntu/ 12.04/contrib mondo amd64
3.2.3-1 [839 kB]
Err ftp://ftp.mondorescue.org/ubuntu/ 12.04/contrib mondo amd64 3.2.3-1
Unable to fetch file, server said 'Failed to open file. '
0% [Working]E: Failed to fetch
Unable to fetch file, server said 'Failed to open file. '
E: Failed to fetch
Unable to fetch file, server said 'Failed to open file. '
# aptitude upgrade
libmondorescue-perl mindi mondo
3 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 669 kB of archives. After unpacking 0 B will be used.
Do you want to continue? [Y/n/?] y
WARNING: untrusted versions of the following packages will be installed!
Untrusted packages could compromise your system's security.
You should only proceed with the installation if you are certain that
this is what you want to do.
libmondorescue-perl mindi mondo
Do you want to ignore this warning and proceed anyway?
To continue, enter "Yes"; to abort, enter "No": Yes
Get: 1 ftp://ftp.mondorescue.org//ubuntu/ 14.04/contrib
libmondorescue-perl all 3.2.3-1 [66.8 kB]
Err ftp://ftp.mondorescue.org//ubuntu/ 14.04/contrib libmondorescue-perl
all 3.2.3-1
Unable to fetch file, server said 'Failed to open file. '
Get: 2 ftp://ftp.mondorescue.org//ubuntu/ 14.04/contrib mindi i386
3.0.3-1 [188 kB]
Err ftp://ftp.mondorescue.org//ubuntu/ 14.04/contrib mindi i386 3.0.3-1
Unable to fetch file, server said 'Failed to open file. '
Get: 3 ftp://ftp.mondorescue.org//ubuntu/ 14.04/contrib mondo i386
3.2.3-1 [414 kB]
Err ftp://ftp.mondorescue.org//ubuntu/ 14.04/contrib mondo i386 3.2.3-1
Unable to fetch file, server said 'Failed to open file. '
0% [Working]E: Failed to fetch
Unable to fetch file, server said 'Failed to open file. '
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mondo-devel mailing list
https://lists.sourceforge.net/lists/listinfo/mondo-devel

[B. S.]

I'm misunderstanding something then.

I receive notifications that updates are available. I aptitude update,
aptitude upgrade, and the messages noted happen.

I'm not seeking the updates, let alone pre-announcement, they seem to be
seeking me.

Perhaps a version update in whatever aptitude looks at to determine
whether a new version is present or not, was prematurely upgraded?

Post by Bruno Cornec
Hello,
Official version is still being generated. Please wait for the
announcement before upgrading.
Best regards, Bruno.

Post by B. S.
Something's amiss somewhere - "Unable to fetch file, server said
'Failed to open file. '".
Kubuntu 12.04 -
The following packages will be upgraded: libmondorescue-perl mindi
mondo 3 packages upgraded, 0 newly installed, 0 to remove and 1 not
upgraded. Need to get 1,120 kB of archives. After unpacking 34.8 kB
will be used. Do you want to continue? [Y/n/?] y WARNING: untrusted
versions of the following packages will be installed!
Untrusted packages could compromise your system's security. You
should only proceed with the installation if you are certain that
this is what you want to do.
mindi libmondorescue-perl mondo
Do you want to ignore this warning and proceed anyway? To continue,
enter "Yes"; to abort, enter "No": Yes Get: 1
ftp://ftp.mondorescue.org/ubuntu/ 12.04/contrib libmondorescue-perl
all 3.2.3-1 [68.2 kB] Err ftp://ftp.mondorescue.org/ubuntu/
12.04/contrib libmondorescue-perl all 3.2.3-1 Unable to fetch file,
server said 'Failed to open file. ' Get: 2
ftp://ftp.mondorescue.org/ubuntu/ 12.04/contrib mindi amd64 3.0.3-1
[213 kB] Err ftp://ftp.mondorescue.org/ubuntu/ 12.04/contrib mindi
amd64 3.0.3-1 Unable to fetch file, server said 'Failed to open
file. ' Get: 3 ftp://ftp.mondorescue.org/ubuntu/ 12.04/contrib
mondo amd64 3.2.3-1 [839 kB] Err ftp://ftp.mondorescue.org/ubuntu/
12.04/contrib mondo amd64 3.2.3-1 Unable to fetch file, server said
'Failed to open file. ' 0% [Working]E: Failed to fetch

Unable to fetch file, server said 'Failed to open file. '

Post by Bruno Cornec

Post by B. S.
E: Failed to fetch

Unable to fetch file, server said 'Failed to open file. '

Post by Bruno Cornec

Post by B. S.
libmondorescue-perl mindi mondo 3 packages upgraded, 0 newly
installed, 0 to remove and 0 not upgraded. Need to get 669 kB of
archives. After unpacking 0 B will be used. Do you want to
continue? [Y/n/?] y WARNING: untrusted versions of the following
packages will be installed!
Untrusted packages could compromise your system's security. You
should only proceed with the installation if you are certain that
this is what you want to do.
libmondorescue-perl mindi mondo
Do you want to ignore this warning and proceed anyway? To continue,
enter "Yes"; to abort, enter "No": Yes Get: 1
ftp://ftp.mondorescue.org//ubuntu/ 14.04/contrib
libmondorescue-perl all 3.2.3-1 [66.8 kB] Err
ftp://ftp.mondorescue.org//ubuntu/ 14.04/contrib
libmondorescue-perl all 3.2.3-1 Unable to fetch file, server said
'Failed to open file. ' Get: 2 ftp://ftp.mondorescue.org//ubuntu/
14.04/contrib mindi i386 3.0.3-1 [188 kB] Err
ftp://ftp.mondorescue.org//ubuntu/ 14.04/contrib mindi i386
3.0.3-1 Unable to fetch file, server said 'Failed to open file. '
Get: 3 ftp://ftp.mondorescue.org//ubuntu/ 14.04/contrib mondo i386
3.2.3-1 [414 kB] Err ftp://ftp.mondorescue.org//ubuntu/
14.04/contrib mondo i386 3.2.3-1 Unable to fetch file, server said
'Failed to open file. ' 0% [Working]E: Failed to fetch

Unable to fetch file, server said 'Failed to open file. '

Post by Bruno Cornec

Post by B. S.
------------------------------------------------------------------------------

Find and fix application performance issues faster with Applications Manager

Post by Bruno Cornec

Post by B. S.
Applications Manager provides deep performance insights into
multiple tiers of your business applications. It resolves
application problems quickly and reduces your MTTR. Get your free
trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________ Mondo-devel mailing
https://lists.sourceforge.net/lists/listinfo/mondo-devel

[B. S.]

Echoing a report from 2016-10-15 21:57:10,
https://sourceforge.net/p/mondo/mailman/message/35430469/ ...

<<<<<
Trying to back up my UEFI-based Fedora 24 system. First, there was a
whine about syslinux.efi missing. I dug up that from the syslinux folks
and installed it, not I'm getting an issue regarding copying stuff to
the temp directory...specifically "cp: cannot stat
'/usr/share/syslinux/efi64/ldlinux.e64/../libutil.c32': Not a directory".

Near as I can tell ldlinux.e64 is a file, not a directory.


I'm including the mindi.log from this. Perhaps you can have a look.


Rick Stevens, Systems Engineer
AllDigital, Inc.
Same thing happening here on a new Debian Stretch system.

What goofy strange thing has Linux done now?

$ ls -l /usr/lib/syslinux/modules/efi64/ldlinux.e64/../libutil.c32
ls: cannot access
'/usr/lib/syslinux/modules/efi64/ldlinux.e64/../libutil.c32': Not a
directory

Which triggers at the end of the (failing) mindi log:

-----------------------------------
INFO: Found ldlinux.c32 at /usr/lib/syslinux/modules/bios/ldlinux.c32
INFO: Found syslinux.efi at /usr/lib/SYSLINUX.EFI/efi64/syslinux.efi
INFO: Found syslinux boot type
INFO: Found ldlinux.e64 at /usr/lib/syslinux/modules/efi64/ldlinux.e64
INFO: Copying /usr/lib/syslinux/modules/efi64/ldlinux.e64 to
/tmp/mindi.qAJsbZsfqX/bigdir/EFI/BOOT
cp: cannot stat
'/usr/lib/syslinux/modules/efi64/ldlinux.e64/../libutil.c32': Not a
directory
FATAL ERROR. Cannot copy /usr/lib/syslinux/modules/efi64/ldlinux.e64 to
/tmp/mindi.qAJsbZsfqX/bigdir/EFI/BOOT). Did you run out of disk space?


-----

$ ls -l /usr/lib/syslinux/modules/efi64/ldlinux.e64
-rw-r--r-- 1 root root 132K Jan 28 13:39
/usr/lib/syslinux/modules/efi64/ldlinux.e64

$ ls -l /usr/lib/syslinux/modules/efi64/libutil.c32
-rw-r--r-- 1 root root 24K Jan 28 13:39
/usr/lib/syslinux/modules/efi64/libutil.c32

$ ls -l /usr/lib/syslinux/modules/efi64/ldlinux.e64/../libutil.c32
ls: cannot access
'/usr/lib/syslinux/modules/efi64/ldlinux.e64/../libutil.c32': Not a
directory

-----

Since when has '../file' constructs stopped working as they always have?


$ ls -l /usr/lib/syslinux/modules/efi64/ldlinux.e64/..
ls: cannot access '/usr/lib/syslinux/modules/efi64/ldlinux.e64/..': Not
a directory

$ ls -l /usr/lib/syslinux/modules/efi64/ldlinux.e64
-rw-r--r-- 1 root root 132K Jan 28 13:39
/usr/lib/syslinux/modules/efi64/ldlinux.e64

$ ls -l /usr/lib/syslinux/modules/efi64
... lots of files.

$ ls -l /usr/lib/syslinux/modules/efi64/libutil.c32
-rw-r--r-- 1 root root 24K Jan 28 13:39
/usr/lib/syslinux/modules/efi64/libutil.c32

-----

$ ls /etc/apt/apt.conf.d/70debconf
/etc/apt/apt.conf.d/70debconf
$ ls /etc/apt/apt.conf.d/../sources.list
/etc/apt/apt.conf.d/../sources.list

-----

Something special about some things?

[B. S.]

Eventually ... remembering these are 'just' scripts ...

Changing:

cp $LDLINUXE64/../libutil.c32 $efidir 2>> $LOGFILE || Die "Cannot copy
$LDLINUXE64 to $efidir). Did you run out of disk space

To:

# cp $LDLINUXE64/../libutil.c32 $efidir 2>> $LOGFILE || Die "Cannot copy
$LDLINUXE64 to $efidir). Did you run out of disk space

cp /usr/lib/syslinux/modules/efi64/libutil.c32 $efidir 2>> $LOGFILE ||
Die "Cannot copy $LDLINUXE64 to $efidir). Did you run

Let's me get through that and on to the next issue.

Granted, it's not a good / robust change, but it's not like this
system's going to change its lib paths.

Post by B. S.
Echoing a report from 2016-10-15 21:57:10,
https://sourceforge.net/p/mondo/mailman/message/35430469/ ...
<<<<<
Trying to back up my UEFI-based Fedora 24 system. First, there was a
whine about syslinux.efi missing. I dug up that from the syslinux folks
and installed it, not I'm getting an issue regarding copying stuff to
the temp directory...specifically "cp: cannot stat
'/usr/share/syslinux/efi64/ldlinux.e64/../libutil.c32': Not a directory".
Near as I can tell ldlinux.e64 is a file, not a directory.
I'm including the mindi.log from this. Perhaps you can have a look.
Rick Stevens, Systems Engineer
AllDigital, Inc.
Same thing happening here on a new Debian Stretch system.
What goofy strange thing has Linux done now?
$ ls -l /usr/lib/syslinux/modules/efi64/ldlinux.e64/../libutil.c32
ls: cannot access
'/usr/lib/syslinux/modules/efi64/ldlinux.e64/../libutil.c32': Not a
directory
-----------------------------------
INFO: Found ldlinux.c32 at /usr/lib/syslinux/modules/bios/ldlinux.c32
INFO: Found syslinux.efi at /usr/lib/SYSLINUX.EFI/efi64/syslinux.efi
INFO: Found syslinux boot type
INFO: Found ldlinux.e64 at /usr/lib/syslinux/modules/efi64/ldlinux.e64
INFO: Copying /usr/lib/syslinux/modules/efi64/ldlinux.e64 to
/tmp/mindi.qAJsbZsfqX/bigdir/EFI/BOOT
cp: cannot stat
'/usr/lib/syslinux/modules/efi64/ldlinux.e64/../libutil.c32': Not a
directory
FATAL ERROR. Cannot copy /usr/lib/syslinux/modules/efi64/ldlinux.e64 to
/tmp/mindi.qAJsbZsfqX/bigdir/EFI/BOOT). Did you run out of disk space?
-----
$ ls -l /usr/lib/syslinux/modules/efi64/ldlinux.e64
-rw-r--r-- 1 root root 132K Jan 28 13:39
/usr/lib/syslinux/modules/efi64/ldlinux.e64
$ ls -l /usr/lib/syslinux/modules/efi64/libutil.c32
-rw-r--r-- 1 root root 24K Jan 28 13:39
/usr/lib/syslinux/modules/efi64/libutil.c32
$ ls -l /usr/lib/syslinux/modules/efi64/ldlinux.e64/../libutil.c32
ls: cannot access
'/usr/lib/syslinux/modules/efi64/ldlinux.e64/../libutil.c32': Not a
directory
-----
Since when has '../file' constructs stopped working as they always have?
$ ls -l /usr/lib/syslinux/modules/efi64/ldlinux.e64/..
ls: cannot access '/usr/lib/syslinux/modules/efi64/ldlinux.e64/..': Not
a directory
$ ls -l /usr/lib/syslinux/modules/efi64/ldlinux.e64
-rw-r--r-- 1 root root 132K Jan 28 13:39
/usr/lib/syslinux/modules/efi64/ldlinux.e64
$ ls -l /usr/lib/syslinux/modules/efi64
... lots of files.
$ ls -l /usr/lib/syslinux/modules/efi64/libutil.c32
-rw-r--r-- 1 root root 24K Jan 28 13:39
/usr/lib/syslinux/modules/efi64/libutil.c32
-----
$ ls /etc/apt/apt.conf.d/70debconf
/etc/apt/apt.conf.d/70debconf
$ ls /etc/apt/apt.conf.d/../sources.list
/etc/apt/apt.conf.d/../sources.list
-----
Something special about some things?

[B. S.]

Looks like xorriso has lost various eltorito options, preventing iso
generation.

$ uname -a
Linux teststop 4.9.0-3-amd64 #1 SMP Debian 4.9.25-1 (2017-05-02) x86_64
GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.0 (stretch)
Release: 9.0
Codename: stretch

Shall I make a bootable CD image? (y/[n]) y
INFO: Copying /var/cache/mindi/*.gz to /tmp/mindi.gs2czEkgZl/target/images
INFO: Copying /boot/vmlinuz-4.9.0-3-amd64 to
/tmp/mindi.gs2czEkgZl/target/vmlinuz
INFO: Copying /tmp/mindi.gs2czEkgZl/initrd.img to
/tmp/mindi.gs2czEkgZl/target/initrd.img
INFO: Creating a 58972 KB empty file for boot device of the ISO image
INFO: Creating a vfat filesystem on /tmp/mindi.gs2czEkgZl/mindi-bootroot.img
INFO: Mounting /tmp/mindi.gs2czEkgZl/mindi-bootroot.img on
/tmp/mindi.gs2czEkgZl/mpt
INFO: Moving boot info on /tmp/mindi.gs2czEkgZl/mpt
INFO: Invoking /usr/bin/xorriso -as mkisofs -J -r -v -p Mindi -publisher
http://www.mondorescue.org -A Mindi -V Mindi_Image -o
/var/cache/mindi/mindi.iso -b EFI/isolinux.bin -c EFI/boot.cat
-no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot
-efi-boot images/mindi-bootroot.img -no-emul-boot .
INFO: Invoking instead /usr/bin/xorriso -as mkisofs -J -r -v -p Mindi
-publisher http://www.mondorescue.org -A Mindi -V Mindi_Image -o
/var/cache/mindi/mindi.iso -b EFI/isolinux.bin -c EFI/boot.cat
-no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot
-eltorito-platform 0xEF -eltorito-boot images/mindi-bootroot.img
-no-emul-boot
/usr/bin/xorriso -as mkisofs returned the following errors:
xorriso 1.4.6 : RockRidge filesystem manipulator, libburnia project.

Drive current: -outdev 'stdio:/var/cache/mindi/mindi.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 99.3g free
xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules
xorriso : FAILURE : -as mkisofs: Unrecognized option '-eltorito-platform'
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
ERROR: Failed to create ISO image.


Uninstalling xorriso and rerunning produces:

Shall I make a bootable CD image? (y/[n]) y
INFO: Copying /var/cache/mindi/*.gz to /tmp/mindi.GbuYVBQjCx/target/images
INFO: Copying /boot/vmlinuz-4.9.0-3-amd64 to
/tmp/mindi.GbuYVBQjCx/target/vmlinuz
INFO: Copying /tmp/mindi.GbuYVBQjCx/initrd.img to
/tmp/mindi.GbuYVBQjCx/target/initrd.img
INFO: Creating a 58972 KB empty file for boot device of the ISO image
INFO: Creating a vfat filesystem on /tmp/mindi.GbuYVBQjCx/mindi-bootroot.img
INFO: Mounting /tmp/mindi.GbuYVBQjCx/mindi-bootroot.img on
/tmp/mindi.GbuYVBQjCx/mpt
INFO: Moving boot info on /tmp/mindi.GbuYVBQjCx/mpt
INFO: Invoking /usr/bin/genisoimage -J -r -v -p Mindi -publisher
http://www.mondorescue.org -A Mindi -V Mindi_Image -o
/var/cache/mindi/mindi.iso -b EFI/isolinux.bin -c EFI/boot.cat
-no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot
-efi-boot images/mindi-bootroot.img -no-emul-boot .
INFO: Invoking instead /usr/bin/genisoimage -J -r -v -p Mindi -publisher
http://www.mondorescue.org -A Mindi -V Mindi_Image -o
/var/cache/mindi/mindi.iso -b EFI/isolinux.bin -c EFI/boot.cat
-no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot
-eltorito-platform 0xEF -eltorito-boot images/mindi-bootroot.img
-no-emul-boot
/usr/bin/genisoimage returned the following errors:
/usr/bin/genisoimage: unrecognized option '-eltorito-platform'
Usage: genisoimage [options] -o file directory ...

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

Report problems to debburn-***@lists.alioth.debian.org.
ERROR: Failed to create ISO image.


$ aptitude show genisoimage
Package: genisoimage
Version: 9:1.1.11-3+b2
State: installed
Automatically installed: no
Priority: optional
Section: otherosfs
Maintainer: Joerg Jaspert <***@debian.org>
Architecture: amd64
Uncompressed Size: 1,655 k
Depends: libbz2-1.0, libc6 (>= 2.14), libmagic1 (>= 5.12), zlib1g (>=
1:1.1.4)
Suggests: wodim, cdrkit-doc
Conflicts: mkhybrid, mkisofs (< 9:1.0), genisoimage:i386, mkisofs:i386
(< 9:1.0)
Replaces: mkisofs (< 9:1.0), mkisofs:i386 (< 9:1.0)
Description: Creates ISO-9660 CD-ROM filesystem images
genisoimage is a pre-mastering program for creating ISO-9660 CD-ROM
filesystem images, which can then be written to CD or DVD media using
the wodim program.
genisoimage includes support for making bootable "El Torito" CDs, as
well as CDs with support for the Macintosh HFS filesystem.

The package also includes extra tools useful for working with ISO images:
* mkzftree - create ISO-9660 image with compressed contents
* dirsplit - easily separate large directory contents into disks of
predefined size
* geteltorito - extract an El Torito boot image from a CD image

Please install cdrkit-doc if you want most of the documentation and
README files.
Tags: hardware::storage, hardware::storage:cd, hardware::storage:dvd,
interface::commandline, role::program, scope::utility, use::storing,
works-with-format::iso9660, works-with::archive


Reinstalling xorriso ...

$ xorriso -version
xorriso 1.4.6 : RockRidge filesystem manipulator, libburnia project.

xorriso 1.4.6
ISO 9660 Rock Ridge filesystem manipulator and CD/DVD/BD burn program
Copyright (C) 2016, Thomas Schmitt <***@gmx.net>, libburnia project.
xorriso version : 1.4.6
Version timestamp : 2016.09.16.133001
Build timestamp : -none-given-
libisofs in use : 1.4.6 (min. 1.4.6)
libjte in use : 1.0.0 (min. 1.0.0)
libburn in use : 1.4.6 (min. 1.4.6)
libburn OS adapter: internal GNU/Linux SG_IO adapter sg-linux
libisoburn in use : 1.4.6 (min. 1.4.6)
Provided under GNU GPL version 3 or later, due to libreadline license.
There is NO WARRANTY, to the extent permitted by law.


$ aptitude show xorriso
Package: xorriso
Version: 1.4.6-1+b1
State: installed
Automatically installed: no
Priority: optional
Section: otherosfs
Maintainer: Debian Libburnia packagers
<pkg-libburnia-***@lists.alioth.debian.org>
Architecture: amd64
Uncompressed Size: 328 k
Depends: libburn4 (>= 1.4.6), libc6 (>= 2.3.4), libisoburn1 (=
1.4.6-1+b1), libisofs6 (>= 1.4.6), libjte1, libreadline7 (>= 6.0),
zlib1g (>= 1:1.1.4)
Suggests: jigit, cdck
Conflicts: xorriso:i386
Description: command line ISO-9660 and Rock Ridge manipulation tool
xorriso is a command line and dialog application, which creates, loads,
manipulates, and writes ISO-9660 file system images with Rock Ridge
extensions.

It maps file objects from POSIX compliant file systems into Rock Ridge
enhanced ISO-9660 file systems and features session-wise manipulation of
such file
systems. It can load the management information of existing ISO images
and write the resulting session to optical medium or as file system objects.

Supported optical media types:
* CD-R, CD-RW
* DVD-R, DVD-R DL, DVD-RW, DVD+R, DVD+R DL, DVD+RW, DVD-RAM
* BD-R, BD-RE

Some interesting features:
* Emulation of the mkisofs and cdrecord programs.
* Data backup and restore capabilities - compression, ACLs, and filters.
* Isohybrid MBR with partition offset - features booting ISOLINUX from
USB sticks, or from other devices that appear to PC-BIOS as hard disks.
The images
carry a conventional partition table for a USB stick; the first
partition reports the size of the ISO image, but starts at a non-zero
address. It is
nevertheless still mountable.
* Jigdo Template Export - jigdo representation of the resulting
ISO-9660 image, generated on the fly.

Test suite:
xorriso source code comes with a release engineering test-suite called
`releng', which aims to cover most of the functionality of the xorriso
and the underlying libraries of libburn, libisofs, and libisoburn.
Homepage: http://libburnia-project.org
Tags: implemented-in::c, role::program, suite::gnu,
works-with-format::iso9660


All presumably coming as a result of (in mindi):

MakeISO() {

LogAll "INFO: Invoking $CMD ."
(cd "$MINDI_TMP/mpt" ; $CMD .) > /dev/null 2> $MINDI_TMP/mkisofs.log
if [ $? -ne 0 ] ; then
if [ "$BOOT_TYPE" = "UEFI" ]; then
CMD=`echo $CMD | perl -p -e 's|--efi-boot
|-eltorito-platform 0xEF -eltorito-boot |; s|-efi-boot
|-eltorito-platform 0xEF -eltorito-boot |;'`
LogAll "INFO: Invoking instead $CMD"
(cd "$MINDI_TMP/mpt" ; $CMD .) > /dev/null 2>
$MINDI_TMP/mkisofs.log
if [ $? -eq 0 ] ; then
LogAll "INFO: Created bootable ISO image at
$MINDI_CACHE/mindi.iso"
else
MakeISOErrors
fi
else
MakeISOErrors
fi
else
LogAll "INFO: Created bootable ISO image at $MINDI_CACHE/mindi.iso"
fi
rm -f $MINDI_TMP/mkisofs.log
}


$ mindi -v
Mindi v3.0.2-r3578


Any suggestions for getting through the iso generation phase, in the
mean time?

[Thomas Schmitt]

Hi,

i am the developer of xorriso and apologize for not having a message id
to refer to by this reply.

Post by B. S.
Looks like xorriso has lost various eltorito options, preventing iso
generation.
...
xorriso : FAILURE : -as mkisofs: Unrecognized option '-eltorito-platform'

This option is relatively young in mkisofs. It was introduced after the
fork of genisoimage and after xorriso got defined its set of mkisofs
emulation options.

genisoimage from upstream cdrkit does not support EFI booting at all.
But Fedora's enhanced genisoimage got option -e for EFI boot images.
xorriso -as mkisofs supports -e too.

So for xorriso and Fedora's genisoimage one would replace the mkisofs
gesture

-eltorito-platform 0xEF -eltorito-boot images/mindi-bootroot.img
-no-emul-boot

by

-e images/mindi-bootroot.img -no-emul-boot


Have a nice day :)

Thomas

[B. S.]

Hi Thomas, thank you very much for your message.

Hopefully it will help Bruno, et al, going forwards.

In the mean time, being on Debian myself, probably not?

Post by Thomas Schmitt
Hi,
i am the developer of xorriso and apologize for not having a message id
to refer to by this reply.

Post by B. S.
Looks like xorriso has lost various eltorito options, preventing iso
generation.
...
xorriso : FAILURE : -as mkisofs: Unrecognized option '-eltorito-platform'

This option is relatively young in mkisofs. It was introduced after the
fork of genisoimage and after xorriso got defined its set of mkisofs
emulation options.
genisoimage from upstream cdrkit does not support EFI booting at all.
But Fedora's enhanced genisoimage got option -e for EFI boot images.
xorriso -as mkisofs supports -e too.
So for xorriso and Fedora's genisoimage one would replace the mkisofs
gesture
-eltorito-platform 0xEF -eltorito-boot images/mindi-bootroot.img
-no-emul-boot
by
-e images/mindi-bootroot.img -no-emul-boot

[Thomas Schmitt]

Hi,

Post by B. S.
In the mean time, being on Debian myself, probably not?

You could volunteer to try the newest GNU xorriso snapshot.

I read the man page of contemporary mkisofs
http://cdrtools.sourceforge.net/private/man/cdrecord/mkisofs.8.html
and implemented in xorriso's mkisofs emulation:

-eltorito-platform "x86"|"PPC"|"Mac"|"efi"|0xnn|nnn
Set the Platform Id number for the next option -b or
-eltorito-boot. The number may be chosen by a platform name or
by a number between 0 and 255 (0x00 and 0xFF). "x86" = 0 is for
PC-BIOS, "PPC" = 1 for some PowerPC systems, "Mac" = 2 for some
MacIntosh systems, "efi" = 0xEF for EFI on modern PCs with x86
compatible CPUs or others.
If the new platform id differs from the previous one,
-eltorito-alt-boot is performed.

There may still be subtle differences between this and the behavior of
mkisofs. (But i lowered myself to make -eltorito-alt-boot conditional. :))

A test with

xorriso -as mkisofs -o test.iso \
-b bios_image -no-emul-boot -boot-load-size 4 -boot-info-table \
-eltorito-alt-boot \
-eltorito-platform 0xEF -eltorito-boot efi_image -no-emul-boot \
images_directory

yields an ISO about which

xorriso -indev test.iso -report_el_torito plain

reports

El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x0000 0x00 4 3937
El Torito boot img : 2 UEFI y none 0x0000 0x00 15612 34
El Torito img path : 1 /bios_image
El Torito img opts : 1 boot-info-table
El Torito img path : 2 /efi_image

-------------------------------------------------------------------

GNU xorriso is a static compilation of the same source which Debian
has as 4 libraries and a small binary. Other than the libraries it
exists not only as release versions but also as development snapshot.

To get the current development snapshot do

mkdir "$HOME"/xorriso_dir
cd "$HOME"/xorriso_dir
wget http://www.gnu.org/software/xorriso/xorriso-1.4.7.tar.gz
tar xzf xorriso-1.4.7.tar.gz
cd xorriso-1.4.7
./configure && make

This needs the tools from Debian meta-package "build-essential":
gcc, ld, "make", ...
(The MD5 of the current tarball is 46e10e669732d47151fa42a71500bfbf.
In a few days, there may be a new upload with different MD5, though.)

After above commands there should be a binary which can tell its version

$ ./xorriso/xorriso -version
GNU xorriso 1.4.7 : RockRidge filesystem manipulator, libburnia project.
...
xorriso version : 1.4.7
Version timestamp : 2017.06.03.163742
...

Next replace the little Debian xorriso binary by the large GNU xorriso:

xorriso="$(which xorriso)"
sudo mv "$xorriso" "$xorriso"-debian
sudo cp xorriso/xorriso "$xorriso"

Verify that you now have GNU xorriso in the command PATH

xorriso -version

and then try whether it brings better results with Mondo Rescue.


Have a nice day :)

Thomas