From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: Use genimage for disk-image creation. Date: Sun, 29 Mar 2020 17:07:14 +0200 Message-ID: <20200329170714.1bf26eb3@scratchpost.org> References: <87eetgo9o6.fsf@gmail.com> <20200327002438.527eb1d0@scratchpost.org> <871rpb1aqw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/h+5rC3ZfzkZV.feKqavNi3q"; protocol="application/pgp-signature"; micalg=pgp-sha256 Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:38204) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIZWz-00078V-1S for guix-devel@gnu.org; Sun, 29 Mar 2020 11:07:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jIZWx-0004hc-Oy for guix-devel@gnu.org; Sun, 29 Mar 2020 11:07:20 -0400 In-Reply-To: <871rpb1aqw.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: Ludovic =?ISO-8859-1?Q?Court=E8s?= Cc: guix-devel --Sig_/h+5rC3ZfzkZV.feKqavNi3q Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ludo, On Sun, 29 Mar 2020 16:44:39 +0200 Ludovic Court=C3=A8s wrote: > Oh, really? I=E2=80=99m surprised partitioning causes problems (though I= =E2=80=99m > 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 somewhe= re 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 o= ver 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/00= 5152.html --Sig_/h+5rC3ZfzkZV.feKqavNi3q Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl6AuaIACgkQ5xo1VCww uqWxHQf/Y/9Bkwe87pPKTYCZhurQCEOo6VHqsnmyWMfxfeePZ6H/lWcZ8jw0R6+I 0rMF3+0q/CNBMu03ZJGzuD6xSox9RUhV6FkLTce8u8ubTEd6j/N1xj0v7cY0Igk+ g0/G+9fasJXjqPLd9TSdVcqV8sqZb3gHeNq2c/l1jqpS76legCANVbDIQqEMFLoc M0hyY5jvtjYnv66IoTQcIPjOAjqNJwr6zpCyOLQgpSQ02pra4hWCLkoJSPguk0aj Nut8JIsl47SDnpQ8/7EY04sbDXSrdQvs7abY8wZ9TUaZMs8wkfmQWn0z9E0fgGd9 Wap7x1g6Wns9KIVY7jz6CPBiDrMK4g== =gYJz -----END PGP SIGNATURE----- --Sig_/h+5rC3ZfzkZV.feKqavNi3q--