grub-mkrescue/xorriso missing syscall in 11.0

ericbsd

Developer
I wonder if any one have an idea of what syscall that is missing in FreeBSD 11.0 to cause the following problem?

Code:
grub-mkrescue -o /usr/obj/amd64/mate/GhostBSD11.0-ALPHA1-20160906-091104-mate-amd64.iso /usr/ghostbsd-fs/amd64/mate -volid GHOSTBSD
xorriso 1.4.2 : RockRidge filesystem manipulator, libburnia project.

Drive current: -outdev 'stdio:/usr/obj/amd64/mate/GhostBSD11.0-ALPHA1-20160906-091104-mate-amd64.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data,  254g free
Added to ISO image: directory '/'='/tmp/grub.ME7AAH'
xorriso : UPDATE : 614 files added in 1 seconds
Added to ISO image: directory '/'='/usr/ghostbsd-fs/amd64/mate'
xorriso : UPDATE : 2997 files added in 1 seconds
xorriso : NOTE : Copying to System Area: 512 bytes from file '/usr/local/lib/grub/i386-pc/boot_hybrid.img'

UNIX-SIGNAL:  SIGSEGV  errno= 22
xorriso : ABORT : Trying to shut down drive and library
xorriso : ABORT : Wait the normal burning time before any kill -9

xorriso : ABORT : Program done. Even if you do not see a shell prompt.
 
Hi,

i'm the developer of xorriso (and test it on FreeBSD 8 before release).

Now i am curious what might be the problem here. If you need to get
a stack trace, consider to use grub-mkrescue option --xorriso=
to foist a script under grub-mkrescue which prints its arguments
and waits endlessly. Like:
Code:
  #/bin/sh
  echo "$@"
  sleep 86400

With the printed arguments and the still prepared GRUB directories
it should be possible to perform the xorriso run under debugger
control.

If you need to build from source, use this all-in-one tarball:
http://scdbackup.sourceforge.net/xorriso-1.4.2.tar.gz
(Current is 1.4.4. I do not expect version to matter much.)

Have a nice day :)

Thomas
 
Hello,

I have tryed to reproduce the issue and I can confirm that exists but only when in system where iso is built with grub-mkrescue is installed grub2-efi package.
If grub2-efi is missing xorriso doesn't crash and iso is built fine but without efi support.
Guess it should be contacted kmoore@FreeBSD.org because he is grub2-efi maintainer in FreeBSD.

Thank you.
 
Hi,

> If grub2-efi is missing xorriso doesn't crash

That's really strange. But also rules out any problems with libburn
and its system specific dependencies libcam and atapicam. (They should
not be involved with ISO image production anyway.)

> Guess it should be contacted kmoore@FreeBSD.org

xorriso under grub-mkrescue does not look into the EFI boot image
but just marks it by an entry in the El Torito boot catalog and by
a GPT partition. Possibly an Apple Partition Map and a HFS+ filesystem
tree, too.
So the GRUB files can hardly be to blame on the first hand.

This looks like a xorriso bug, to my embarrassment.
I could need:

- A stack trace of the situation when it crashes.
(See above proposal to catch the xorriso arguments. One could of
course directly perform a debugger run with those arguments.)

- A confirmation that this still happens with
http://scdbackup.sourceforge.net/xorriso-1.4.5.tar.gz
It should compile out of the box by
Code:
tar xzf xorriso-1.4.5.tar.gz
cd xorriso-1.4.5
./configure && make
and then be executable without further installation
Code:
xorriso_path=$(pwd)/xorriso/xorriso
cd ...somewhere.else...
grub-mkrescue --xorriso="$xorriso_path" ...other.arguments...

Meanwhile i wonder why this thread is titled "missing syscall".
The last info from xorriso is
Code:
UNIX-SIGNAL:  SIGSEGV  errno= 22
As a SIGSEGV norally is not accompanied by an error code, i assume that
errno 22 is a remnant from a previous system call.

Have a nice day :)

Thomas
 
This looks like a xorriso bug, to my embarrassment.

Not really, xorriso appear to work properly on FreeBSD 10.3, in the context reported from AngelescuO, and the problem only appeared on FreeBSD 11.xx.

As for the thread title, because yesterday I was chatting with ericturgeon about the issue, I know he was very tired at the time he wrote his post, most likely a misunderstanding of the error message.
 
scdbackup
Code:
grub-mkrescue -o /usr/obj/amd64/mate/GhostBSD11.0-ALPHA1-20160906-091104-mate-amd64.iso /usr/ghostbsd-fs/amd64/mate -volid GHOSTBSD
That command was working well under GhostBSD/FreeBSD 10.3 which also still work well in 10.3, the error is only under 11.0.
 
AngelescuO and scdbackup I did removed grub-efi and the ISO successfully build. I do not know much about xorriso and grub-mkrescue, but under 10.3 it build whatever grub-efi is install of not.
 
Hi,

ericturgeon wrote:
> under 10.3 it build whatever grub-efi is install of not.

That's how it should be.
It is a riddle how the quite unconspicious processing of the EFI System
Partition is able to trigger this SIGSEGV in a system dependent way.
I remember to have massively tested grub-mkrescue on Debian G../L....
when i added wrapper script frontend/grub-mkrescue-sed.sh to
libisoburn-1.4.4.

> I do confirm that xorriso 1.4.5 is working with grub-efi and without
> grub-efi.

That's quite a surprise.
Can you test the same with

http://scdbackup.sourceforge.net/xorriso-1.4.2.tar.gz

which is nearly source code identical to the ports libraries
libburn-1.4.2.pl01, libisofs-1.4.2, libisoburn-1.4.2
but is linked statically. (The reason for releasing libburn-1.4.2.pl01
is supposed not to affect xorriso.)

If the statically linked xorriso works, then i might be able to forward
the shame to dynamic linking. (Any idea how to inspect that aspect ?)

In any case a stack trace of the crash with the ports libraries
would help to clarify whether xorriso's source or the linker of
FreeBSD 11 is to blame.

Have a nice day :)

Thomas
 
Hi,

i found a candidate in respect to problems with dynamical linking.

In april 2016, RedHat and Ubuntu began to suffer from unexplainable
SIGSEGVs in several packages which formerly ran fine. Among them was
dynamically linked xorriso.
https://bugzilla.redhat.com/show_bug.cgi?id=1320305
https://bugs.launchpad.net/ubuntu/+source/libisoburn/+bug/1571684
Matthias Klose found the trigger and blamed the problem on glibc changes
which reacted badly on a stupid linker option:
https://sourceware.org/bugzilla/show_bug.cgi?id=19966

I did not follow further after
http://libburnia-project.org/changeset/5692
of libisoburn 1.4.3 implemented Matthias' patch and fixed the RedHat problem.

Whether the stupid option was to be applied was determined by an automat
in ./configure. So it may or not may be in effect on FreeBSD 11 and may
or may not cause problems with the linker or libc there.

I see in
http://portsmon.freebsd.org/portoverview.py?category=sysutils&portname=xorriso
that only version 1.4.2 is available.
http://portsmon.freebsd.org/portoverview.py?category=devel&portname=libisofs
http://portsmon.freebsd.org/portoverview.py?category=devel&portname=libburn
are already at version 1.4.4.
So it should be no problem to bump xorriso in ports to 1.4.4.

It might be worth to try this in advance:

- Make sure to have the ports of libburn-1.4.4 and libisofs-1.4.4 installed.
Ask the installed xorriso from ports by:
xorriso -version
which should yield
Code:
xorriso version   :  1.4.2
...
libisofs   in use :  1.4.4  (min. 1.4.2)
...
libburn    in use :  1.4.4  (min. 1.4.2)
...
libisoburn in use :  1.4.2  (min. 1.4.2)
...

- Uninstall xorriso from ports in the hope to uninstall libisoburn.so*
(Maybe a find run before and after uninstallation can confirm that
it worked as hoped.)

- Install libisoburn and dynamically linked xorriso from upstream source:
http://files.libburnia-project.org/releases/libisoburn-1.4.4.tar.gz
by
Code:
tar xzf libisoburn-1.4.4.tar.gz
cd libisoburn-1.4.4
./configure && make
make install
(This works out of the box on FreeBSD 8. Please report any necessary
adaptions together with info how to recognize systems which need
that adaption.)

If the reason for the FreeBSD 11 problem is the bad linker option in
the makefile of libisoburn-1.4.2, then xorriso-1.4.4 from libisoburn-1.4.4
should work without SIGSEGV.


Have a nice day :)

Thomas
 
  • Thanks
Reactions: ASX
There is no maintainer in the moment, I have try to fix the ports, but I can figure what is wrong.
 
Back
Top