Hi,
Gábor Boskovits wrote:
> I removed the xorriso bug list, as I feel this does not belong there.
As its admin i say that everything xorriso related belongs there. :))
But maybe we should remove 33...@debbugs.gnu.org from the Cc ?
I herby give this a try.
i wrote:
> > The alternative/backup
Hi,
Florian Pelz wrote:
> I would prefer an image that can be written just with dd,
A broken backup GPT is not supposed to stop EFI from finding its partition
and running its architecture specific start-up program.
But it becomes annoying when another partition shall be created for
a read-write
Hi,
i wrote:
> > A broken backup GPT is not supposed to stop EFI from finding its partition
Florian Pelz wrote:
> On the 2011 Macbook I am using, the boot process gets stuck before I
> can select the drive to boot from, as long as a USB flash drive with
> this GPT error is in a USB port.
Did you
Hi,
Florian Pelz wrote:
> $ gdisk Downloads/debian-live-9.8.0-amd64-xfce.iso
> ...
> Found valid MBR and GPT. Which do you want to use?
> 1 - MBR
> 2 - GPT
> ...
> Your answer: 2
> Using GPT and creating fresh protective MBR.
> Warning! Main partition table overlaps the first partition by 64 block
Hi,
here are instructions to repack a Guix ISO with EFI support (via GPT)
to an ISO with MBR-only partition table.
Tested with guixsd-install-0.15.0.i686-linux.iso, because my copy
of 0.16.0 is one of the victims of bug#33639.
It becomes 130 MiB larger than the original, probably because there
w
Hi,
Florian Pelz wrote:
> my Macbook still does not like it.
The content of the EFI partition of guixsd-install-0.15.0.i686-linux.iso
does not look like it is ready for 64-bit x86:
$ mount guixsd-install-0.15.0.i686-linux.iso /mnt/iso
$ mount /mnt/iso/efi.img /mnt/fat
$ find /mnt/fat -exec
Hi,
meanwhile i learned that "i686" means 32 bit.
So i downloaded
guixsd-install-0.16.0.x86_64-linux.iso
and see indeed the boot program for 64 bit x86 in the EFI partition:
-rwxr-xr-x 1 root root 132608 Dec 5 16:59 /mnt/fat/efi/boot/bootx64.efi
>From Florian's reports i cannot tell which
Hi,
i wrote:
> > From Florian's reports i cannot tell which ISO he used
Florian Pelz wrote:
> The current git master for x86_64.
I begin to remember discussions about 64-bit Macs having 32-bit EFI
firmware.
Googling brought me to
https://everymac.com/mac-answers/snow-leopard-mac-os-x-faq/mac-
Hi,
Florian Pelz wrote:
> I find a efi/boot/bootx64.efi PE executable inside efi.img on the Guix
> ISO. On Debian the long name is EFI/boot/bootx64.iso in capital letters
(I assume s/bootx64.iso/bootx64.efi/)
It's FAT filesystem. Upper case or lower case does not matter.
Most probably it is a ma
Hi,
this is the xorriso run for producing a layout like "isohybrid --uefi"
with GRUB equipment for BIOS instead of ISOLINUX.
I prepended command -stdio_sync "off" in order to make use of my generous
amount of RAM for write buffering. The default syncs to disk every 16 MiB.
Good with low RAM or fa
Hi,
i wrote:
> > this is the xorriso run for producing a layout like "isohybrid --uefi"
Florian Pelz wrote:
> No, it still gets stuck. :(
Then it must be something inside the EFI partition which makes the
Macbook firmware dismiss the partition for booting.
> The GPT partition GUID is different
Hi,
Florian Pelz wrote:
> For x86_64 iso images, the Macbook does *not dismiss*. It gets stuck
> in the lightgray startup screen forever without showing a menu with
> the drives to boot from, except for the Debian ISO image, for which a
> menu is shown with an »EFI partition« that runs a bootload
Hi,
Florian Pelz wrote:
> The DVD works and is bootable. :)
Hrmpf. I hate it when success spoils a theory.
I wrote:
> > The youngest without "Secure" in its bootx64.efi is
> > debian-7.7.0-amd64-netinst.iso
> No, it does not hang, it is bootable.
It is about time for black candles and the t
Hi,
Florian Pelz wrote:
> I wonder, what kind of FAT is the EFI partition using? Could it be
> the wrong kind of FAT?
I got a mail from a bystander, Ady Ady whom i know from SYSLINUX/ISOLINUX
mailing list. He proposes the experiment to exchange the whole EFI partition
of the Guix ISO by the one
Hi,
i now look at the FAT filesystem images of Debian Live 9 and Guix 0.16.0:
Guix:
- There is an MBR partition table in the image file:
DeviceBoot Start End Sectors Size Id Type
/mnt/iso/efi.img1 *0 28792880 1.4M 1 FAT12
- Program "file" says:
DOS/MBR b
Hi,
... and if the erasure of the partition table entry helps, would it then
also help if that entry's partition does not start at LBA 0 ?
Change bytes 446 (dec) to 461 (dec) from (in hex):
80 00 01 00 01 01 12 4f 00 00 00 00 40 0b 00 00
to
80 00 02 00 01 01 12 4f 01
Hi,
i wrote:
> To kill table entry 1 after having put the Guix EFI image back into
> partition 2 of the USB stick:
>
> dd if=/dev/zero bs=1 count=16 seek=446 of=/dev/sdc1
Of course i meant of=/dev/sdc2
The 16 bytes written to /dev/sdc1 would deface the GPT's "protective" MBR
and thus make the
Hi,
Florian Pelz wrote:
> mkfs.fat fatfs.img
> sudo mount fatfs.img /mnt/img
> sudo cp -r /mnt/efiimg/efi /mnt/img/
> Hooray! It boots!
So it is indeed the filesystem hull, which is to blame.
We still need to find out whether the partition entry is the culprit.
So please do the experiment with
Hi,
i wrote:
> > with the Guix EFI partition image in
> > partition 2 of the USB stick and
> >dd if=/dev/zero bs=1 count=16 seek=446 of=/dev/sdc2
Florian Pelz wrote:
> Yes, this fixes the issue.
I really had a good feeling with that theory. :))
--
Hi,
i plan to ask at gru-devel about mformat, its MBR, and the partition entry,
as soon as the last experiment is made (LBA 1 rather than LBA 0 as start
of the inner partition).
For that discussion i could also need the exact model name of the Macbook.
If its EFI has a name, then this too.
Flor
Hi,
i wrote:
> > ... 3f 0b
> > ... 40 0b
> > ... == ==
Florian Pelz wrote:
> Why is 0b underlined?
Too much enthusiasm on my side.
> OK, so I just wrote the Guix git master with ludo’s reproducibility
> patches to a USB drive (boot gets stuck again) and then did:
> sudo dd if=/dev/sdc2 of=m
Hi,
Florian Pelz wrote:
> it is not
> 80 00 00 04 01 24 4f 00 00 00 00 80 16 00 00 00
> but
> 80 00 01 00 04 01 24 4f 00 00 00 00 80 16 00 00 00
This makes more sense as an MBR partition table entry:
Start C/H/S is 0/0/1.
Start LBA is 0.
Block count is 0x1680 = 5760
Hi,
Ady Ady gave me a hint about why the EFI partition in Guix 0.16.0 ISO
has 1.4 MB of size, despite grub-mkrescue asks mformat for 2.8 MB.
Obviously Guix uses mtools 4.0.21 (image OEM-ID "MTOO4021") which is one
version before this bug fix:
"Fixed -f flag for mformat (size is KBytes, rather t
Hi,
Florian pelaz wrote:
> So the options are:
> · Update mtools and then somehow patch mformat to zero out this
> region.
I will hopefully tonight post a proposal for
- Leave grub-mkrescue and mformat as they are. Rather do the partition
entry removal in the course of Guix ISO production.
I
Hi,
after the adventure of diagnosing Macbook EFI and mformat, i want to
return to the original topic of this thread:
I deem it worthwhile to offer the opportunity to create the Guix ISO
with MBR partition table rather than with GPT.
If you just want to see my technical proposal, then hop to the
Hi,
Florian Pelz wrote:
> florian@florianmacbook ~ [env]$ grub-mkrescue -o output.iso minimal
> --xorriso=./grub-mkrescue-sed.sh
> grub-mkrescue: warning: Your xorriso doesn't support `--grub2-boot-info'.
> Some features are disabled. Please use xorriso 1.2.9 or later..
>
> and yields no output.is
Hi,
i wrote:
> > > > So programs like /sbin/isosize can tell the image size
> > (The [Debian] layout with nested partitions obsoletes the cleanliness
> > considerations about partition start at LBA 0.)
Florian Pelz wrote
> So… GPT is wrong for some optical media too?
Not in this aspect. GPT pa
Hi,
Florian Pelz wrote:
> Sorry, I meant to quote this aspect:
I wrote:
> > > One can read trailing garbage not only from USB sticks but also from
> > > most DVD types.
Florian Pelz wrote:
> > So… GPT is wrong for some optical media too?
I wrote:
> Not in this aspect. GPT partitions must not st
Hi,
Danny Milosavljevic wrte:
> If someone is testing this with Guix, make sure to actually try to boot Guix
> with it (until the root is mounted). Back in the day I changed the root
> discovery of Guix to make it also consider using the entire disk (as opposed
> to a partition on it) as a viable
Hi,
Florian Pelz wrote:
> So what’s the plan?
> Wait for another responce from the grub-devel mailing list?
They need time to to make up their mind. Maybe other incidents are needed to
push towards some change in grub-mkrescue.
We have a halfways positive response from the old owner and a somewha
Hi,
Florian Pelz wrote:
> I do not know and did not try yet how to configure GRUB to produce
> both 32-bit and 64-bit EFI.
As Debian user i am in the comfortable position to install the
three binary packages for BIOS, x86 EFI 32 bit, and x86 EFI 64 bit.
Then grub-mkrescue knows what to do.
Some
Hi,
Danny Milosavljevic wrote:
> you *are* upstream so
> it's really up to you whether we should patch xorriso or not.
Then do if you can make use of those two git commits.
They are the only ones to that file since release 1.5.0.
> I'm not sure about amending "guix system disk-image" by options
Hi,
i worte:
> > (My other sport besides ISO 9660 is burning flat round things.)
Florian Pelz wrote:
> :D Burning is not the problem. ;)
We could let xorriso put some read load on it and watch out for error
messages.
> With the USB flash drive booting was not stuck, it just did not appear
> in
Hi,
i wrote:
> > --file-system-type=iso9660[_$variation]
Danny Milosavljevic wrote:
> I'm not sure yet. We have a lot of special-casing for iso9660
> already. If anything, at that point, we could pass an arbitrary list
> of options or something (an "environment" if you will. Hah).
How ever
Hi,
Ludovic Courtès wrote:
> > I lost track of the discussion. You’re looking at a MacBook-specific
> > issue, right?
Florian Pelz wrote:
> As I understand it, Thomas’ work is about
> - making a correct ISO image and
The grub-mkrescue ISOs are correct but also sometimes inconvenient on
USB stic
Hi,
Ludovic Courtès wrote:
> I don’t feel like distributing two variants of the ISO per architecture.
Then i guess the most early opportunity for my proposal to get
into production is after the upcomming Guix release.
> It’s also something other distros don’t do: you get only one
> ISO per arch
36 matches
Mail list logo
