[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#898995: live-wrapper: debian-live-9.4.0-amd64-xfce.iso image file is larger than its isosize



Source: live-wrapper
Version: which made debian-live-9.4.0-amd64-xfce.iso, possibly newer than 0.7
Severity: normal

Dear Maintainer,

as Mike Kupfer pointed out in
  https://lists.debian.org/debian-user/2018/05/msg00522.html
the file size of
  debian-live-9.4.0-amd64-xfce.iso
is larger than the filesystem size reported by
  isosize -x debian-live-9.4.0-amd64-xfce.iso

It is undesirable to have sizes differing between filesystem and image file,
because
  https://www.debian.org/CD/faq/#verify
proposes to use isosize for determining the checksummed size on a medium
which does not mark the end of the image file copy.

The difference is 32 KiB. It pads up the image file to full multiples of
64 KiB.
The reason for this padding is the multi-session preparation of xorriso
which is done by default if the native command set is used. It is disabled
by default in mkisofs emultation.

debian-live-9.3.0-amd64-xfce.iso was not affected because its filesystem
size was already aligned to 64 KiB.

---------------------------------------------------------------------------
Proposal:

Add to the xorriso run of live-wrapper the command

  -compliance no_emul_toc

which will disable the multi-session preparation.

---------------------------------------------------------------------------
Test made:

I repacked debian-live-9.4.0-amd64-xfce.iso by mounting it as /mnt/iso
and running xorriso similar to the recorded run in its file
  /.disk/mkisofs
with the proposed command added.

  xorriso-1.4.6 \
    -outdev /dvdbuffer/x.iso \
    -volid 'd-live 9.4.0 xf amd64' \
    -padding 0 \
    -map /mnt/iso / \
    -chmod 0755 / -- \
    -boot_image isolinux dir=/isolinux \
    -boot_image isolinux system_area=/dvdbuffer/isohdpfx.bin \
    -boot_image any next \
    -boot_image any efi_path=boot/grub/efi.img \
    -boot_image isolinux partition_entry=gpt_basdat \
    \
    -compliance no_emul_toc

The resulting file /dvdbuffer/x.iso has  1951432704 bytes.
isosize -x reports the matching number of 952848 blocks of 2048 bytes.


There remains the riddle why i cannot find xorriso command
  -padding 0
in
  https://sources.debian.org/src/live-wrapper/0.7/lwr/xorriso.py/
/.disk/mkisofs indicates that it has been added to the argument list between
       self.args.extend(['-volid', self.volume_id])
and
       self.args.extend(['-map', cdroot, '/'])
But the code does not do this.

---------------------------------------------------------------------------
Background:

Multi-session preparation on overwritable media (e.g. data files or DVD+RW)
writes the first session to block 32 ff. and writes a superblock copy to
block 0 ff. The session gets aligned to full 64 KiB to avoid remaining
garbage between this session and the next to come, which will start at the
aligned end address.
Each new session overwrites the superblock copy at block 0 ff. This way a
chain of recognizable sessions and their superblocks is created.
xorriso command -toc can then tell where each session begins and thus how
it can be mounted by mount(8) option -o sbsector=.

As example see one of my daily backup DVD+RWs with base session at block 32
and add-on sessions at 32-block-aligned start blocks ("sbsector"):

  Media blocks : 1996256 readable , 298848 writable , 2295104 overall
  TOC layout   : Idx ,  sbsector ,       Size , Volume Id
  ISO session  :   1 ,        32 ,   1242005s , HOME_Z_2018_04_24_220414
  ISO session  :   2 ,   1242048 ,     39682s , HOME_Z_2018_04_25_221507
  ...
  ISO session  :  20 ,   1908992 ,     44177s , HOME_Z_2018_05_16_223024
  ISO session  :  21 ,   1953184 ,     43051s , HOME_Z_2018_05_17_223716
  Media summary: 21 sessions, 1995881 data blocks, 3898m data,  584m free
  Media nwa    : 1996256s

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

-- System Information:
Unknown. The problem occurs during Debian Live CD production.


Have a nice day :)

Thomas


Reply to: