From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thomas Schmitt" Subject: ISO installer image: GPT versus MBR partitions (was bug#33639) Date: Tue, 16 Apr 2019 15:40:56 +0200 Message-ID: <22381672198740946174@scdbackup.webframe.org> References: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:45270) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hGOIf-0002Aa-Ss for guix-devel@gnu.org; Tue, 16 Apr 2019 09:39:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hGOIe-0006ej-EE for guix-devel@gnu.org; Tue, 16 Apr 2019 09:39:01 -0400 In-Reply-To: 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.org@gnu.org Sender: "Guix-devel" To: bug-xorriso@gnu.org Cc: guix-devel@gnu.org Hi, G=C3=A1bor 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 33639@debbugs.gnu.org from the Cc ? I herby give this a try. i wrote: > > The alternative/backup header is a property of GPT which makes it > > rather unsuitable for disk images. G=C3=A1bor Boskovits wrote: > Could we create a simple tool to write the disk images to a disk > correcting this problem? There are GPT partition editors which offer to repair the backup block problem. gdisk has in its expert's menu 'x': e relocate backup data structures to the end of the disk The job is indeed not very difficult. Backup header block and backup table entries array need to be moved up. Then a few block addresses in both header blocks need to be updated. Finally new CRCs need to be computed and put into the headers. More headache is in the wish to have a fool-proof tool for copying the image file to USB stick. Compared with the risks of burning a DVD, the risks of writing a disk image are quite unbearable. Covering all pitfalls might be a larger adventure. (Ubuntu has mkusb: https://help.ubuntu.com/community/mkusb) A problem with GPT relocation is that checksums of the image cannot be verified on USB stick any more. An MBR partitioned image would not have to be altered. /sbin/isosize could tell the number of bytes which should be processed when comparing with published checksums. Further an MBR partitioned image would have no non-mountable partitions. $ /sbin/gdisk guixsd-install-0.15.0.i686-linux.iso ... Command (? for help): p ... Number Start (sector) End (sector) Size Code Name 1 64 34107 16.6 MiB 0700 Gap0 2 34108 39867 2.8 MiB EF00 EFI boot partit= ion 3 39868 1815727 867.1 MiB AF00 HFSPLUS 4 1815728 1816327 300.0 KiB 0700 Gap1 Gap0 and Gap1 are not mountable. One can get access to the ISO's files only via the base device. The HFS+ partition publishes the same files, but you need to find a HFS+ driver which works with block size 2048. (Even more difficult could be to find any machine that boots via APM and HFS+ and can make use of the binaries in ISO and HFS+.) Repeating my example of yesterday of a grub-mkrescue ISO with MBR partition table (and no APM, which could be added if really of interest): $ /sbin/fdisk -l output.iso ... Device Boot Start End Sectors Size Id Type output.iso1 * 64 28103 28040 13.7M 83 Linux output.iso2 28104 33863 5760 2.8M ef EFI (FAT-12/16/32) $ expr $(/sbin/isosize output.iso) / 512 33864 Of course, ISO and partition 1 would be much larger in a Guix ISO. Have a nice day :) Thomas