grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: "Thomas Schmitt" <scdbackup@gmx.net>
To: grub-devel@gnu.org
Subject: Re: How important is the MBR partition offset of grub-mkrescue ?
Date: Sun, 03 Nov 2013 13:21:36 +0100	[thread overview]
Message-ID: <2627651367660158335@scdbackup.webframe.org> (raw)
In-Reply-To: <52758DFE.3030604@gmail.com>

Hi,

> Noce to hear from you.

I am always watching here for any problems with ISOs.


> LBA 0 is not an option.

Thanks for confirming this (once again).


It turned out that /dev/sdb1 is link target in ./by-label
with any partition start LBA. Lack of brains.

So the last hope is the double superblock option of xorriso,
which to my knowledge was only tested with ISOLINUX up to now.
It seems to work with pure GRUB2 equipment too.

I repacked the ISO in question according to what i can
see in my olde copy of grub-mkrescue.
"$old_iso" is mounted at /mnt, modification-date was learned
from that image, /dvdbuffer is my local playground.
Option -partition_offset 16 is the new thing to be tested:

  xorriso -as mkisofs \
    -V "$version" \
    -o /dvdbuffer/"$version".iso \
    -graft-points \
    --modification-date=2013030413525500 \
    -b boot/grub/i386-pc/eltorito.img -no-emul-boot -boot-info-table \
    --embedded-boot "$old_iso" \
    --protective-msdos-label -r --sort-weight 0 / --sort-weight 1 /boot \
    -partition_offset 16 \
    /mnt

This yields an MBR (copied from $old_iso) with partition start
LBA 64 (16 blocks of 2048), two Primary Volume descriptors,
and two directory trees with the same file names but data block
addresses differing by 16.

The resulting image was put onto USB stick and DVD. Both boot fine
on my test machine.
Unlike with partition start at LBA 1, the USB stick can be mounted
as /dev/sdb and as /dev/sdb1.
(Simultaneously only by help of -o loop. Brain suffices to recognize
that /dev/sdb and /dev/sdb1 do overlap.)

My test machine boots via BIOS. The ISO image is only equipped
for BIOS, anyway. I have no means to test UEFI with partition
offset 16.

Does contemporary grub-mkrescue cause xorriso to produce GPT
for UEFI ? (That would be a new adventure with -partition_offset.)


If anybody has opportunity and curiosity:

It should be possible to append option -partition_offset 16
to the options of grub-mkrescue, so that it reaches xorriso
as one of the ${source} arguments.

There was a bug with -partition_offset with older versions
of xorriso, which caused Debian to stop using this option
in its amd64 UEFI capable images. So better get newest stable
xorriso for such a test. Currently this is:
  http://www.gnu.org/software/xorriso/xorriso-1.3.2.tar.gz


Theoretical problems:

El Torito booting from CD/DVD should not be influenced by
this unusual layout.  The ISO 9660 image beginning at LBA 0
is quite the same as without that option.

Nevertheless, there was a report that Apple "Snow Leopard"
refused to mount an ISO image with partition offset 16.
  http://lists.debian.org/debian-cd/2011/04/msg00032.html
  http://lists.debian.org/debian-cd/2011/04/msg00040.html
  http://lists.debian.org/debian-cd/2011/04/msg00042.html
Note well that this was not about booting.

Further, one never knows what the booting operating system
expects as layout of USB sticks. I consider the current layout
with LBA 1 to be more confusing. But that's only me ...


Have a nice day :)

Thomas



  reply	other threads:[~2013-11-03 12:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-02 18:57 How important is the MBR partition offset of grub-mkrescue ? Thomas Schmitt
2013-11-02 23:42 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-11-03 12:21   ` Thomas Schmitt [this message]
2013-11-03 13:05     ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-11-03 15:21       ` Thomas Schmitt
2013-11-03 15:48         ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-11-03 16:19           ` Thomas Schmitt
2013-11-03 16:32             ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-11-03 17:16           ` Thomas Schmitt
2013-11-04 12:08             ` Andrey Borzenkov
2013-11-04 14:03               ` Thomas Schmitt
2013-11-04 14:10                 ` Andrey Borzenkov
2013-11-04 14:21                   ` Thomas Schmitt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2627651367660158335@scdbackup.webframe.org \
    --to=scdbackup@gmx.net \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).