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
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.
>I am investigating. You may assume that this partition
>will not b
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.
>Are the partitions mountable ?
The first two are, yes.
>>3 313344 313343 0 bytes 0700 Gap
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
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
On Tue, Apr 14, 2015 at 08:41:35PM +0200, Thomas Schmitt wrote:
>Hi,
>
>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.
>> > [...]
>> > This proposal will look
Hi,
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.
> > [...]
> > This proposal will look like
> > xorriso-1.3.9 -as mkisofs \
> > -V 'Debian jessie-DI-b2 ar
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 d
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,
Apologies, no - I've been busy at
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 ?
If it is reproducible, then my understanding of partitions
is in deep trouble. I'd need to investigate and compare an
Hi,
> If I specify "-c isolinux/boot.cat" too, that fixes
> it.
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
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 doe
On Wed, Feb 04, 2015 at 03:12:30PM +, Steve McIntyre wrote:
>On Sat, Jan 31, 2015 at 10:24:17AM +, 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 f
On Sat, Jan 31, 2015 at 10:24:17AM +, 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
>>
>>
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. :-)
>How about you replace it by the intent to fix bug 776317:
>amd64 mini.iso : BIOS or EFI boot
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 p
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...
>
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 test
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
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.
-
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
intelligen
21 matches
Mail list logo
