From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: grub-devel@gnu.org
Subject: Re: How important is the MBR partition offset of grub-mkrescue ?
Date: Sun, 03 Nov 2013 14:05:50 +0100 [thread overview]
Message-ID: <52764A2E.5050701@gmail.com> (raw)
In-Reply-To: <2627651367660158335@scdbackup.webframe.org>
[-- Attachment #1: Type: text/plain, Size: 2757 bytes --]
>
> This yields an MBR (copied from $old_iso) with partition start
> LBA 64 (16 blocks of 2048)
Hm, that would mean that some crapware like adobe might write between
MBR and first partition.
>
> 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.)
>
Yes, and we add HFS+ as well. Isn't this HFS+ catalog sufficient for the
problem at hand?
>
> 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
>
Can we detect presence of this bug?
>
> Theoretical problems:
>
Additional problem you don't mention: consumption of space by additional
headers. We use xorriso for making floppies as well (and it works).
> 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.
>
But it will most likely swallow HFS+-hybrid disk without any problem.
Perhaps we should generate HFS+-hybrid even for BIOS-only CDs.
Another solution is to have a hybrid ISO + FAT or ISO + HFS+ + FAT layouts.
> 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 ...
>
The reason for the specified partition is twofold:
- Some computers check for presence of an active partition.
- To avoid some software overwriting the ISO
If user desires to have a partition for data he can always add a second
partition but it doesn't solve the problem of accessing ISO files.
>
> Have a nice day :)
>
> Thomas
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
next prev parent reply other threads:[~2013-11-03 13:06 UTC|newest]
Thread overview: 15+ 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
2013-11-03 13:05 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
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 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
2013-11-04 15:44 ` 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=52764A2E.5050701@gmail.com \
--to=phcoder@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.