grub-mkrescue hfsplus GPT partition is not mountable on Linux

grub-mkrescue hfsplus GPT partition is not mountable on Linux

[Andrei Borzenkov]

Current GRUB GIT, Ubuntu 14.04 (kernel 3.13.0-74-generic), USB stick (I
have no CD drive).

xorriso used under openSUSE Tumbleweed:

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


Attempt to mount third GPR partition as HFS+ results in failure.
Additionally it tries to interpret the first (dummy) partition, which is
not fatal but annoying.

[24623.255932]  sdb: sdb1 sdb2 sdb3
[24623.256733] sd 5:0:0:0: [sdb] No Caching mode page found
[24623.256736] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[24623.256738] sd 5:0:0:0: [sdb] Attached SCSI removable disk
[24623.483845] isofs_fill_super: bread failed, dev=sdb1, iso_blknum=71,
block=142
[24623.487605] hfsplus: invalid secondary volume header
[24623.487608] hfsplus: unable to find HFS+ superblock

xorriso report.

El Torito catalog  : 1674  1
El Torito cat path : /boot.catalog
El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4        7279
El Torito boot img :   2  UEFI  y   none  0x0000  0x00   5760          87
El Torito img path :   1  /boot/grub/i386-pc/eltorito.img
El Torito img opts :   1  boot-info-table grub2-boot-info
El Torito img path :   2  /efi.img
System area options: 0x00004201
System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off
GPT APM
ISO image size/512 : 30292
Partition offset   : 0
MBR heads per cyl  : 64
MBR secs per head  : 32
MBR partition table:   N Status  Type        Start       Blocks
MBR partition      :   1   0x00  0xee            1        30291
GPT                :   N  Info
GPT disk GUID      :      9b29d8ed2179ff43a11959efd5fa085e
GPT entry array    :      20  176  separated
GPT lba range      :      64  30246  30291
GPT partition name :   1  4700610070003000
GPT partname local :   1  Gap0
GPT partition GUID :   1  9b29d8ed2179ff43a11a59efd5fa085e
GPT type GUID      :   1  a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags:   1  0x1000000000000001
GPT start and size :   1  64  284
GPT partition name :   2
450046004900200062006f006f007400200070006100720074006900740069006f006e00
GPT partname local :   2  EFI boot partition
GPT partition GUID :   2  9b29d8ed2179ff43a11b59efd5fa085e
GPT type GUID      :   2  28732ac11ff8d211ba4b00a0c93ec93b
GPT partition flags:   2  0x1000000000000001
GPT start and size :   2  348  5760
GPT partition path :   2  /efi.img
GPT partition name :   3  4700610070003100
GPT partname local :   3  Gap1
GPT partition GUID :   3  9b29d8ed2179ff43a11859efd5fa085e
GPT type GUID      :   3  a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags:   3  0x1000000000000001
GPT start and size :   3  6108  24136
APM                :   N  Info
APM block size     :      2048
APM gap fillers    :      2
APM partition name :   1  Gap0
APM partition type :   1  ISO9660_data
APM start and size :   1  16  1511
APM partition name :   2  HFSPLUS_Hybrid
APM partition type :   2  Apple_HFS
APM start and size :   2  1527  5884
APM partition name :   3  Gap1
APM partition type :   3  ISO9660_data
APM start and size :   3  7411  162

apple2 is actually smaller than gpt3, and Linux kernel checks secondary
header which is expected to be at the end of partition.

I am not sure what is intended here, but apparently Linux does not
support APM so being able to access HFS+ partition via GPT is a bonus.
In which case name "Gap1" is misleading :)

And is the very first partition really needed? It is not used by GRUB
anyway, and there is no requirement that each bit of media is covered.

Re: grub-mkrescue hfsplus GPT partition is not mountable on Linux

[Thomas Schmitt]

Hi,

sorry, i misposted this answer to bug-grub, rather than grub-devel.
With the wrong subject, too. Internal thread error.

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

Andrei Borzenkov wrote:
> Attempt to mount third GPR partition as HFS+ results in failure.
> Additionally it tries to interpret the first (dummy) partition, which is
> not fatal but annoying.
> [24623.487605] hfsplus: invalid secondary volume header
> [24623.487608] hfsplus: unable to find HFS+ superblock

The HFS+ failure is due to APM block size 2048.
Linux has 512 hardcoded.

We need to record APM in 2048 blocks in order to have room for the
GPT header block at byte 512. The first APM entry is at byte 2048.
The GPT entry array is after the last APM entry.

I discussed this with Vladimir Serbinenko and George Danchev (my DD)
in June 2012 when we introduced HFS+. George had the same complaint
as you.
Vladimir checked mountability with his Mac reference machine.

My assessment back then with a Linux kernel 2.6i.32 was that the
APM Block0 is not interpreted at all. Its bytes 2 and 3 tell the
block size.
The problem was with the partition map only. As soon as the filesystem
is found, the block size was no issue. (Maybe it's 512 in the filesystem.
I'd have to dig in Vladimir's contributed code.)

I even patched fs/hfsplus/part_tbl.c to make it mount on my test
machine. The patch does not match what i see in linux-4.1.6, i fear.

In linux-4.1.6/fs/hfsplus/part_tbl.c i see an iteration over
the list of partition table entries:

        do {
                ...
                pm = (struct new_pmap *)((u8 *)pm + HFSPLUS_SECTOR_SIZE);
                ...
        } while (pm->pmSig == cpu_to_be16(HFS_NEW_PMAP_MAGIC));

In fs/hfsplus/hfsplus_raw.h i see:

  #define HFSPLUS_SECTOR_SIZE        512
  #define HFSPLUS_SECTOR_SHIFT         9

The magic number of Block0 is defined in fs/hfsplus/part_tbl.c
and in fs/hfs/hfs.h
  #define HFS_DRVR_DESC_MAGIC       0x4552 /* "ER": driver descriptor map */
but not used anywhere underneath linux-4.1.6/fd.
So still not interpreted.

(The GRUB2 MBR starts by "ER\200\000". x86 CPUs take no offense.)


> apple2 is actually smaller than gpt3, and Linux kernel checks secondary
> header which is expected to be at the end of partition.

gpt3 + gpt-backup should cover the same range as apple2 + apple3.

The layout as decided by Vladimir is documented in sectiom
  GRUB2 grub-mkrescue MBR
of
  xorriso-*/doc/boot_sectors.txt
  http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt

Currently around line 1540.
Ignore any mentioning of FAT. This is not implemented.
We obviously had no compelling use case.


> I am not sure what is intended here, but apparently Linux does not
> support APM

It supports APM with block size 512. If you avoid any GPT production
and use xorriso -as mkisofs option
  -apm-block-size 512 -hfsplus ...blessings.or.not...
then the result should be mountable (read-only iirc).


> so being able to access HFS+ partition via GPT is a bonus.
> In which case name "Gap1" is misleading :)

GPT "Gap1" is only the final filler up to the backup GPT.
This mountability is a quite inadverted but reliable consequence of
the layout which Vladimir and i negociated in 2012.
In absence of PreP, the HFS+ partition directly follows after
the EFI boot partition.

Actually the layout plan says that there should be a GPT partition
dedicated to HFS+.

GPT Partitions:
   The primary GPT itself covers the System Area.
   Basic Data  from   16 to  EFI-1, protects first part of ISO image
   EFI System  from  EFI to PREP-1, offers EFI image for booting
   Basic Data  from PREP to HFAT-1, protects PreP partition
   HFS+        from HFAT to TAIL-1, offers HFS+ for mounting
   Basic Data  from TAIL to GPTB-1, protects rest of ISO image (if there is)

The middle "Basic Data" would be missing because empty.
But there should be 4 GPT partitions, not 3 as in your ISO.

Might be that this was never correctly implemented.
At least libisofs/hfsplus.c only registers an APM slot named
"HFSPLUS_Hybrid" but no GPT slot.

Hrmpf. This might be the reason why HFS+ was supposed to imply
the production of GPT.
I will investigate where and how i can add a GPT partition for
HFS+ if GPT gets produced.


> And is the very first partition really needed? It is not used by GRUB
> anyway, and there is no requirement that each bit of media is covered.

Vladimir wanted it. It protects against inadverted partition editing.


Thanks for testing, guys !
It is always astounding how many roaches hide under the carpet.


Have a nice day :)

Thomas

Re: grub-mkrescue hfsplus GPT partition is not mountable on Linux

[Thomas Schmitt]

Hi,

sorry, i misposted this answer to bug-grub, rather than grub-devel.
With the wrong subject, too. Internal thread error.

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

Andrei Borzenkov wrote:
> Attempt to mount third GPR partition as HFS+ results in failure.
> Additionally it tries to interpret the first (dummy) partition, which is
> not fatal but annoying.
> [24623.487605] hfsplus: invalid secondary volume header
> [24623.487608] hfsplus: unable to find HFS+ superblock

The HFS+ failure is due to APM block size 2048.
Linux has 512 hardcoded.

We need to record APM in 2048 blocks in order to have room for the
GPT header block at byte 512. The first APM entry is at byte 2048.
The GPT entry array is after the last APM entry.

I discussed this with Vladimir Serbinenko and George Danchev (my DD)
in June 2012 when we introduced HFS+. George had the same complaint
as you.
Vladimir checked mountability with his Mac reference machine.

My assessment back then with a Linux kernel 2.6i.32 was that the
APM Block0 is not interpreted at all. Its bytes 2 and 3 tell the
block size.
The problem was with the partition map only. As soon as the filesystem
is found, the block size was no issue. (Maybe it's 512 in the filesystem.
I'd have to dig in Vladimir's contributed code.)

I even patched fs/hfsplus/part_tbl.c to make it mount on my test
machine. The patch does not match what i see in linux-4.1.6, i fear.

In linux-4.1.6/fs/hfsplus/part_tbl.c i see an iteration over
the list of partition table entries:

        do {
                ...
                pm = (struct new_pmap *)((u8 *)pm + HFSPLUS_SECTOR_SIZE);
                ...
        } while (pm->pmSig == cpu_to_be16(HFS_NEW_PMAP_MAGIC));

In fs/hfsplus/hfsplus_raw.h i see:

  #define HFSPLUS_SECTOR_SIZE        512
  #define HFSPLUS_SECTOR_SHIFT         9

The magic number of Block0 is defined in fs/hfsplus/part_tbl.c
and in fs/hfs/hfs.h
  #define HFS_DRVR_DESC_MAGIC       0x4552 /* "ER": driver descriptor map */
but not used anywhere underneath linux-4.1.6/fd.
So still not interpreted.

(The GRUB2 MBR starts by "ER\200\000". x86 CPUs take no offense.)


> apple2 is actually smaller than gpt3, and Linux kernel checks secondary
> header which is expected to be at the end of partition.

gpt3 + gpt-backup should cover the same range as apple2 + apple3.

The layout as decided by Vladimir is documented in sectiom
  GRUB2 grub-mkrescue MBR
of
  xorriso-*/doc/boot_sectors.txt
  http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt

Currently around line 1540.
Ignore any mentioning of FAT. This is not implemented.
We obviously had no compelling use case.


> I am not sure what is intended here, but apparently Linux does not
> support APM

It supports APM with block size 512. If you avoid any GPT production
and use xorriso -as mkisofs option
  -apm-block-size 512 -hfsplus ...blessings.or.not...
then the result should be mountable (read-only iirc).


> so being able to access HFS+ partition via GPT is a bonus.
> In which case name "Gap1" is misleading :)

GPT "Gap1" is only the final filler up to the backup GPT.
This mountability is a quite inadverted but reliable consequence of
the layout which Vladimir and i negociated in 2012.
In absence of PreP, the HFS+ partition directly follows after
the EFI boot partition.

Actually the layout plan says that there should be a GPT partition
dedicated to HFS+.

GPT Partitions:
   The primary GPT itself covers the System Area.
   Basic Data  from   16 to  EFI-1, protects first part of ISO image
   EFI System  from  EFI to PREP-1, offers EFI image for booting
   Basic Data  from PREP to HFAT-1, protects PreP partition
   HFS+        from HFAT to TAIL-1, offers HFS+ for mounting
   Basic Data  from TAIL to GPTB-1, protects rest of ISO image (if there is)

The middle "Basic Data" would be missing because empty.
But there should be 4 GPT partitions, not 3 as in your ISO.

Might be that this was never correctly implemented.
At least libisofs/hfsplus.c only registers an APM slot named
"HFSPLUS_Hybrid" but no GPT slot.

Hrmpf. This might be the reason why HFS+ was supposed to imply
the production of GPT.
I will investigate where and how i can add a GPT partition for
HFS+ if GPT gets produced.


> And is the very first partition really needed? It is not used by GRUB
> anyway, and there is no requirement that each bit of media is covered.

Vladimir wanted it. It protects against inadverted partition editing.


Thanks for testing, guys !
It is always astounding how many roaches hide under the carpet.


Have a nice day :)

Thomas

Re: grub-mkrescue hfsplus GPT partition is not mountable on Linux

[Andrei Borzenkov]

23.12.2015 01:54, Thomas Schmitt пишет:
> 
> The HFS+ failure is due to APM block size 2048.
> Linux has 512 hardcoded.
> 

No, it has not.

> 
> My assessment back then with a Linux kernel 2.6i.32 was that the
> APM Block0 is not interpreted at all. Its bytes 2 and 3 tell the
> block size.

Do not confuse APM and HFS+. Block size in APM has no relation to block
size in HFS+. Neither in Linux nor in GRUB. And GRUB never uses APM
block size when reading HFS+ either.

> 
> In fs/hfsplus/hfsplus_raw.h i see:
> 
>   #define HFSPLUS_SECTOR_SIZE        512
>   #define HFSPLUS_SECTOR_SHIFT         9
> 

This is simply *minimal* HFS+ block size, same as in GRUB.

> 
>> I am not sure what is intended here, but apparently Linux does not
>> support APM
> 
> It supports APM with block size 512.

It supports APM with any size. It is just that APM has lower priority in
Linux so MSDOS or GPT win and Linux does not support multiple partition
labels on device.

And again - APM is irrelevant here, we do not access HFS+ via APM, we
access it via GPT in this case. If I adjust gpt3 to be of the same size
as apple2 it is happily mounted by Linux. So there is absolutely no
issue with block size in HFS+.

> 
> Hrmpf. This might be the reason why HFS+ was supposed to imply
> the production of GPT.
> I will investigate where and how i can add a GPT partition for
> HFS+ if GPT gets produced.
> 

If you insist on covering the whole range, just add one more GPT
partition after it.

> 
>> And is the very first partition really needed? It is not used by GRUB
>> anyway, and there is no requirement that each bit of media is covered.
> 
> Vladimir wanted it. It protects against inadverted partition editing.
> 

Not following here. The whole image is created by dedicated tool and is
mainly intended for read-only media anyway.

Re: grub-mkrescue hfsplus GPT partition is not mountable on Linux

[Thomas Schmitt]

Hi,

i wrote:
> > The HFS+ failure is due to APM block size 2048.
> > Linux has 512 hardcoded.

Andrei Borzenkov wrote:
> No, it has not.

Seems to fixed meanwhile, indeed.

I patched away MBR partition table and GPT. After that, the partition
/dev/sdb3 does mount. (sdb1 is the APM partition table, sbd2 and sdb4
are "Gap0" and "Gap1".)

But there is a HFS+ problem regardless of partitioning.
See below.


> Do not confuse APM and HFS+.

I shall rather not confuse APM with GPT when reading.

> If I adjust gpt3 to be of the same size
> as apple2 it is happily mounted by Linux.

I would not have expected that the oversize spoils mountability.
Thus my misreading.


Whatever, the lack of a GPT partition for HFS+ is fixed by
  http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/1297/libisofs/system_area.c

It now yields when run by grub-mkrescue (Debian Sid, "2.02~beta2-33",
grub-efi-ia32-bin, grub-efi-amd64-bin, grub-pc-bin)

  GPT partition name :   3  48004600530050004c0055005300
  GPT partname local :   3  HFSPLUS
  GPT partition GUID :   3  54048af0155bb44aa145348d46e87e81
  GPT type GUID      :   3  005346480000aa11aa1100306543ecac
  GPT partition flags:   3  0x1000000000000001
  GPT start and size :   3  6096  24096

together with

  APM partition name :   2  HFSPLUS_Hybrid
  APM partition type :   2  Apple_HFS
  APM start and size :   2  1524  6024

I boot a Debian Jessie VM with that image as -hdb (booted is -hda).
fdisk reports

  Device     Start   End Sectors  Size Type
  /dev/sdb1     64   335     272  136K Microsoft basic data
  /dev/sdb2    336  6095    5760  2.8M EFI System
  /dev/sdb3   6096 30191   24096 11.8M Apple HFS/HFS+
  /dev/sdb4  30192 30791     600  300K Microsoft basic data

I can do as uperuser

  # mount /dev/sdb3 /mnt/hfs

without error message.
But then there is a HFS+ problem which i cannot explain yet:

  # ls /mnt/hfs
  ls: reading directory /mnt/hfs: Input/output error
  System  boot  empty-file.txt  mach_kernel

whereas

  # mount -o loop /dev/sdb /mnt/iso
  # ls /mnt/iso
  System  boot  boot.catalog  efi.img  empty-file.txt  mach_kernel

dmesg has:

  [  354.871503] hfsplus: Filesystem is marked locked, mounting read-only.
  [  359.020970] hfsplus: walked past end of dir

uname -a :

  Linux ... 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u4 (2015-09-19) x86_64 GNU/Linux


It does not look like a problem with the partition.
I have no clue of HFS+ internals. It's done by Vladimir's code in

  http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/libisofs/hfsplus.c
  http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/libisofs/hfsplus.h
  http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/libisofs/hfsplus_case.c
  http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/libisofs/hfsplus_classes.c
  http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/libisofs/hfsplus_decompose.c

I only provided some glue code and replacements for copyrighted
tables (which are specified freely, to our luck).

If this is a real problem with the boot purpose of the ISO, then
we will have to ask Vladimir for help.

(Mountability and readability on Linux is nice-to-have. But i
 assume that Vladimir is too busy to work on such an issue.)


> > > And is the very first partition really needed? 
> > Vladimir wanted it.
> Not following here.

We should ask Vladimir for the exact motivation of the filler
partitions and show him an evaluation of drawbacks.


Have a nice day :)

Thomas

Re: grub-mkrescue hfsplus GPT partition is not mountable on Linux

[Thomas Schmitt]

Hi,

i hopefully identified the cause of the i/o error with kernel
message
    [  359.020970] hfsplus: walked past end of dir

It seems to be an original mistake by Vladimir (who normally
makes much less mistakes than i do).
Since Andrei is surely more familiar with Vladimir's coding habits
and quite surely has more clue about HFS+, i post my analysis for
review.

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

In  libisofs/hfsplus.c  there is a function  create_tree() :

  http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/1249/libisofs/hfsplus.c#L299

It converts file objects from the libisofs tree model into objects
of the HFS+ tree model. The function returns 0 without creating
a new HFS+ tree object for files which it deems to be ignorable.
In case of error the return value is < 0.
In case of successful creation of HFS+ object and sub objects
it returns ISO_SUCCESS, which is > 0.

The two callers of create_tree() return error, if they receive
a return value < 0.
But they increment the directory children counter without
regarding return value 0.

This happens in the loop for populating the root directory

  http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/1249/libisofs/hfsplus.c#L1660

and in the loop for recursively populating other directories

  http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/1249/libisofs/hfsplus.c#L400

In my test runs, two files get ignored in the root directory:
  /boot.catalog  ... because it is not a data file in the libisofs
                     model but rather a boot catalog.
                     (For HFS+ this difference would not matter.)
  /efi.img ......... because it is explicitely hidden from HFS+.
                     (Not so clear why libisofs/eltorito.c hides
                      the first EFI boot image from HFS+. Shrug.)

So the HFS+ root directory gets a .nchildren count of 6, but only 4
HFS+ file objects get registered for populating the root directory.


The remedy is to increment .nchildren only if create_tree() returned
a value > 0.
After i changed both loops, i get from grub-mkrescue an ISO, where
i can mount and explore /dev/sdb3 (via GPT) without i/o error.

  http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/1298/libisofs/hfsplus.c

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

Have a nice day :)

Thomas

Re: [Bug-xorriso] grub-mkrescue hfsplus GPT partition is not mountable on Linux

[Andrei Borzenkov]

26.12.2015 14:39, Thomas Schmitt пишет:
> i hopefully identified the cause of the i/o error with kernel
> message
>     [  359.020970] hfsplus: walked past end of dir
> 
...

> After i changed both loops, i get from grub-mkrescue an ISO, where
> i can mount and explore /dev/sdb3 (via GPT) without i/o error.
> 
>   http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/1298/libisofs/hfsplus.c
> 

Thanks!

BTW is xorriso available from single GIT repo?

Re: grub-mkrescue hfsplus GPT partition is not mountable on Linux

[Thomas Schmitt]

Hi,

> BTW is xorriso available from single GIT repo?

For historical reasons the software is scattered over a bzr repo
for libisofs and a svn repo for libburn and libisoburn.
  bzr branch lp:~libburnia-team/libisofs/scdbackup ./nglibisofs-develop
  svn co http://svn.libburnia-project.org/libburn/trunk ./libburn-develop
  svn co http://svn.libburnia-project.org/libisoburn/trunk ./libisoburn-develop
They yield three .so libraries and a small xorriso main program.
Upstream
  ./bootstrap && ./configure && make
  make install
should work out of the box. First libisofs, then libburn, then
libisoburn.

But one will have to keep the resulting xorriso from linking with
older system-wide installed libburn.so, libisofs.so, libisoburn.so.


GNU xorriso can be derived from checked-out libisofs, libburn, and
libisoburn repos. They have to be reachable under peculiar names.
Further it needs directory jigit-1.17/libjte from
  http://www.einval.com/~steve/software/JTE/download/jigit_1.17.orig.tar.gz

The emerging xorriso/xorriso is weighty and immune against linking
to any installed libburn.so, libisofs.so, or libisoburn.so.

The equivalent to "git clone" is this (indeed constant :)) script:

  mkdir ./gnu_xorriso_test
  cd ./gnu_xorriso_test
  bzr branch lp:~libburnia-team/libisofs/scdbackup ./nglibisofs-develop
  svn co http://svn.libburnia-project.org/libburn/trunk ./libburn-develop
  svn co http://svn.libburnia-project.org/libisoburn/trunk ./libisoburn-develop
  wget http://www.einval.com/~steve/software/JTE/download/jigit_1.17.orig.tar.gz
  tar xzf jigit_1.17.orig.tar.gz
  ln -s jigit-1.17/libjte ./jte-develop
  (cd libisoburn-develop && ./bootstrap)
  (cd libisoburn-develop/xorriso && 
   cc -g -Wall -o unite_html_b_line unite_html_b_line.c )

  ./libisoburn-develop/xorriso/make_xorriso_standalone.sh

There might get reported a problem with "man -H" during
make_xorriso_standalone.sh :
   man: command exited with status 3:
   /usr/lib/man-db/zsoelim | preconv -e UTF-8 | tbl | groff -mandoc -Thtml
It works on my fat workstation but not on the lean VM.

This produces directory tree

  ./xorriso-standalone

and the development snapshot tarball (currently ../xorriso-1.4.3.tar.gz).
The new directory tree is equivalent to the unpacked tarball tree
./xorriso-1.4.3 and suitable for

  cd ./xorriso-standalone
  ./configure && make

Check executability and runtime dependencies

  xorriso/xorriso -version
  ldd xorriso/xorriso

Please ignore compiler warnings about libjte. I need to pester
Steve McIntyre to include a few cosmetic changes in the upstream.
It is not related to bootability but to Debian download system Jigdo.

If you want to debug, best remove the two instances of "-O2" in
./configure. Then run "./configure && make clean && make".
Extra nice to debug and extra slow is -O0.


Have a nice day :)

Thomas