Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
arm64 and isohybrid
312 views
Skip to first unread message
Steve McIntyre
Jan 28, 2015, 6:10:02 PM1/28/15
to
Hi folks,
I've been playing with the arm64 netinst build a little today, when
installing a new machine. We *hadn't* been making them isohybrid thus
far, and therefore when I simply dumped one onto a USB stick using dd
it didn't work wonderfully. Due to the UEFI firmware being reasonably
intelligent, I could boot the installer off the USB stick. But later
on d-i failed to find and mount the "cdrom" so it bailed out - AFAICS
this is because there weren't any partitions on the media.
So... Next, I tried to add some xorriso isohybrid options to the
build, starting with
-isohybrid-gpt-basdat
but that didn't have any noticeable effect on my build. (I don't know
if that's expected!). Next, I bit my tongue and copied more of the
amd64 build, using bits of syslinux to add:
-isohybrid-mbr syslinux/usr/lib/syslinux/isohdpfx.bin
and that makes a big difference - I then ended up with the
normal-looking 2-partition image and d-i awas happy with
this.
So... Much as this image seems to work for me, it's bloody silly to be
using bits out of syslinux for an arm64 image! Thomas: what exactly
does xorriso need out of isohdpfx.bin to be able to make a *non* x86
bootable MBR etc. please? I'm *guessing* we just need a basic MBR-ony
boot sector that xorriso can modify with a partition table, but I
don't really know this area all that well. Can you give me some clues
please? :-)
--
Steve McIntyre, Cambridge, UK. st...@einval.com
"C++ ate my sanity" -- Jon Rabone
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/20150128230...@einval.com
I've been playing with the arm64 netinst build a little today, when
installing a new machine. We *hadn't* been making them isohybrid thus
far, and therefore when I simply dumped one onto a USB stick using dd
it didn't work wonderfully. Due to the UEFI firmware being reasonably
intelligent, I could boot the installer off the USB stick. But later
on d-i failed to find and mount the "cdrom" so it bailed out - AFAICS
this is because there weren't any partitions on the media.
So... Next, I tried to add some xorriso isohybrid options to the
build, starting with
-isohybrid-gpt-basdat
but that didn't have any noticeable effect on my build. (I don't know
if that's expected!). Next, I bit my tongue and copied more of the
amd64 build, using bits of syslinux to add:
-isohybrid-mbr syslinux/usr/lib/syslinux/isohdpfx.bin
and that makes a big difference - I then ended up with the
normal-looking 2-partition image and d-i awas happy with
this.
So... Much as this image seems to work for me, it's bloody silly to be
using bits out of syslinux for an arm64 image! Thomas: what exactly
does xorriso need out of isohdpfx.bin to be able to make a *non* x86
bootable MBR etc. please? I'm *guessing* we just need a basic MBR-ony
boot sector that xorriso can modify with a partition table, but I
don't really know this area all that well. Can you give me some clues
please? :-)
--
Steve McIntyre, Cambridge, UK. st...@einval.com
"C++ ate my sanity" -- Jon Rabone
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/20150128230...@einval.com
Thomas Schmitt
Jan 29, 2015, 5:50:03 AM1/29/15
to
Hi,
i wonder why my mail of Thu, 29 Jan 2015 08:14:08 +0100
does not show up in debian-cd mailing list. It reported about
a preliminary experiment with amd64 mini.iso.
Meanwhile it is quite outdated by my new experiments with
an arm64 ISO.
-------------------------------------------------------------
I downloaded
http://cloudfront.debian.net/cdimage/jessie_di_beta_2/arm64/iso-cd/debian-jessie-DI-b2-arm64-netinst.iso
of 2014-10-03.
Inspection yields:
Volume id : 'Debian jessie-DI-b2 arm64 1'
El Torito catalog : 832 1
El Torito cat path : /boot.catalog
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 UEFI y none 0x0000 0x00 768 833
El Torito img path : 1 /boot/grub/efi.img
xorriso : NOTE : No System Area was loaded
This looks like amd64 mini.iso without the BIOS stuff.
After reading its /.disk/mkisofs, i re-pack it by
# A dummy MBR template as substitute for isohdpfx.bin
dd if=/dev/zero bs=432 count=1 of=null.mbr
mount -o loop debian-jessie-DI-b2-arm64-netinst.iso /mnt/iso
xorriso -as mkisofs \
-V 'Debian jessie-DI-b2 arm64 1' \
-r -o test.iso -J -joliet-long -cache-inodes \
-isohybrid-mbr null.mbr \
-e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat \
/mnt/iso
Omitted options:
all Jigdo options
-eltorito-alt-boot is a separator which is needed only if
already a boot image was defined by -b, -e,
or alike
Added options:
-isohybrid-gpt-basdat works only if -isohybrid-mbr is present
-isohybrid-mbr gets as input the dummy MBR template. So SYSLINUX
is not needed.
The result shows nested partitions in MBR and GPT.
This is the mjg layout, which partition editors dislike heavily
but seems to work well in the amd64 netinst ISOs.
It offers three entry points for booting: El Torito, MBR, GPT.
------------------------------------------------------------------------
El Torito catalog : 832 1
El Torito cat path : /boot.catalog
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 UEFI y none 0x0000 0x00 768 833
El Torito img path : 1 /boot/grub/efi.img
System area options: 0x00000900
System area summary: MBR cyl-align-on GPT
ISO image size/512 : 262144
Partition offset : 0
MBR heads per cyl : 64
MBR secs per head : 32
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x80 0x00 0 262144
MBR partition : 2 0x00 0xef 3332 768
MBR partition path : 2 /boot/grub/efi.img
GPT : N Info
GPT disk GUID : 8822d6a0aadcde40a8afcd569dc28802
GPT entry array : 2 248 overlapping
GPT lba range : 64 262080 262143
GPT partition name : 1 490053004f00480079006200720069006400
GPT partname local : 1 ISOHybrid
GPT partition GUID : 1 8822d6a0aadcde40a8adcd569dc28802
GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags: 1 0x1000000000000001
GPT start and size : 1 0 262080
GPT partition name : 2 490053004f004800790062007200690064003100
GPT partname local : 2 ISOHybrid1
GPT partition GUID : 2 8822d6a0aadcde40a8accd569dc28802
GPT type GUID : 2 a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags: 2 0x1000000000000001
GPT start and size : 2 3332 768
GPT partition path : 2 /boot/grub/efi.img
------------------------------------------------------------------------
Of course it is odd to use ISOLINUX related xorriso commands
with pure GRUB2 boot equipment. Especially since Vladimir
Serbinenko puts much emphasis on a neat partition table.
Let's try an option which was introduced for grub-mkrescue
xorriso -as mkisofs \
-V 'Debian jessie-DI-b2 arm64 1' \
-r -o test.iso -J -joliet-long -cache-inodes \
-efi-boot-part --efi-boot-image \
-e boot/grub/efi.img -no-emul-boot \
/mnt/iso
Added options:
-efi-boot-part with special argument "--efi-boot-image"
marks the first EFI El Torito boot image as
partition in GPT.
Only a "protective MBR" emerges, which complies
to GPT specs. (Other than a multi-partition MBR.)
This yields a more conventional partition layout.
The range of the ISO filesystem is protected by the MBR partition and
by three GPT partitions, of which the middle one points to the EFI
boot filesystem in /boot/grub/efi.img.
Only two boot entry points are provided: El Torito and GPT.
------------------------------------------------------------------------
El Torito catalog : 1024 1
El Torito cat path : /boot.catalog
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 UEFI y none 0x0000 0x00 768 831
El Torito img path : 1 /boot/grub/efi.img
System area options: 0x00000201
System area summary: MBR protective-msdos-label cyl-align-off GPT
ISO image size/512 : 260484
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 260483
GPT : N Info
GPT disk GUID : 307e73f26c8c7b4a9dd739bd9e5991fe
GPT entry array : 2 248 separated
GPT lba range : 64 260420 260483
GPT partition name : 1 4700610070003000
GPT partname local : 1 Gap0
GPT partition GUID : 1 307e73f26c8c7b4a9dd439bd9e5991fe
GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags: 1 0x1000000000000001
GPT start and size : 1 64 3260
GPT partition name : 2 450046004900200062006f006f007400200070006100720074006900740069006f006e00
GPT partname local : 2 EFI boot partition
GPT partition GUID : 2 307e73f26c8c7b4a9dd539bd9e5991fe
GPT type GUID : 2 28732ac11ff8d211ba4b00a0c93ec93b
GPT partition flags: 2 0x1000000000000001
GPT start and size : 2 3324 768
GPT partition path : 2 /boot/grub/efi.img
GPT partition name : 3 4700610070003100
GPT partname local : 3 Gap1
GPT partition GUID : 3 307e73f26c8c7b4a9dd639bd9e5991fe
GPT type GUID : 3 a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags: 3 0x1000000000000001
GPT start and size : 3 4092 256328
------------------------------------------------------------------------
One should consider to use grub-mkrescue for pure GRUB2
boot equipment. It is well coordinated with GRUB2 but rarely
seen as producer of distro ISOs.
Regrettably there is a small unintended CLI compatibility problem
between the old bash script and the new C program:
- The script needs argument "--" only to throw xorriso out of
its mkisofs emulation. (There is few reason to do this.)
- The C program needs argument "--" to end its own option list
and to start the list of additional xorriso -as mkisofs options.
(A second "--" would end mkisofs emulation of xorriso.)
The list of additional options would contain all xorriso options
which do not directly deal with boot aspects or the output ISO
path.
I.e. the many Jigdo options, -r -V -J -joliet-long -cache-inodes CD1.
But not -o ... -eltorito-alt-boot -e boot/grub/efi.img -no-emul-boot
Depending on its content, "boot1" may be needed or not. All boot
files up to the start of the Linux kernel are produced by
grub-mkrescue.
Vladimir stated that the CLI change was unintentional.
But he did not yet decide whether to fix it by a proposal of
Andrei Borzenkov, or by a proposal of mine, or by some other
idea. See:
http://lists.gnu.org/archive/html/grub-devel/2014-11/msg00076.html
http://lists.gnu.org/archive/html/grub-devel/2014-11/msg00082.html
http://lists.gnu.org/archive/html/grub-devel/2014-11/msg00083.html
which are late follow-ups of
http://lists.gnu.org/archive/html/grub-devel/2014-09/msg00067.html
(Maybe if users show up and encourage a swift decision ...)
Well, the user just has to know which grub-mkrescue variant is
at hand and thus insert the "--" argument or not.
Either grub-mkrescue or xorriso will protest loudly if the
wrong variant was assumed.
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/2091254415...@scdbackup.webframe.org
i wonder why my mail of Thu, 29 Jan 2015 08:14:08 +0100
does not show up in debian-cd mailing list. It reported about
a preliminary experiment with amd64 mini.iso.
Meanwhile it is quite outdated by my new experiments with
an arm64 ISO.
-------------------------------------------------------------
I downloaded
http://cloudfront.debian.net/cdimage/jessie_di_beta_2/arm64/iso-cd/debian-jessie-DI-b2-arm64-netinst.iso
of 2014-10-03.
Inspection yields:
Volume id : 'Debian jessie-DI-b2 arm64 1'
El Torito catalog : 832 1
El Torito cat path : /boot.catalog
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 UEFI y none 0x0000 0x00 768 833
El Torito img path : 1 /boot/grub/efi.img
xorriso : NOTE : No System Area was loaded
This looks like amd64 mini.iso without the BIOS stuff.
After reading its /.disk/mkisofs, i re-pack it by
# A dummy MBR template as substitute for isohdpfx.bin
dd if=/dev/zero bs=432 count=1 of=null.mbr
mount -o loop debian-jessie-DI-b2-arm64-netinst.iso /mnt/iso
xorriso -as mkisofs \
-V 'Debian jessie-DI-b2 arm64 1' \
-r -o test.iso -J -joliet-long -cache-inodes \
-isohybrid-mbr null.mbr \
-e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat \
/mnt/iso
Omitted options:
all Jigdo options
-eltorito-alt-boot is a separator which is needed only if
already a boot image was defined by -b, -e,
or alike
Added options:
-isohybrid-gpt-basdat works only if -isohybrid-mbr is present
-isohybrid-mbr gets as input the dummy MBR template. So SYSLINUX
is not needed.
The result shows nested partitions in MBR and GPT.
This is the mjg layout, which partition editors dislike heavily
but seems to work well in the amd64 netinst ISOs.
It offers three entry points for booting: El Torito, MBR, GPT.
------------------------------------------------------------------------
El Torito catalog : 832 1
El Torito cat path : /boot.catalog
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 UEFI y none 0x0000 0x00 768 833
El Torito img path : 1 /boot/grub/efi.img
System area options: 0x00000900
System area summary: MBR cyl-align-on GPT
ISO image size/512 : 262144
Partition offset : 0
MBR heads per cyl : 64
MBR secs per head : 32
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x80 0x00 0 262144
MBR partition : 2 0x00 0xef 3332 768
MBR partition path : 2 /boot/grub/efi.img
GPT : N Info
GPT disk GUID : 8822d6a0aadcde40a8afcd569dc28802
GPT entry array : 2 248 overlapping
GPT lba range : 64 262080 262143
GPT partition name : 1 490053004f00480079006200720069006400
GPT partname local : 1 ISOHybrid
GPT partition GUID : 1 8822d6a0aadcde40a8adcd569dc28802
GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags: 1 0x1000000000000001
GPT start and size : 1 0 262080
GPT partition name : 2 490053004f004800790062007200690064003100
GPT partname local : 2 ISOHybrid1
GPT partition GUID : 2 8822d6a0aadcde40a8accd569dc28802
GPT type GUID : 2 a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags: 2 0x1000000000000001
GPT start and size : 2 3332 768
GPT partition path : 2 /boot/grub/efi.img
------------------------------------------------------------------------
Of course it is odd to use ISOLINUX related xorriso commands
with pure GRUB2 boot equipment. Especially since Vladimir
Serbinenko puts much emphasis on a neat partition table.
Let's try an option which was introduced for grub-mkrescue
xorriso -as mkisofs \
-V 'Debian jessie-DI-b2 arm64 1' \
-r -o test.iso -J -joliet-long -cache-inodes \
-efi-boot-part --efi-boot-image \
-e boot/grub/efi.img -no-emul-boot \
/mnt/iso
Added options:
-efi-boot-part with special argument "--efi-boot-image"
marks the first EFI El Torito boot image as
partition in GPT.
Only a "protective MBR" emerges, which complies
to GPT specs. (Other than a multi-partition MBR.)
This yields a more conventional partition layout.
The range of the ISO filesystem is protected by the MBR partition and
by three GPT partitions, of which the middle one points to the EFI
boot filesystem in /boot/grub/efi.img.
Only two boot entry points are provided: El Torito and GPT.
------------------------------------------------------------------------
El Torito catalog : 1024 1
El Torito cat path : /boot.catalog
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 UEFI y none 0x0000 0x00 768 831
El Torito img path : 1 /boot/grub/efi.img
System area options: 0x00000201
System area summary: MBR protective-msdos-label cyl-align-off GPT
ISO image size/512 : 260484
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 260483
GPT : N Info
GPT disk GUID : 307e73f26c8c7b4a9dd739bd9e5991fe
GPT entry array : 2 248 separated
GPT lba range : 64 260420 260483
GPT partition name : 1 4700610070003000
GPT partname local : 1 Gap0
GPT partition GUID : 1 307e73f26c8c7b4a9dd439bd9e5991fe
GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags: 1 0x1000000000000001
GPT start and size : 1 64 3260
GPT partition name : 2 450046004900200062006f006f007400200070006100720074006900740069006f006e00
GPT partname local : 2 EFI boot partition
GPT partition GUID : 2 307e73f26c8c7b4a9dd539bd9e5991fe
GPT type GUID : 2 28732ac11ff8d211ba4b00a0c93ec93b
GPT partition flags: 2 0x1000000000000001
GPT start and size : 2 3324 768
GPT partition path : 2 /boot/grub/efi.img
GPT partition name : 3 4700610070003100
GPT partname local : 3 Gap1
GPT partition GUID : 3 307e73f26c8c7b4a9dd639bd9e5991fe
GPT type GUID : 3 a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags: 3 0x1000000000000001
GPT start and size : 3 4092 256328
------------------------------------------------------------------------
One should consider to use grub-mkrescue for pure GRUB2
boot equipment. It is well coordinated with GRUB2 but rarely
seen as producer of distro ISOs.
Regrettably there is a small unintended CLI compatibility problem
between the old bash script and the new C program:
- The script needs argument "--" only to throw xorriso out of
its mkisofs emulation. (There is few reason to do this.)
- The C program needs argument "--" to end its own option list
and to start the list of additional xorriso -as mkisofs options.
(A second "--" would end mkisofs emulation of xorriso.)
The list of additional options would contain all xorriso options
which do not directly deal with boot aspects or the output ISO
path.
I.e. the many Jigdo options, -r -V -J -joliet-long -cache-inodes CD1.
But not -o ... -eltorito-alt-boot -e boot/grub/efi.img -no-emul-boot
Depending on its content, "boot1" may be needed or not. All boot
files up to the start of the Linux kernel are produced by
grub-mkrescue.
Vladimir stated that the CLI change was unintentional.
But he did not yet decide whether to fix it by a proposal of
Andrei Borzenkov, or by a proposal of mine, or by some other
idea. See:
http://lists.gnu.org/archive/html/grub-devel/2014-11/msg00076.html
http://lists.gnu.org/archive/html/grub-devel/2014-11/msg00082.html
http://lists.gnu.org/archive/html/grub-devel/2014-11/msg00083.html
which are late follow-ups of
http://lists.gnu.org/archive/html/grub-devel/2014-09/msg00067.html
(Maybe if users show up and encourage a swift decision ...)
Well, the user just has to know which grub-mkrescue variant is
at hand and thus insert the "--" argument or not.
Either grub-mkrescue or xorriso will protest loudly if the
wrong variant was assumed.
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steve McIntyre
Jan 31, 2015, 5:30:02 AM1/31/15
to
On Thu, Jan 29, 2015 at 11:41:57AM +0100, Thomas Schmitt wrote:
>Hi,
Hi Thomas!
>i wonder why my mail of Thu, 29 Jan 2015 08:14:08 +0100
>does not show up in debian-cd mailing list. It reported about
>a preliminary experiment with amd64 mini.iso.
Easy; you just sent it to me directly, not to the list(s)... :-)
>Meanwhile it is quite outdated by my new experiments with
>an arm64 ISO.
>
>-------------------------------------------------------------
>
>I downloaded
> http://cloudfront.debian.net/cdimage/jessie_di_beta_2/arm64/iso-cd/debian-jessie-DI-b2-arm64-netinst.iso
>of 2014-10-03.
>
>Inspection yields:
>
> Volume id : 'Debian jessie-DI-b2 arm64 1'
> El Torito catalog : 832 1
> El Torito cat path : /boot.catalog
> El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
> El Torito boot img : 1 UEFI y none 0x0000 0x00 768 833
> El Torito img path : 1 /boot/grub/efi.img
> xorriso : NOTE : No System Area was loaded
>
>This looks like amd64 mini.iso without the BIOS stuff.
That's as we'd expect, yes. We support arm64 booting off CD/USB via
UEFI; there's nothing like the BIOS boot.
>After reading its /.disk/mkisofs, i re-pack it by
>
> # A dummy MBR template as substitute for isohdpfx.bin
> dd if=/dev/zero bs=432 count=1 of=null.mbr
>
> mount -o loop debian-jessie-DI-b2-arm64-netinst.iso /mnt/iso
>
> xorriso -as mkisofs \
> -V 'Debian jessie-DI-b2 arm64 1' \
> -r -o test.iso -J -joliet-long -cache-inodes \
> -isohybrid-mbr null.mbr \
> -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat \
> /mnt/iso
>
>Omitted options:
> all Jigdo options
> -eltorito-alt-boot is a separator which is needed only if
> already a boot image was defined by -b, -e,
> or alike
>
>Added options:
> -isohybrid-gpt-basdat works only if -isohybrid-mbr is present
> -isohybrid-mbr gets as input the dummy MBR template. So SYSLINUX
> is not needed.
OK.
Right.
>Of course it is odd to use ISOLINUX related xorriso commands
>with pure GRUB2 boot equipment. Especially since Vladimir
>Serbinenko puts much emphasis on a neat partition table.
>
>Let's try an option which was introduced for grub-mkrescue
>
> xorriso -as mkisofs \
> -V 'Debian jessie-DI-b2 arm64 1' \
> -r -o test.iso -J -joliet-long -cache-inodes \
> -efi-boot-part --efi-boot-image \
> -e boot/grub/efi.img -no-emul-boot \
> /mnt/iso
>
>Added options:
> -efi-boot-part with special argument "--efi-boot-image"
> marks the first EFI El Torito boot image as
> partition in GPT.
> Only a "protective MBR" emerges, which complies
> to GPT specs. (Other than a multi-partition MBR.)
Woo. :-)
I understand why - it then makes the scripting very different for some
architectures compared to others, instead of just changing the
particular options needed for boot. That's much harder to track and
keep consistent for us.
For now, I'll add -efi-boot-part and continue testing. Thanks!
I'm also *way* overdue on switching all of debian-cd over to using
xorriso and using native xorriso options totally rather than the
-as-mkisofs stuff equivalents. But that's a topic for another day...
"The problem with defending the purity of the English language is that
English is about as pure as a cribhouse whore. We don't just borrow words; on
occasion, English has pursued other languages down alleyways to beat them
unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/2015013110...@einval.com
>Hi,
Hi Thomas!
>i wonder why my mail of Thu, 29 Jan 2015 08:14:08 +0100
>does not show up in debian-cd mailing list. It reported about
>a preliminary experiment with amd64 mini.iso.
>Meanwhile it is quite outdated by my new experiments with
>an arm64 ISO.
>
>-------------------------------------------------------------
>
>I downloaded
> http://cloudfront.debian.net/cdimage/jessie_di_beta_2/arm64/iso-cd/debian-jessie-DI-b2-arm64-netinst.iso
>of 2014-10-03.
>
>Inspection yields:
>
> Volume id : 'Debian jessie-DI-b2 arm64 1'
> El Torito catalog : 832 1
> El Torito cat path : /boot.catalog
> El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
> El Torito boot img : 1 UEFI y none 0x0000 0x00 768 833
> El Torito img path : 1 /boot/grub/efi.img
> xorriso : NOTE : No System Area was loaded
>
>This looks like amd64 mini.iso without the BIOS stuff.
UEFI; there's nothing like the BIOS boot.
>After reading its /.disk/mkisofs, i re-pack it by
>
> # A dummy MBR template as substitute for isohdpfx.bin
> dd if=/dev/zero bs=432 count=1 of=null.mbr
>
> mount -o loop debian-jessie-DI-b2-arm64-netinst.iso /mnt/iso
>
> xorriso -as mkisofs \
> -V 'Debian jessie-DI-b2 arm64 1' \
> -r -o test.iso -J -joliet-long -cache-inodes \
> -isohybrid-mbr null.mbr \
> -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat \
> /mnt/iso
>
>Omitted options:
> all Jigdo options
> -eltorito-alt-boot is a separator which is needed only if
> already a boot image was defined by -b, -e,
> or alike
>
>Added options:
> -isohybrid-gpt-basdat works only if -isohybrid-mbr is present
> -isohybrid-mbr gets as input the dummy MBR template. So SYSLINUX
> is not needed.
>Of course it is odd to use ISOLINUX related xorriso commands
>with pure GRUB2 boot equipment. Especially since Vladimir
>Serbinenko puts much emphasis on a neat partition table.
>
>Let's try an option which was introduced for grub-mkrescue
>
> xorriso -as mkisofs \
> -V 'Debian jessie-DI-b2 arm64 1' \
> -r -o test.iso -J -joliet-long -cache-inodes \
> -efi-boot-part --efi-boot-image \
> -e boot/grub/efi.img -no-emul-boot \
> /mnt/iso
>
>Added options:
> -efi-boot-part with special argument "--efi-boot-image"
> marks the first EFI El Torito boot image as
> partition in GPT.
> Only a "protective MBR" emerges, which complies
> to GPT specs. (Other than a multi-partition MBR.)
architectures compared to others, instead of just changing the
particular options needed for boot. That's much harder to track and
keep consistent for us.
For now, I'll add -efi-boot-part and continue testing. Thanks!
I'm also *way* overdue on switching all of debian-cd over to using
xorriso and using native xorriso options totally rather than the
-as-mkisofs stuff equivalents. But that's a topic for another day...
"The problem with defending the purity of the English language is that
English is about as pure as a cribhouse whore. We don't just borrow words; on
occasion, English has pursued other languages down alleyways to beat them
unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Schmitt
Jan 31, 2015, 7:30:02 AM1/31/15
to
Hi,
Steve McIntyre:
when testing the new feature to generate commands from the
analyzed boot equipment of ISOs.
The -as mkisofs command is an offcial part of xorriso.
You may well stay with it as long as there are no demands
which cannot be fulfilled with its option interface.
(E.g. it is not very suitable for multi-session and
allows few file manipulations inside the ISO.)
One may question the beauty of
-boot_image any efi_boot_part=--efi-boot-image
-boot_image any cat_path='/boot.catalog'
-boot_image any efi_path='/boot/grub/efi.img'
relative to
-efi-boot-part --efi-boot-image
-c '/boot.catalog'
-e '/boot/grub/efi.img' -no-emul-boot
I had few clue of boot equipment when designing the -boot_image
command. It is flexible enough to keep up with new demands.
But it is far from being clear. The first parameter, which was
intended to distinguish boot loaders, is mostly wasted.
Actually i could need a new straighforward language to
describe El Torito and the System Area.
As said, i am working on a feature to tell commands from
ISOs. There are still problems with commands which take
as input data from outside the ISO filesystem.
E.g.: -isohybrid-mbr or -append_partition.
When this feature is completed, then it will be halfways usable
as translator from -as mkisofs options to -boot_image commands.
Just inquire some ISO that was produced by xorriso -as mkisofs.
E.g. an amd64-netinst will yield:
-boot_image isolinux system_area=...what.path.to.use.here.?...
-boot_image isolinux partition_table=on
-boot_image any partition_cyl_align=on
-boot_image any partition_offset=0
-boot_image any partition_hd_cyl=64
-boot_image any partition_sec_hd=32
-boot_image any apm_block_size=2048
-boot_image any cat_path='/isolinux/boot.cat'
-boot_image isolinux bin_path='/isolinux/isolinux.bin'
-boot_image any platform_id=0x00
-boot_image any emul_type=no_emulation
-boot_image any load_size=2048
-boot_image any boot_info_table=on
-boot_image any next
-boot_image any efi_path='/boot/grub/efi.img'
-boot_image any platform_id=0xef
-boot_image any emul_type=no_emulation
-boot_image any load_size=458752
-boot_image isolinux partition_entry=gpt_basdat
-boot_image isolinux partition_entry=apm_hfsplus
This will still not be a no-brainer. One has to check
each command whether one wants to fixely set its parameter
or rather depend on xorriso defaults.
E.g. the load_size=458752 is actually the size of efi.img
and thus variable. So one better omits that command and
lets xorriso use the data file size.
On the other hand load_size=2048 is an important fixed
parameter for ISOLINUX BIOS boot images. It corresponds to
-as mkisofs -boot-load-size 4.
(Ceterum censio partition_entry=apm_hfsplus
is not appropriatum and esse delendam.)
Have a nice day :)
Thomas
Steve McIntyre:
> I'm also *way* overdue on switching all of debian-cd over to using
> xorriso and using native xorriso options totally rather than the
> -as-mkisofs stuff equivalents. But that's a topic for another day...
You will be a trailblazer. Nobody else does this, except me,
> xorriso and using native xorriso options totally rather than the
> -as-mkisofs stuff equivalents. But that's a topic for another day...
when testing the new feature to generate commands from the
analyzed boot equipment of ISOs.
The -as mkisofs command is an offcial part of xorriso.
You may well stay with it as long as there are no demands
which cannot be fulfilled with its option interface.
(E.g. it is not very suitable for multi-session and
allows few file manipulations inside the ISO.)
One may question the beauty of
-boot_image any efi_boot_part=--efi-boot-image
-boot_image any cat_path='/boot.catalog'
-boot_image any efi_path='/boot/grub/efi.img'
relative to
-efi-boot-part --efi-boot-image
-c '/boot.catalog'
-e '/boot/grub/efi.img' -no-emul-boot
I had few clue of boot equipment when designing the -boot_image
command. It is flexible enough to keep up with new demands.
But it is far from being clear. The first parameter, which was
intended to distinguish boot loaders, is mostly wasted.
Actually i could need a new straighforward language to
describe El Torito and the System Area.
As said, i am working on a feature to tell commands from
ISOs. There are still problems with commands which take
as input data from outside the ISO filesystem.
E.g.: -isohybrid-mbr or -append_partition.
When this feature is completed, then it will be halfways usable
as translator from -as mkisofs options to -boot_image commands.
Just inquire some ISO that was produced by xorriso -as mkisofs.
E.g. an amd64-netinst will yield:
-boot_image isolinux system_area=...what.path.to.use.here.?...
-boot_image isolinux partition_table=on
-boot_image any partition_cyl_align=on
-boot_image any partition_offset=0
-boot_image any partition_hd_cyl=64
-boot_image any partition_sec_hd=32
-boot_image any apm_block_size=2048
-boot_image any cat_path='/isolinux/boot.cat'
-boot_image isolinux bin_path='/isolinux/isolinux.bin'
-boot_image any platform_id=0x00
-boot_image any emul_type=no_emulation
-boot_image any load_size=2048
-boot_image any boot_info_table=on
-boot_image any next
-boot_image any efi_path='/boot/grub/efi.img'
-boot_image any platform_id=0xef
-boot_image any emul_type=no_emulation
-boot_image any load_size=458752
-boot_image isolinux partition_entry=gpt_basdat
-boot_image isolinux partition_entry=apm_hfsplus
This will still not be a no-brainer. One has to check
each command whether one wants to fixely set its parameter
or rather depend on xorriso defaults.
E.g. the load_size=458752 is actually the size of efi.img
and thus variable. So one better omits that command and
lets xorriso use the data file size.
On the other hand load_size=2048 is an important fixed
parameter for ISOLINUX BIOS boot images. It corresponds to
-as mkisofs -boot-load-size 4.
(Ceterum censio partition_entry=apm_hfsplus
is not appropriatum and esse delendam.)
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/2106254381...@scdbackup.webframe.org
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steve McIntyre
Jan 31, 2015, 10:20:03 AM1/31/15
to
On Sat, Jan 31, 2015 at 01:24:39PM +0100, Thomas Schmitt wrote:
>Hi,
>
>Steve McIntyre:
>> I'm also *way* overdue on switching all of debian-cd over to using
>> xorriso and using native xorriso options totally rather than the
>> -as-mkisofs stuff equivalents. But that's a topic for another day...
>
>You will be a trailblazer. Nobody else does this, except me,
>when testing the new feature to generate commands from the
>analyzed boot equipment of ISOs.
>
>The -as mkisofs command is an offcial part of xorriso.
>You may well stay with it as long as there are no demands
>which cannot be fulfilled with its option interface.
>(E.g. it is not very suitable for multi-session and
> allows few file manipulations inside the ISO.)
>
>One may question the beauty of
>
>-boot_image any efi_boot_part=--efi-boot-image
>-boot_image any cat_path='/boot.catalog'
>-boot_image any efi_path='/boot/grub/efi.img'
>
>relative to
>
>-efi-boot-part --efi-boot-image
>-c '/boot.catalog'
>-e '/boot/grub/efi.img' -no-emul-boot
*grin* You're not selling this very much... :-)
>Hi,
>
>Steve McIntyre:
>> I'm also *way* overdue on switching all of debian-cd over to using
>> xorriso and using native xorriso options totally rather than the
>> -as-mkisofs stuff equivalents. But that's a topic for another day...
>
>You will be a trailblazer. Nobody else does this, except me,
>when testing the new feature to generate commands from the
>analyzed boot equipment of ISOs.
>
>The -as mkisofs command is an offcial part of xorriso.
>You may well stay with it as long as there are no demands
>which cannot be fulfilled with its option interface.
>(E.g. it is not very suitable for multi-session and
> allows few file manipulations inside the ISO.)
>
>One may question the beauty of
>
>-boot_image any efi_boot_part=--efi-boot-image
>-boot_image any cat_path='/boot.catalog'
>-boot_image any efi_path='/boot/grub/efi.img'
>
>relative to
>
>-efi-boot-part --efi-boot-image
>-c '/boot.catalog'
>-e '/boot/grub/efi.img' -no-emul-boot
< sladen> I actually stayed in a hotel and arrived to find a post-it
note stuck to the mini-bar saying "Paul: This fridge and
fittings are the correct way around and do not need altering"
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Schmitt
Jan 31, 2015, 1:10:02 PM1/31/15
to
Hi,
> *grin* You're not selling this very much... :-)
Do you complain about losing an item from your todo list ?
How about you replace it by the intent to fix bug 776317:
amd64 mini.iso : BIOS or EFI boot from CD or USB stick,
with the complication to keep the firmware partition
digestible for partition editors.
I am preparing a conclusion post with lengthy considerations,
xorriso novelties, and proposals. An excellent candidate for
being way behind with deciding and implementing it.
(It will pass through this list. Bystanders be warned.)
Have a nice day :)
Thomas
> *grin* You're not selling this very much... :-)
How about you replace it by the intent to fix bug 776317:
amd64 mini.iso : BIOS or EFI boot from CD or USB stick,
with the complication to keep the firmware partition
digestible for partition editors.
I am preparing a conclusion post with lengthy considerations,
xorriso novelties, and proposals. An excellent candidate for
being way behind with deciding and implementing it.
(It will pass through this list. Bystanders be warned.)
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/360454369...@scdbackup.webframe.org
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steve McIntyre
Feb 1, 2015, 10:30:02 AM2/1/15
to
On Sat, Jan 31, 2015 at 06:59:44PM +0100, Thomas Schmitt wrote:
>Hi,
>
>> *grin* You're not selling this very much... :-)
>
>Do you complain about losing an item from your todo list ?
Certainly not. :-)
>Hi,
>
>> *grin* You're not selling this very much... :-)
>
>Do you complain about losing an item from your todo list ?
>How about you replace it by the intent to fix bug 776317:
>amd64 mini.iso : BIOS or EFI boot from CD or USB stick,
>with the complication to keep the firmware partition
>digestible for partition editors.
>
>I am preparing a conclusion post with lengthy considerations,
>xorriso novelties, and proposals. An excellent candidate for
>being way behind with deciding and implementing it.
>(It will pass through this list. Bystanders be warned.)
at FOSDEM) and I see he's responded in that bug# too...
"Further comment on how I feel about IBM will appear once I've worked out
whether they're being malicious or incompetent. Capital letters are forecast."
Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steve McIntyre
Feb 4, 2015, 10:20:04 AM2/4/15
to
On Sat, Jan 31, 2015 at 10:24:17AM +0000, Steve McIntyre wrote:
>On Thu, Jan 29, 2015 at 11:41:57AM +0100, Thomas Schmitt wrote:
>>
>>After reading its /.disk/mkisofs, i re-pack it by
>>
>> # A dummy MBR template as substitute for isohdpfx.bin
>> dd if=/dev/zero bs=432 count=1 of=null.mbr
>>
>> mount -o loop debian-jessie-DI-b2-arm64-netinst.iso /mnt/iso
>>
>> xorriso -as mkisofs \
>> -V 'Debian jessie-DI-b2 arm64 1' \
>> -r -o test.iso -J -joliet-long -cache-inodes \
>> -isohybrid-mbr null.mbr \
>> -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat \
>> /mnt/iso
>>
>>Omitted options:
>> all Jigdo options
>> -eltorito-alt-boot is a separator which is needed only if
>> already a boot image was defined by -b, -e,
>> or alike
>>
>>Added options:
>> -isohybrid-gpt-basdat works only if -isohybrid-mbr is present
>> -isohybrid-mbr gets as input the dummy MBR template. So SYSLINUX
>> is not needed.
>
>OK.
This may look valid, but gdisk and other code I've used don't cope
>On Thu, Jan 29, 2015 at 11:41:57AM +0100, Thomas Schmitt wrote:
>>
>>After reading its /.disk/mkisofs, i re-pack it by
>>
>> # A dummy MBR template as substitute for isohdpfx.bin
>> dd if=/dev/zero bs=432 count=1 of=null.mbr
>>
>> mount -o loop debian-jessie-DI-b2-arm64-netinst.iso /mnt/iso
>>
>> xorriso -as mkisofs \
>> -V 'Debian jessie-DI-b2 arm64 1' \
>> -r -o test.iso -J -joliet-long -cache-inodes \
>> -isohybrid-mbr null.mbr \
>> -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat \
>> /mnt/iso
>>
>>Omitted options:
>> all Jigdo options
>> -eltorito-alt-boot is a separator which is needed only if
>> already a boot image was defined by -b, -e,
>> or alike
>>
>>Added options:
>> -isohybrid-gpt-basdat works only if -isohybrid-mbr is present
>> -isohybrid-mbr gets as input the dummy MBR template. So SYSLINUX
>> is not needed.
>
>OK.
well with the PMBR being broken. I can mount partition 1 fine for the
normal ISO contents, but partition 2 seems broken and I can't mount
it. Maybe an offset bug(?), or things are being too confused by the
GPT-MBR disconnect here.
generating 3 partitions:
Number Start (sector) End (sector) Size Code Name
1 64 3867 1.9 MiB 0700 Gap0
2 3868 4635 384.0 KiB EF00 EFI boot partition
3 4636 365891 176.4 MiB 0700 Gap1
where neither Gap0 nor Gap1 are usable for mounting. I guess I see
what you've done, just slicing up the image to make the EFI boot
partition work. However, this isn't helpful for the Debian installer
which now can't find the rest of the installer on any partition. It's
used to looking for things in a "normal" isohybrid manner where it can
mount the main ISO contents as a partition too. I tried to force the
efi.img file to tne end of the media to make Gap0 functional, but that
doesn't seem to help at all.
Into the distance, a ribbon of black
Stretched to the point of no turning back
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steve McIntyre
Feb 4, 2015, 11:50:02 AM2/4/15
to
it. efi.img is being modified otherwise, it seems?
Is there anybody out there?
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Schmitt
Feb 4, 2015, 12:10:03 PM2/4/15
to
Hi,
> >> -isohybrid-mbr null.mbr \
> >> -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat \
The isohybbrid --gpt layout does not comply to UEF/GPT.
Either there must be a "protective MBR" with a single
partition of type 0xee, reaching from LBA 1 up to the
backup GPT. In that case, GPT represents the partitions,
which must not overlap.
Or there may be a "Legacy MBR" with non-overlapping
partitions of which one needs to have type 0xef and
marks the EFI system partition with the FAT filesystem.
When i plug the USB stick with the resulting image
into my olde Linux, it probably uses the MBR to create
a mountable /dev/sdb2 with efi/boot/bootaa64.efi in it.
Further my Linux tolerates that partition 2 is located
inside partition 1. That's the sin of overlapping.
> >> -efi-boot-part --efi-boot-image \
It complies to UEFI but the ISO can only be mounted by the
base device.
Especially udev and blkid do not handle this well. They happily
let partition 1 inherit the filesystem identification of the
base device.
(On the other hand, who needs udev to find a CD or USB stick
when the freshly booted kernel is the own well known one ?
The list of possible device files is very finite.)
> I guess I see what you've done,
Urm. Blame Vladimir Serbinenko for that layout. He has
good arguments for it. I have questioned it several times
but he always staid firm.
> However, this isn't helpful for the Debian installer
> which now can't find the rest of the installer on any partition.
Depending on udev early ?
Your findings match the reasons why "Legacy MBR" won in my
discussion of mini.iso
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776317#75
The waste of 1 MB for an appended external partition seems
worthwhile.
Stripping down my best proposal from BIOS+EFI to EFI-only:
mount -o loop debian-jessie-DI-b2-arm64-netinst.iso /mnt/iso
# Get a copy of the El Torito EFI system partition
cp /mnt/iso/boot/grub/efi.img arm64-efi.img
# Append that copy as MBR partition of type 0xef
-append_partition 2 0xef arm64-efi.img \
-partition_cyl_align all \
/mnt/iso
This yields a non-overlapping UEFI compliant Legacy MBR
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x00 0x83 0 262144
MBR partition : 2 0x00 0xef 262144 2048
The NUL-bytes in the MBR are no problem because of UEF 2.4 5.2.1
"The boot code on the MBR is not executed by UEFI firmware."
UEFI 2.4, table 13 shows that it needs at least one partition table
entry and the magic 0x55 0xaa at bytes 510 and 511.
The only effect of omitting option -isohybrid is that the type
of partition 1 is 0x83 rather than 0x17.
-------------------------------------------------------------
I am still hunting a bug in the pending changeset to enable
production of a UEFI compliant protective MBR plus GPT
layout with -append_partition. This would be the second best
proposal from bug=776317#75.
Disadvantages in comparison to above winner:
You get a mountable ISO partition only if you use
-partition_offset 16
The backup GPT makes mini.iso production postprocessing
cumbersome. (This might be no problem with netinst.iso
because no postprocessing shall happen in debian-cd anyway.)
This proposal will look like the above one, with additional
novel option -appended_part_as_gpt and partition offset 16:
xorriso-1.3.9 -as mkisofs \
-append_partition 2 0xef arm64-efi.img \
-appended_part_as_gpt \
-partition_offset 16 \
/mnt/iso
will yield:
ISO image size/512 : 264192
...
GPT : N Info
GPT disk GUID : 95a21034fca5864bbf6738ff7f0c9a04
GPT partition name : 1 490053004f003900360036003000
GPT partname local : 1 ISO9660
GPT partition GUID : 1 95a21034fca5864bbf6438ff7f0c9a04
GPT partition name : 2 41007000700065006e006400650064003200
GPT partname local : 2 Appended2
GPT partition GUID : 2 95a21034fca5864bbf6538ff7f0c9a04
GPT start and size : 2 264192 768
The bug i'm hunting does not affect the production of
this ISO. So i can make one for you for testing, if you
give me an opportunity to upload it somewhere. 130 MB.
Have a nice day :)
Thomas
> >> -isohybrid-mbr null.mbr \
> >> -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat \
> This may look valid, but gdisk and other code I've used don't cope
> well with the PMBR being broken.
But that's not the fault of the NUL-bytes in null.mbr.
> well with the PMBR being broken.
The isohybbrid --gpt layout does not comply to UEF/GPT.
Either there must be a "protective MBR" with a single
partition of type 0xee, reaching from LBA 1 up to the
backup GPT. In that case, GPT represents the partitions,
which must not overlap.
Or there may be a "Legacy MBR" with non-overlapping
partitions of which one needs to have type 0xef and
marks the EFI system partition with the FAT filesystem.
When i plug the USB stick with the resulting image
into my olde Linux, it probably uses the MBR to create
a mountable /dev/sdb2 with efi/boot/bootaa64.efi in it.
Further my Linux tolerates that partition 2 is located
inside partition 1. That's the sin of overlapping.
> >> -efi-boot-part --efi-boot-image \
> neither Gap0 nor Gap1 are usable
That's a known disadvantage of grub-mkrescue partition layout.
It complies to UEFI but the ISO can only be mounted by the
base device.
Especially udev and blkid do not handle this well. They happily
let partition 1 inherit the filesystem identification of the
base device.
(On the other hand, who needs udev to find a CD or USB stick
when the freshly booted kernel is the own well known one ?
The list of possible device files is very finite.)
> I guess I see what you've done,
good arguments for it. I have questioned it several times
but he always staid firm.
> However, this isn't helpful for the Debian installer
> which now can't find the rest of the installer on any partition.
Your findings match the reasons why "Legacy MBR" won in my
discussion of mini.iso
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776317#75
The waste of 1 MB for an appended external partition seems
worthwhile.
Stripping down my best proposal from BIOS+EFI to EFI-only:
mount -o loop debian-jessie-DI-b2-arm64-netinst.iso /mnt/iso
cp /mnt/iso/boot/grub/efi.img arm64-efi.img
# Append that copy as MBR partition of type 0xef
xorriso -as mkisofs \
-V 'Debian jessie-DI-b2 arm64 1' \
-r -o test.iso -J -joliet-long -cache-inodes \
-e boot/grub/efi.img -no-emul-boot \
-V 'Debian jessie-DI-b2 arm64 1' \
-r -o test.iso -J -joliet-long -cache-inodes \
-append_partition 2 0xef arm64-efi.img \
-partition_cyl_align all \
/mnt/iso
This yields a non-overlapping UEFI compliant Legacy MBR
MBR partition table: N Status Type Start Blocks
MBR partition : 2 0x00 0xef 262144 2048
The NUL-bytes in the MBR are no problem because of UEF 2.4 5.2.1
"The boot code on the MBR is not executed by UEFI firmware."
UEFI 2.4, table 13 shows that it needs at least one partition table
entry and the magic 0x55 0xaa at bytes 510 and 511.
The only effect of omitting option -isohybrid is that the type
of partition 1 is 0x83 rather than 0x17.
-------------------------------------------------------------
I am still hunting a bug in the pending changeset to enable
production of a UEFI compliant protective MBR plus GPT
layout with -append_partition. This would be the second best
proposal from bug=776317#75.
Disadvantages in comparison to above winner:
You get a mountable ISO partition only if you use
-partition_offset 16
The backup GPT makes mini.iso production postprocessing
cumbersome. (This might be no problem with netinst.iso
because no postprocessing shall happen in debian-cd anyway.)
This proposal will look like the above one, with additional
novel option -appended_part_as_gpt and partition offset 16:
xorriso-1.3.9 -as mkisofs \
-V 'Debian jessie-DI-b2 arm64 1' \
-r -o test.iso -J -joliet-long -cache-inodes \
-e boot/grub/efi.img -no-emul-boot \
-r -o test.iso -J -joliet-long -cache-inodes \
-append_partition 2 0xef arm64-efi.img \
-appended_part_as_gpt \
-partition_offset 16 \
/mnt/iso
will yield:
ISO image size/512 : 264192
...
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x00 0xee 1 265023
GPT : N Info
GPT disk GUID : 95a21034fca5864bbf6738ff7f0c9a04
GPT entry array : 2 248 separated
GPT lba range : 64 264960 265023
GPT partition name : 1 490053004f003900360036003000
GPT partname local : 1 ISO9660
GPT partition GUID : 1 95a21034fca5864bbf6438ff7f0c9a04
GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags: 1 0x1000000000000001
GPT start and size : 1 64 264128
GPT partition flags: 1 0x1000000000000001
GPT partition name : 2 41007000700065006e006400650064003200
GPT partname local : 2 Appended2
GPT partition GUID : 2 95a21034fca5864bbf6538ff7f0c9a04
GPT type GUID : 2 28732ac11ff8d211ba4b00a0c93ec93b
GPT partition flags: 2 0x0000000000000000
GPT start and size : 2 264192 768
The bug i'm hunting does not affect the production of
this ISO. So i can make one for you for testing, if you
give me an opportunity to upload it somewhere. 130 MB.
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/301595447...@scdbackup.webframe.org
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Schmitt
Feb 4, 2015, 12:30:03 PM2/4/15
to
Hi,
That's surprising. Can you surely switch forth and back
between mounatble and unmountable by this option ?
Option -c just gives the El Torito catalog a file name.
The catalog file is not involved in booting from
USB-stick or in the hard-disk-like partitioning of the image.
> efi.img is being modified otherwise, it seems?
El Torito boot images get modified only if options
-boot-info-table or --grub2-boot-info are present.
You can check this by comparing boot/grub/efi.img of
the ISO with boot/grub/efi.img in the input file tree
on hard disk.
Have a nice day :)
Thomas
That's surprising. Can you surely switch forth and back
between mounatble and unmountable by this option ?
Option -c just gives the El Torito catalog a file name.
The catalog file is not involved in booting from
USB-stick or in the hard-disk-like partitioning of the image.
> efi.img is being modified otherwise, it seems?
-boot-info-table or --grub2-boot-info are present.
You can check this by comparing boot/grub/efi.img of
the ISO with boot/grub/efi.img in the input file tree
on hard disk.
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/2426354470...@scdbackup.webframe.org
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Schmitt
Feb 11, 2015, 10:00:03 AM2/11/15
to
Hi,
Steve McIntyre wrote:
> > partition 2 seems broken and I can't mount it.
Is there any new insight in this mystery ?
If it is reproducible, then my understanding of partitions
is in deep trouble. I'd need to investigate and compare an
ISO with usable partition against one with unusable partition.
-------------------------------------------------------------
Only remotely related:
I found a new compliant partiton layout in the web.
It could avoid the duplication of the EFI partition at the
cost of a second ISO superblock and directory tree, if one
would develop it further.
openSUSE-13.1-NET-x86_64.iso has a mountable ISO filesystem
in MBR partiton 2 and on the base device:
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x00 0xef 280 8192
MBR partition : 2 0x80 0x17 8472 573160
MBR partition path : 1 /boot/x86_64/efi
Both ISO directory trees share most data files in the ISO.
Only their files /boot/x86_64/efi are located in different
content blocks.
If i get it right, then
https://github.com/openSUSE/kiwi/blob/master/modules/KIWIIsoLinux.pm
lets mkisofs produce a first ISO with EFI FAT as first data
file. The head of this ISO is cut off after the content of
the EFI FAT. The rest (rump) of the first ISO is thrown away.
The harvested ISO head is then brought as data file into the
second, final ISO. There it is stored as second file after
the EFI FAT, where partition 1 ends and partition 2 begins.
(It gets hidden from the directory tree in the second ISO,
but that's not really needed for the trick.)
Because both mkisofs runs sort the other data file blocks
to the same sequence, the ISO head gets retransplanted to
an identical copy of its old rump.
So partiton 2 becomes mountable as ISO 9660.
This layout is still as wasteful as xorriso appended partition
plus partition offset 16.
But it should be possible to substitute the duplicate FAT
image file in the second ISO by a missing FAT image file
in the first ISO. The first ISO is only for mounting as
partition 2. The El Torito boot image and FAT partition 1
are needed in the second, outer ISO.
-------------------------------------------------------------
Have a nice day :)
Thomas
Steve McIntyre wrote:
> > partition 2 seems broken and I can't mount it.
If it is reproducible, then my understanding of partitions
is in deep trouble. I'd need to investigate and compare an
ISO with usable partition against one with unusable partition.
-------------------------------------------------------------
Only remotely related:
I found a new compliant partiton layout in the web.
It could avoid the duplication of the EFI partition at the
cost of a second ISO superblock and directory tree, if one
would develop it further.
openSUSE-13.1-NET-x86_64.iso has a mountable ISO filesystem
in MBR partiton 2 and on the base device:
MBR partition table: N Status Type Start Blocks
MBR partition : 2 0x80 0x17 8472 573160
MBR partition path : 1 /boot/x86_64/efi
Both ISO directory trees share most data files in the ISO.
Only their files /boot/x86_64/efi are located in different
content blocks.
If i get it right, then
https://github.com/openSUSE/kiwi/blob/master/modules/KIWIIsoLinux.pm
lets mkisofs produce a first ISO with EFI FAT as first data
file. The head of this ISO is cut off after the content of
the EFI FAT. The rest (rump) of the first ISO is thrown away.
The harvested ISO head is then brought as data file into the
second, final ISO. There it is stored as second file after
the EFI FAT, where partition 1 ends and partition 2 begins.
(It gets hidden from the directory tree in the second ISO,
but that's not really needed for the trick.)
Because both mkisofs runs sort the other data file blocks
to the same sequence, the ISO head gets retransplanted to
an identical copy of its old rump.
So partiton 2 becomes mountable as ISO 9660.
This layout is still as wasteful as xorriso appended partition
plus partition offset 16.
But it should be possible to substitute the duplicate FAT
image file in the second ISO by a missing FAT image file
in the first ISO. The first ISO is only for mounting as
partition 2. The El Torito boot image and FAT partition 1
are needed in the second, outer ISO.
-------------------------------------------------------------
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/2539154514...@scdbackup.webframe.org
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steve McIntyre
Feb 19, 2015, 10:40:03 PM2/19/15
to
On Wed, Feb 11, 2015 at 03:48:07PM +0100, Thomas Schmitt wrote:
>Hi,
>
>Steve McIntyre wrote:
>> > partition 2 seems broken and I can't mount it.
>> If I specify "-c isolinux/boot.cat" too, that fixes it.
>
>Is there any new insight in this mystery ?
Hi Thomas,
>Hi,
>
>Steve McIntyre wrote:
>> > partition 2 seems broken and I can't mount it.
>> If I specify "-c isolinux/boot.cat" too, that fixes it.
>
>Is there any new insight in this mystery ?
Apologies, no - I've been busy at a conference for a week and now I'm
away on vacation down in Australia for several weeks. If I try to
spend any time hacking on this stuff on holiday, my wife will hurt
me... :-)
I'll carry on looking when I'm back...
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steve McIntyre
Apr 14, 2015, 10:00:03 AM4/14/15
to
Hi Thomas!
I said I'd get back to you *ages* ago. Sorry. :-/
On Wed, Feb 04, 2015 at 06:06:45PM +0100, Thomas Schmitt wrote:
>Hi,
>
>> >> -isohybrid-mbr null.mbr \
>> >> -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat \
>> This may look valid, but gdisk and other code I've used don't cope
>> well with the PMBR being broken.
>
>But that's not the fault of the NUL-bytes in null.mbr.
>The isohybbrid --gpt layout does not comply to UEF/GPT.
>Either there must be a "protective MBR" with a single
>partition of type 0xee, reaching from LBA 1 up to the
>backup GPT. In that case, GPT represents the partitions,
>which must not overlap.
Right.
>Or there may be a "Legacy MBR" with non-overlapping
>partitions of which one needs to have type 0xef and
>marks the EFI system partition with the FAT filesystem.
OK.
>When i plug the USB stick with the resulting image
>into my olde Linux, it probably uses the MBR to create
>a mountable /dev/sdb2 with efi/boot/bootaa64.efi in it.
>Further my Linux tolerates that partition 2 is located
>inside partition 1. That's the sin of overlapping.
>
>> >> -efi-boot-part --efi-boot-image \
>> neither Gap0 nor Gap1 are usable
>
>That's a known disadvantage of grub-mkrescue partition layout.
>It complies to UEFI but the ISO can only be mounted by the
>base device.
>Especially udev and blkid do not handle this well. They happily
>let partition 1 inherit the filesystem identification of the
>base device.
Yup. I think that may be the problem I'm seeing in fact - we're using
blkid etc. in debian-installer.
>(On the other hand, who needs udev to find a CD or USB stick
> when the freshly booted kernel is the own well known one ?
> The list of possible device files is very finite.)
>
>> I guess I see what you've done,
>
>Urm. Blame Vladimir Serbinenko for that layout. He has
>good arguments for it. I have questioned it several times
>but he always staid firm.
:-/
>> However, this isn't helpful for the Debian installer
>> which now can't find the rest of the installer on any partition.
>
>Depending on udev early ?
>
>Your findings match the reasons why "Legacy MBR" won in my
>discussion of mini.iso
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776317#75
>The waste of 1 MB for an appended external partition seems
>worthwhile.
Right, I don't think it's a major problem.
>Stripping down my best proposal from BIOS+EFI to EFI-only:
>
> mount -o loop debian-jessie-DI-b2-arm64-netinst.iso /mnt/iso
>
> # Get a copy of the El Torito EFI system partition
> cp /mnt/iso/boot/grub/efi.img arm64-efi.img
>
> # Append that copy as MBR partition of type 0xef
> xorriso -as mkisofs \
> -V 'Debian jessie-DI-b2 arm64 1' \
> -r -o test.iso -J -joliet-long -cache-inodes \
> -e boot/grub/efi.img -no-emul-boot \
> -append_partition 2 0xef arm64-efi.img \
> -partition_cyl_align all \
> /mnt/iso
>
>This yields a non-overlapping UEFI compliant Legacy MBR
>
> MBR partition table: N Status Type Start Blocks
> MBR partition : 1 0x00 0x83 0 262144
> MBR partition : 2 0x00 0xef 262144 2048
>
>The NUL-bytes in the MBR are no problem because of UEF 2.4 5.2.1
>"The boot code on the MBR is not executed by UEFI firmware."
>UEFI 2.4, table 13 shows that it needs at least one partition table
>entry and the magic 0x55 0xaa at bytes 510 and 511.
>
>The only effect of omitting option -isohybrid is that the type
>of partition 1 is 0x83 rather than 0x17.
Right. I honestly don't think that's an issue to worry about.
>-------------------------------------------------------------
>
>I am still hunting a bug in the pending changeset to enable
>production of a UEFI compliant protective MBR plus GPT
>layout with -append_partition. This would be the second best
>proposal from bug=776317#75.
>
>Disadvantages in comparison to above winner:
>You get a mountable ISO partition only if you use
> -partition_offset 16
>The backup GPT makes mini.iso production postprocessing
>cumbersome. (This might be no problem with netinst.iso
>because no postprocessing shall happen in debian-cd anyway.)
Maybe not by us directly, but I think a fair number of Debian users
like the ability to extend/modify images later and we have docs
telling them how to add partitions once an image is written to a USB
stick, for example.
Right. If you're still working on this I'd be very interested in
testing it!
Armed with "Valor": "Centurion" represents quality of Discipline,
Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
concord the digital world while feeling safe and proud.
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/20150414135...@einval.com
I said I'd get back to you *ages* ago. Sorry. :-/
On Wed, Feb 04, 2015 at 06:06:45PM +0100, Thomas Schmitt wrote:
>Hi,
>
>> >> -isohybrid-mbr null.mbr \
>> >> -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat \
>> This may look valid, but gdisk and other code I've used don't cope
>> well with the PMBR being broken.
>
>But that's not the fault of the NUL-bytes in null.mbr.
>The isohybbrid --gpt layout does not comply to UEF/GPT.
>Either there must be a "protective MBR" with a single
>partition of type 0xee, reaching from LBA 1 up to the
>backup GPT. In that case, GPT represents the partitions,
>which must not overlap.
>Or there may be a "Legacy MBR" with non-overlapping
>partitions of which one needs to have type 0xef and
>marks the EFI system partition with the FAT filesystem.
>When i plug the USB stick with the resulting image
>into my olde Linux, it probably uses the MBR to create
>a mountable /dev/sdb2 with efi/boot/bootaa64.efi in it.
>Further my Linux tolerates that partition 2 is located
>inside partition 1. That's the sin of overlapping.
>
>> >> -efi-boot-part --efi-boot-image \
>> neither Gap0 nor Gap1 are usable
>
>That's a known disadvantage of grub-mkrescue partition layout.
>It complies to UEFI but the ISO can only be mounted by the
>base device.
>Especially udev and blkid do not handle this well. They happily
>let partition 1 inherit the filesystem identification of the
>base device.
blkid etc. in debian-installer.
>(On the other hand, who needs udev to find a CD or USB stick
> when the freshly booted kernel is the own well known one ?
> The list of possible device files is very finite.)
>
>> I guess I see what you've done,
>
>Urm. Blame Vladimir Serbinenko for that layout. He has
>good arguments for it. I have questioned it several times
>but he always staid firm.
>> However, this isn't helpful for the Debian installer
>> which now can't find the rest of the installer on any partition.
>
>Depending on udev early ?
>
>Your findings match the reasons why "Legacy MBR" won in my
>discussion of mini.iso
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776317#75
>The waste of 1 MB for an appended external partition seems
>worthwhile.
>Stripping down my best proposal from BIOS+EFI to EFI-only:
>
> mount -o loop debian-jessie-DI-b2-arm64-netinst.iso /mnt/iso
>
> # Get a copy of the El Torito EFI system partition
> cp /mnt/iso/boot/grub/efi.img arm64-efi.img
>
> # Append that copy as MBR partition of type 0xef
> xorriso -as mkisofs \
> -V 'Debian jessie-DI-b2 arm64 1' \
> -r -o test.iso -J -joliet-long -cache-inodes \
> -e boot/grub/efi.img -no-emul-boot \
> -append_partition 2 0xef arm64-efi.img \
> -partition_cyl_align all \
> /mnt/iso
>
>This yields a non-overlapping UEFI compliant Legacy MBR
>
> MBR partition table: N Status Type Start Blocks
> MBR partition : 1 0x00 0x83 0 262144
> MBR partition : 2 0x00 0xef 262144 2048
>
>The NUL-bytes in the MBR are no problem because of UEF 2.4 5.2.1
>"The boot code on the MBR is not executed by UEFI firmware."
>UEFI 2.4, table 13 shows that it needs at least one partition table
>entry and the magic 0x55 0xaa at bytes 510 and 511.
>
>The only effect of omitting option -isohybrid is that the type
>of partition 1 is 0x83 rather than 0x17.
>-------------------------------------------------------------
>
>I am still hunting a bug in the pending changeset to enable
>production of a UEFI compliant protective MBR plus GPT
>layout with -append_partition. This would be the second best
>proposal from bug=776317#75.
>
>Disadvantages in comparison to above winner:
>You get a mountable ISO partition only if you use
> -partition_offset 16
>The backup GPT makes mini.iso production postprocessing
>cumbersome. (This might be no problem with netinst.iso
>because no postprocessing shall happen in debian-cd anyway.)
like the ability to extend/modify images later and we have docs
telling them how to add partitions once an image is written to a USB
stick, for example.
testing it!
Armed with "Valor": "Centurion" represents quality of Discipline,
Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
concord the digital world while feeling safe and proud.
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Schmitt
Apr 14, 2015, 2:50:03 PM4/14/15
to
Hi,
i wrote back in february:
But when i now tested above proposal (before bragging), it
turned out that production of a true "protective MBR" partition
table works only with isohybrid MBR. (I wonder what use case
i tested 10 weeks ago ...)
... Now above sketch works. The risk of regression by my
last minute change is low.
Nevertheless have a sharp look at i386 and amd64 results
when this version of xorriso produces them.
I did not make any Jigdo tests with -append_partition yet.
As said: -partition_offset 16 is essential for a
mountable GPT partition 1 with the ISO filesystem.
----------------------------------------------------------
The current GNU xorriso development snapshot has the new
-as mkisofs option -appended_part_as_gpt, which lets the
ISO and the appended partition appear in GPT, with UEFI
compliant "protective" MBR.
http://www.gnu.org/software/xorriso/xorriso-1.3.9.tar.gz
MD5 9577c69da2591c683ca2cf84d29e6191
Version timestamp : 2015.04.13.172501
(I finely mistyped the date when faking the timestamp.)
----------------------------------------------------------
We would have to change the CD FAQ about verification of
ISOs, because this advises to determine the exact amount
of image bytes from the ISO filesystem size.
But with above layout there is a neat disk-like situation
where the ISO filesystem ends before the EFI System Partition
begins. So one will rather have to checksum up to the
end of the second partition (as inquired by gdisk or alike).
Best would be if the Debian checksum lists would be
accompanied by length lists, which simply tell the
original size of the images by which the MD5s were computed.
----------------------------------------------------------
> > The backup GPT makes mini.iso production postprocessing
> > cumbersome. (This might be no problem with netinst.iso
> > because no postprocessing shall happen in debian-cd anyway.)
> Maybe not by us directly, but I think a fair number of Debian users
> like the ability to extend/modify images later and we have docs
> telling them how to add partitions once an image is written to a USB
> stick, for example.
As soon as the image is on a block device with inquirable
size, the partition editors should offer an option to move
the backup GPT to the end of the device. That would be the
first step before installing further partitions.
The docs need to be checked whether they are updated for GPT.
Have a nice day :)
Thomas
i wrote back in february:
> > I am still hunting a bug in the pending changeset to enable
> > production of a UEFI compliant protective MBR plus GPT
> > layout with -append_partition.
> > [...]
> > production of a UEFI compliant protective MBR plus GPT
> > layout with -append_partition.
> > This proposal will look like
> > xorriso-1.3.9 -as mkisofs \
> > -V 'Debian jessie-DI-b2 arm64 1' \
> > -r -o test.iso -J -joliet-long -cache-inodes \
> > -e boot/grub/efi.img -no-emul-boot \
> > -append_partition 2 0xef arm64-efi.img \
> > -appended_part_as_gpt \
> > -partition_offset 16 \
> > /mnt/iso
Steve McIntyre wrote today:
> > -V 'Debian jessie-DI-b2 arm64 1' \
> > -r -o test.iso -J -joliet-long -cache-inodes \
> > -e boot/grub/efi.img -no-emul-boot \
> > -append_partition 2 0xef arm64-efi.img \
> > -appended_part_as_gpt \
> > -partition_offset 16 \
> > /mnt/iso
> Right. If you're still working on this I'd be very interested in
> testing it!
Well, the changesets are committed, meanwhile.
> testing it!
But when i now tested above proposal (before bragging), it
turned out that production of a true "protective MBR" partition
table works only with isohybrid MBR. (I wonder what use case
i tested 10 weeks ago ...)
... Now above sketch works. The risk of regression by my
last minute change is low.
Nevertheless have a sharp look at i386 and amd64 results
when this version of xorriso produces them.
I did not make any Jigdo tests with -append_partition yet.
As said: -partition_offset 16 is essential for a
mountable GPT partition 1 with the ISO filesystem.
----------------------------------------------------------
The current GNU xorriso development snapshot has the new
-as mkisofs option -appended_part_as_gpt, which lets the
ISO and the appended partition appear in GPT, with UEFI
compliant "protective" MBR.
http://www.gnu.org/software/xorriso/xorriso-1.3.9.tar.gz
MD5 9577c69da2591c683ca2cf84d29e6191
Version timestamp : 2015.04.13.172501
(I finely mistyped the date when faking the timestamp.)
----------------------------------------------------------
We would have to change the CD FAQ about verification of
ISOs, because this advises to determine the exact amount
of image bytes from the ISO filesystem size.
But with above layout there is a neat disk-like situation
where the ISO filesystem ends before the EFI System Partition
begins. So one will rather have to checksum up to the
end of the second partition (as inquired by gdisk or alike).
Best would be if the Debian checksum lists would be
accompanied by length lists, which simply tell the
original size of the images by which the MD5s were computed.
----------------------------------------------------------
> > The backup GPT makes mini.iso production postprocessing
> > cumbersome. (This might be no problem with netinst.iso
> > because no postprocessing shall happen in debian-cd anyway.)
> Maybe not by us directly, but I think a fair number of Debian users
> like the ability to extend/modify images later and we have docs
> telling them how to add partitions once an image is written to a USB
> stick, for example.
size, the partition editors should offer an option to move
the backup GPT to the end of the device. That would be the
first step before installing further partitions.
The docs need to be checked whether they are updated for GPT.
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/3158256259...@scdbackup.webframe.org
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steve McIntyre
Apr 17, 2015, 8:00:02 PM4/17/15
to
build. This gives me the following:
$ gdisk -l iso/tmp.iso
GPT fdisk (gdisk) version 0.8.5
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk iso/tmp.iso: 313408 sectors, 153.0 MiB
Logical sector size: 512 bytes
Disk identifier (GUID): 2573D2EC-456B-4D75-A0F3-DA94B2713406
Partition table holds up to 248 entries
First usable sector is 64, last usable sector is 313344
Partitions will be aligned on 64-sector boundaries
Total free space is 1 sectors (512 bytes)
Number Start (sector) End (sector) Size Code Name
2 311296 313343 1024.0 KiB EF00 Appended2
3 313344 313343 0 bytes 0700 Gap1
(using the command line options:
~93sam/xorriso-1.3.9/xorriso/xorriso -as mkisofs -r \
-checksum_algorithm_iso md5,sha1,sha256,sha512 \
-V 'Debian testing arm64 1' -o tmp.iso \
($jigdo_opts) \
-J -joliet-long -cache-inodes -e boot/grub/efi.img -no-emul-boot \
-append_partition 2 0xef CD1/boot/grub/efi.img \
-partition_cyl_align all \
-appended_part_as_gpt -partition_offset 16 CD1)
I've tried both with and without the "-partition_offset all" and it
(obviously) affects the partition alignments and the overall image
size, but otherwise the images produced *look* ok apart from the
odd-looking zero-sized 3rd partition. It's a cosmetic issue only, but
I'm curious why it's there. :-)
>We would have to change the CD FAQ about verification of
>ISOs, because this advises to determine the exact amount
>of image bytes from the ISO filesystem size.
>But with above layout there is a neat disk-like situation
>where the ISO filesystem ends before the EFI System Partition
>begins. So one will rather have to checksum up to the
>end of the second partition (as inquired by gdisk or alike).
>
>Best would be if the Debian checksum lists would be
>accompanied by length lists, which simply tell the
>original size of the images by which the MD5s were computed.
<snip>
>> Maybe not by us directly, but I think a fair number of Debian users
>> like the ability to extend/modify images later and we have docs
>> telling them how to add partitions once an image is written to a USB
>> stick, for example.
>
>As soon as the image is on a block device with inquirable
>size, the partition editors should offer an option to move
>the backup GPT to the end of the device. That would be the
>first step before installing further partitions.
>
>The docs need to be checked whether they are updated for GPT.
"...In the UNIX world, people tend to interpret `non-technical user'
as meaning someone who's only ever written one device driver." -- Daniel Pead
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Schmitt
Apr 18, 2015, 4:20:02 AM4/18/15
to
Hi,
> OK, I've just built and done a very quick test with an arm64 netinst
> build.
Does it boot ?
Are the partitions mountable ?
> 3 313344 313343 0 bytes 0700 Gap1
This looks strange.
What do you get from
xorriso-1.3.9 -indev tmp.iso -report_system_area plain
The name "Gap1" seems to stem from libisofs. These partitions
are supposed to fill gaps in the partition layout of grub-mkrescue.
But zero sized gaps are not really intended targets.
> I've tried both with and without the "-partition_offset all" and it
> (obviously) affects the partition alignments and the overall image
> size, but otherwise the images produced *look* ok apart from the
> odd-looking zero-sized 3rd partition. It's a cosmetic issue only, but
> I'm curious why it's there. :-)
I assume you mean -partition_cyl_align, not -partition_offset.
It is a relict of MBR, its quirks, and its urban legends.
SYSLINUX (resp. hpa) emphasizes that isohybrid images have
their partitions aligned to full cylinders, preferrably to
64 heads of 32 sectors or to 255 heads of 63 sectors.
It seems to be about assumptions made by older BIOSes.
UEFI 2.4 does not have hard alignment requirements for partitions.
But there are some "should" statements in 5.3.1 GPT Overview,
which propose to align to physical block size (e.g. 4096)
and state that alignment to 1 MiB fulfills this proposal
with "most common physical block sizes and RAID stripe sizes".
Currently the alignment granularity of xorriso -as mkisofs is
controlled by -partition_hd_cyl and -partition_sec_hd which
are subject to MBR restrictions.
It has to be tested whether
-partition_hd_cyl 64 -partition_sec_hd 32
keeps up the alignment for images larger than 1 GiB (1024
cylinders).
Have a nice day :)
Thomas
> OK, I've just built and done a very quick test with an arm64 netinst
> build.
Are the partitions mountable ?
> 3 313344 313343 0 bytes 0700 Gap1
What do you get from
xorriso-1.3.9 -indev tmp.iso -report_system_area plain
The name "Gap1" seems to stem from libisofs. These partitions
are supposed to fill gaps in the partition layout of grub-mkrescue.
But zero sized gaps are not really intended targets.
> I've tried both with and without the "-partition_offset all" and it
> (obviously) affects the partition alignments and the overall image
> size, but otherwise the images produced *look* ok apart from the
> odd-looking zero-sized 3rd partition. It's a cosmetic issue only, but
> I'm curious why it's there. :-)
It is a relict of MBR, its quirks, and its urban legends.
SYSLINUX (resp. hpa) emphasizes that isohybrid images have
their partitions aligned to full cylinders, preferrably to
64 heads of 32 sectors or to 255 heads of 63 sectors.
It seems to be about assumptions made by older BIOSes.
UEFI 2.4 does not have hard alignment requirements for partitions.
But there are some "should" statements in 5.3.1 GPT Overview,
which propose to align to physical block size (e.g. 4096)
and state that alignment to 1 MiB fulfills this proposal
with "most common physical block sizes and RAID stripe sizes".
Currently the alignment granularity of xorriso -as mkisofs is
controlled by -partition_hd_cyl and -partition_sec_hd which
are subject to MBR restrictions.
It has to be tested whether
-partition_hd_cyl 64 -partition_sec_hd 32
keeps up the alignment for images larger than 1 GiB (1024
cylinders).
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/109556355...@scdbackup.webframe.org
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Schmitt
Apr 18, 2015, 5:50:02 AM4/18/15
to
Hi,
the third, zero sized partition "Gap1" gets indeed
produced by libisofs. xorriso command -report_system_area
does not show it, though.
I am investigating. You may assume that this partition
will not be produced in future xorriso versions.
If the "Gap1" partition entry is suspected to disturb anything,
you may create the intended state of GPT by
dd if=/dev/zero of=tmp.iso conv=notrunc bs=1 seek=1280 count=128
(Actually one would have to zeroize the entry in the backup
GPT, too. Its position is 62 blocks before the backup header
block + 256 bytes. The header block number is given by
xorriso -report_system area as third number in line
"GPT lba range". E.g with
GPT lba range : 64 266240 266303
the backup entry of partition 3 is at byte (266303 - 62) * 512 + 256.
)
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/3268256354...@scdbackup.webframe.org
the third, zero sized partition "Gap1" gets indeed
produced by libisofs. xorriso command -report_system_area
does not show it, though.
I am investigating. You may assume that this partition
will not be produced in future xorriso versions.
If the "Gap1" partition entry is suspected to disturb anything,
you may create the intended state of GPT by
dd if=/dev/zero of=tmp.iso conv=notrunc bs=1 seek=1280 count=128
(Actually one would have to zeroize the entry in the backup
GPT, too. Its position is 62 blocks before the backup header
block + 256 bytes. The header block number is given by
xorriso -report_system area as third number in line
"GPT lba range". E.g with
GPT lba range : 64 266240 266303
the backup entry of partition 3 is at byte (266303 - 62) * 512 + 256.
)
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steve McIntyre
Apr 20, 2015, 1:20:02 PM4/20/15
to
On Sat, Apr 18, 2015 at 10:13:52AM +0200, Thomas Schmitt wrote:
>Hi,
>
>> OK, I've just built and done a very quick test with an arm64 netinst
>> build.
>
>Does it boot ?
Yes.
>Hi,
>
>> OK, I've just built and done a very quick test with an arm64 netinst
>> build.
>
>Does it boot ?
>Are the partitions mountable ?
>> 3 313344 313343 0 bytes 0700 Gap1
>
>This looks strange.
>What do you get from
>
> xorriso-1.3.9 -indev tmp.iso -report_system_area plain
tmp.iso -report_system_area plain
GNU xorriso 1.3.9 : RockRidge filesystem manipulator, libburnia
project.
xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 1238 nodes read in 1 seconds
xorriso : NOTE : Detected El-Torito boot information which currently
is set to be discarded
Drive current: -indev 'tmp.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Boot record : El Torito , MBR cyl-align-off GPT
Media summary: 1 session, 77824 data blocks, 152m data, 29.2g free
Volume id : 'Debian testing arm64 1'
System area options: 0x00000a00
System area summary: MBR cyl-align-off GPT
ISO image size/512 : 311296
Partition offset : 16
MBR heads per cyl : 64
MBR secs per head : 32
MBR secs per head : 32
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x00 0xee 1 313407
GPT : N Info
GPT disk GUID : ecd273256b45754da0f3da94b2713406
GPT entry array : 2 248 separated
GPT lba range : 64 313344 313407
GPT partition name : 1 490053004f003900360036003000
GPT partname local : 1 ISO9660
GPT partition GUID : 1 ecd273256b45754da0f0da94b2713406
GPT partname local : 1 ISO9660
GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags: 1 0x1000000000000001
GPT start and size : 1 64 311232
GPT partition flags: 1 0x1000000000000001
GPT partition name : 2 41007000700065006e006400650064003200
GPT partname local : 2 Appended2
GPT partition GUID : 2 ecd273256b45754da0f1da94b2713406
GPT partname local : 2 Appended2
GPT type GUID : 2 28732ac11ff8d211ba4b00a0c93ec93b
GPT partition flags: 2 0x0000000000000000
GPT start and size : 2 311296 2048
GPT partition flags: 2 0x0000000000000000
>The name "Gap1" seems to stem from libisofs. These partitions
>are supposed to fill gaps in the partition layout of grub-mkrescue.
>But zero sized gaps are not really intended targets.
>> I've tried both with and without the "-partition_offset all" and it
>> (obviously) affects the partition alignments and the overall image
>> size, but otherwise the images produced *look* ok apart from the
>> odd-looking zero-sized 3rd partition. It's a cosmetic issue only, but
>> I'm curious why it's there. :-)
>
>I assume you mean -partition_cyl_align, not -partition_offset.
already as you said.
>It is a relict of MBR, its quirks, and its urban legends.
>SYSLINUX (resp. hpa) emphasizes that isohybrid images have
>their partitions aligned to full cylinders, preferrably to
>64 heads of 32 sectors or to 255 heads of 63 sectors.
>It seems to be about assumptions made by older BIOSes.
>
>UEFI 2.4 does not have hard alignment requirements for partitions.
>But there are some "should" statements in 5.3.1 GPT Overview,
>which propose to align to physical block size (e.g. 4096)
>and state that alignment to 1 MiB fulfills this proposal
>with "most common physical block sizes and RAID stripe sizes".
>Currently the alignment granularity of xorriso -as mkisofs is
>controlled by -partition_hd_cyl and -partition_sec_hd which
>are subject to MBR restrictions.
>It has to be tested whether
> -partition_hd_cyl 64 -partition_sec_hd 32
>keeps up the alignment for images larger than 1 GiB (1024
>cylinders).
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steve McIntyre
Apr 20, 2015, 1:20:02 PM4/20/15
to
On Sat, Apr 18, 2015 at 11:45:16AM +0200, Thomas Schmitt wrote:
>Hi,
>
>the third, zero sized partition "Gap1" gets indeed
>produced by libisofs. xorriso command -report_system_area
>does not show it, though.
ACK, I can see that.
>Hi,
>
>the third, zero sized partition "Gap1" gets indeed
>produced by libisofs. xorriso command -report_system_area
>does not show it, though.
>I am investigating. You may assume that this partition
>will not be produced in future xorriso versions.
image format using an appended msdos partition rather than GPT is
working fine for now, and is what I'm going to use for the Jessie
release this coming weekend. I might be tempted to switch to GPT later
for this, but it's just too close to release to be playing with this
kind of change... :-)
>If the "Gap1" partition entry is suspected to disturb anything,
>you may create the intended state of GPT by
>
> dd if=/dev/zero of=tmp.iso conv=notrunc bs=1 seek=1280 count=128
>
>(Actually one would have to zeroize the entry in the backup
> GPT, too. Its position is 62 blocks before the backup header
> block + 256 bytes. The header block number is given by
> xorriso -report_system area as third number in line
> "GPT lba range". E.g with
> GPT lba range : 64 266240 266303
> the backup entry of partition 3 is at byte (266303 - 62) * 512 + 256.
>)
The Gap1 partition doesn't seem to cause any problems on the one
device I've got handy for testing, anyway.
"This dress doesn't reverse." -- Alden Spiess
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Schmitt
Apr 20, 2015, 2:40:03 PM4/20/15
to
Hi,
i wrote:
> > The name "Gap1" seems to stem from libisofs.
The cause was found and a fix is being tested meanwhile.
Steve McIntyre wrote:
> The Gap1 partition doesn't seem to cause any problems on the one
> device I've got handy for testing, anyway.
In any case it looks clueless.
(The stupid gap filler wanted to cover the backup GPT
by a partition, whereas the less stupid partition
writer truncated it to the permissible range.)
Steve McIntyre wrote:
> > > I've tried both with and without the "-partition_offset all"
"all" is read as 0. Without -partition_offset 16, the
first GPT partition is supposed to be not mountable.
So some riddling remains on my side ...
i wrote:
> > It has to be tested whether
> > -partition_hd_cyl 64 -partition_sec_hd 32
> > keeps up the alignment for images larger than 1 GiB (1024
> > cylinders).
Currently libisofs enlarges the cylinder size if the
number of cylinders exceeds 1024. But i am testing a change
now, which allows an unlimited number of "cylinders" for GPT.
So
-partition_hd_cyl 64 -partition_sec_hd 32 -partition_cyl_align all
will ensure alignment to 1 MiB, if desired.
> I'll be honest, there's no rush for this for me.
This will leave more time for my tests.
My best wishes for Jessie's scheduled birth and all her
proud parents.
Have a nice day :)
Thomas
i wrote:
> > The name "Gap1" seems to stem from libisofs.
Steve McIntyre wrote:
> The Gap1 partition doesn't seem to cause any problems on the one
> device I've got handy for testing, anyway.
(The stupid gap filler wanted to cover the backup GPT
by a partition, whereas the less stupid partition
writer truncated it to the permissible range.)
Steve McIntyre wrote:
> > > I've tried both with and without the "-partition_offset all"
> > I assume you mean -partition_cyl_align, not -partition_offset.
> No, explicitly -partition_offset. I'd added -partition_cyl_align
> already as you said.
-partition_offset expects a block number as argument.
> No, explicitly -partition_offset. I'd added -partition_cyl_align
> already as you said.
"all" is read as 0. Without -partition_offset 16, the
first GPT partition is supposed to be not mountable.
So some riddling remains on my side ...
i wrote:
> > It has to be tested whether
> > -partition_hd_cyl 64 -partition_sec_hd 32
> > keeps up the alignment for images larger than 1 GiB (1024
> > cylinders).
number of cylinders exceeds 1024. But i am testing a change
now, which allows an unlimited number of "cylinders" for GPT.
So
-partition_hd_cyl 64 -partition_sec_hd 32 -partition_cyl_align all
will ensure alignment to 1 MiB, if desired.
> I'll be honest, there's no rush for this for me.
My best wishes for Jessie's scheduled birth and all her
proud parents.
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/992356311...@scdbackup.webframe.org
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages