unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Danny Milosavljevic <dannym@scratchpost.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Use genimage for disk-image creation.
Date: Sun, 29 Mar 2020 17:07:14 +0200	[thread overview]
Message-ID: <20200329170714.1bf26eb3@scratchpost.org> (raw)
In-Reply-To: <871rpb1aqw.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1871 bytes --]

Hi Ludo,

On Sun, 29 Mar 2020 16:44:39 +0200
Ludovic Courtès <ludo@gnu.org> wrote:

> Oh, really?  I’m surprised partitioning causes problems (though I’m
> not familiar with embedded dev!).

Well, maybe not that bad, but it's pretty bad.

It's because the boot sector for ARM, for some unfathomable reason, is not
the first sector but has basically a vendor-dependent sector number somewhere
in the middle of the disk :P

(with the "boot sector" I mean the sector(s) where usually u-boot resides)

So there are all kinds of stupid problems like sometimes you have to reduce
the size of the GPT partition table (TABLE!) because it would write right over
the actual boot sector of the platform otherwise.  For that vendor.  Other
vendors do other silly things.

Parted doesn't really have support for that stuff either, and I while I
brought it up with them[1], I can't think of a practical way to fix it
(i.e. automatically keep clear of all possible boot ranges of all ARM
vendors) or to even find the extent of the problem.  I think it should be
the vendors' responsibility to standardize on one way to boot that doesn't
suck :P

It turns partitioning basically from straightforward allocation inside
one block into allocation with strange hidden mines to avoid.

Embedded usually ignores the problem, finds a partitioning that works
(with dummy spacer partition if you are lucky--otherwise just random
gap) and everyone just uses that one.  Sigh...

(x86 kinda has standardized a gap at the beginning of the disk until the
second head (seems to be 2048 sectors with 512 Byte/sector nowadays
since the drive doesn't expose valid CHS information anymore), and put
the bootloader there--so that's a 1 MiB gap at the beginning of the
disk)

[1] https://alioth-lists.debian.net/pipermail/parted-devel/2017-December/005152.html

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-03-29 15:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-25 13:18 Use genimage for disk-image creation Mathieu Othacehe
2020-03-26  9:55 ` Vincent Legoll
2020-03-26 10:18   ` Efraim Flashner
2020-03-28 20:47   ` Mathieu Othacehe
2020-03-28 21:25     ` Vincent Legoll
2020-03-26 14:19 ` Ludovic Courtès
2020-03-26 15:01   ` Vincent Legoll
2020-03-29 18:13   ` Mathieu Othacehe
2020-03-26 23:24 ` Danny Milosavljevic
2020-03-29 14:44   ` Ludovic Courtès
2020-03-29 15:07     ` Danny Milosavljevic [this message]
2020-03-29 19:06       ` Vagrant Cascadian
2020-03-31 15:24         ` Ludovic Courtès

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=20200329170714.1bf26eb3@scratchpost.org \
    --to=dannym@scratchpost.org \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).