All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Schmitt" <scdbackup@gmx.net>
To: grub-devel@gnu.org
Cc: michel@bouissou.net
Subject: Re: A thread on grub-bug could need attention
Date: Fri, 02 Feb 2018 11:18:17 +0100	[thread overview]
Message-ID: <27696785453525870820@scdbackup.webframe.org> (raw)
In-Reply-To: <4cc95338-8da7-e953-ff55-175b554771b8@bouissou.net>

Hi,

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

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



  parent reply	other threads:[~2018-02-02 19:48 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-20 11:35 A thread on grub-bug could need attention Thomas Schmitt
2018-01-08 12:48 ` Daniel Kiper
2018-01-08 16:14   ` Michel Bouissou
2018-01-29 12:49     ` Daniel Kiper
2018-01-29 15:29       ` Michel Bouissou
2018-01-29 18:20         ` Michel Bouissou
2018-01-29 18:53           ` Thomas Schmitt
2018-01-30 15:18             ` Michel Bouissou
2018-01-30 16:33               ` Thomas Schmitt
2018-01-30 17:43                 ` Michel Bouissou
2018-01-30 18:00           ` Daniel Kiper
2018-01-30 19:15             ` Thomas Schmitt
2018-01-31  9:38               ` Michel Bouissou
2018-01-31 12:20                 ` Thomas Schmitt
2018-01-31 13:22                   ` Michel Bouissou
2018-01-31 15:33                     ` Thomas Schmitt
2018-01-31 21:37                       ` Thomas Schmitt
2018-01-31 22:47                         ` Michel Bouissou
2018-02-01  0:02                           ` Thomas Schmitt
2018-02-01 21:56                             ` Michel Bouissou
2018-02-02  8:15                               ` Thomas Schmitt
2018-02-02 10:28                                 ` Michel Bouissou
2018-02-02 10:50                                   ` Thomas Schmitt
2018-02-02 10:18                               ` Thomas Schmitt [this message]
2018-01-31 15:46                 ` Daniel Kiper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=27696785453525870820@scdbackup.webframe.org \
    --to=scdbackup@gmx.net \
    --cc=grub-devel@gnu.org \
    --cc=michel@bouissou.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.