grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A thread on grub-bug could need attention


From: Thomas Schmitt
Subject: Re: A thread on grub-bug could need attention
Date: Fri, 02 Feb 2018 11:18:17 +0100

Hi,

about two hours ago i sent an answer to
  Date: Thu, 1 Feb 2018 22:56:26 +0100
  From: Michel Bouissou <address@hidden>
  Subject: Re: A thread on grub-bug could need attention
with own
  Date: Fri, 02 Feb 2018 09:15:42 +0100
  Message-Id: <address@hidden>

It did not show up in the mailing list yet. Neither in my mailbox nor at
  http://lists.gnu.org/archive/html/grub-devel/2018-02/threads.html

This is an attempt to resend it. I again Cc: Michel Bouissou because i
don't know whether the problem is with my mail provider.

-----------------------------------------------------------------------------

Hi,

i wrote:
> > zeroize 512-byte block 1 of the
> > Debian Live ISO and then try to boot it from USB stick

Michel Bouissou wrote:
> I made it (with latest debian-gnome 9.3 live),i

Now we have no surplus GPT any more. The EFI system partition is only
marked by the MBR partition 2 (and by the El Torito catalog which should
be ignored when found on USB stick).


> and tested it OK on *another* machine.
> But on the machine where the problem is, it does *NOT* boot.

Normally i would now again exclude the theory that the partitions inside
the ISO are to blame. (We still have to explain why the GRUB installations
on hard-disk-like partitioned USB sticks failed too.)


> It does display the key brand/model (instead of "Windows boot manager")

But this slight change in firmware behavior could be significant.

Under the theory that it's the partition layout and not the EFI partition
image content or its way to hop on the ISO, there remains the nested
partition situation as main suspect:

  $ /sbin/fdisk -l debian-live-9.3.0-amd64-xfce.iso
  ...
  Device                            Boot Start     End Sectors  Size Id Type
  debian-live-9.3.0-amd64-xfce.iso1 *        0 3803903 3803904  1.8G  0 Empty
  debian-live-9.3.0-amd64-xfce.iso2       1548    2379     832  416K ef EFI

The block range of partition 2 is inside partition 1.
Normally the type 0 ("Empty") of partition 1 is enough to let firmwares
tolerate this.

Partition 1 is not needed for the boot process. It just protects the ISO
from partition editors and provides a mountable partition to operating
systems.

So the next experiment would be to remove it, i.e. zeroize its slot in
the MBR.

One can do it in the ISO file
  img=debian-live-9.3.0-amd64-xfce.iso
or directly on the USB stick where it was copied
  img=/dev/sdc

Either by:
  /sbin/fdisk "$img" <<+
  d
  1
  w
  +

Or by:
  dd if=/dev/zero bs=1 seek=446 count=16 conv=notrunc of="$img"


The result should then be
  $ /sbin/fdisk -l "$img"
  ...
  Device                            Boot Start     End Sectors  Size Id Type
  debian-live-9.3.0-amd64-xfce.iso2       1548    2379     832  416K ef EFI 


Have a nice day :)

Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]