From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1aCCYn-00035H-05 for mharc-grub-devel@gnu.org; Thu, 24 Dec 2015 15:32:29 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aCCYl-00034U-63 for grub-devel@gnu.org; Thu, 24 Dec 2015 15:32:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aCCYh-00050y-WE for grub-devel@gnu.org; Thu, 24 Dec 2015 15:32:27 -0500 Received: from mail-lb0-x22d.google.com ([2a00:1450:4010:c04::22d]:34405) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aCCYh-00050N-Ms for grub-devel@gnu.org; Thu, 24 Dec 2015 15:32:23 -0500 Received: by mail-lb0-x22d.google.com with SMTP id pv2so78312812lbb.1 for ; Thu, 24 Dec 2015 12:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=64+VZyleUiLGkgXlrMg8kj6f4SO6QY6Cm7QAjv0YurI=; b=mS4ZEOw0DdCF7aCO9NeIBP5+2CaN3kcw/wu2arYGjc2mQoDcC8ajx43UGWuphlxyQe 2yE3So5q+mx93GzhvtNQ2R1mN6TOSA5mHl7v7XX3XWRMWcVa6yeP/zlkXCStaep/a46p bKHst3Ye179DurIwXggDLNtvSzj9NwS0SuL9U8uxi5n2sM7n8qgOPbvmOWntGAuzYYw+ fus+AVDHDwDWzVBpjdhGh7PG8k6NNpXCLBy+8+VmHbVGWjcle+8kqBvlNjZTARO9KPgG XckSm+euQbU606AnSg1dCzmn4Omwfm+iawN6a3Ye4JKAyykNZ5G0R62ppeBGmVFD248z j49g== X-Received: by 10.112.13.99 with SMTP id g3mr5040761lbc.86.1450989142864; Thu, 24 Dec 2015 12:32:22 -0800 (PST) Received: from [192.168.1.41] (ppp91-76-25-247.pppoe.mtu-net.ru. [91.76.25.247]) by smtp.gmail.com with ESMTPSA id th6sm1432233lbb.26.2015.12.24.12.32.21 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Dec 2015 12:32:22 -0800 (PST) Subject: Re: grub-mkrescue hfsplus GPT partition is not mountable on Linux To: The development of GNU GRUB References: <5679A1C0.5020702@gmail.com> <8610584908695216656@scdbackup.webframe.org> From: Andrei Borzenkov X-Enigmail-Draft-Status: N1110 Message-ID: <567C5654.4060505@gmail.com> Date: Thu, 24 Dec 2015 23:32:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <8610584908695216656@scdbackup.webframe.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c04::22d X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 20:32:28 -0000 23.12.2015 01:54, Thomas Schmitt пишет: > > The HFS+ failure is due to APM block size 2048. > Linux has 512 hardcoded. > No, it has not. > > My assessment back then with a Linux kernel 2.6i.32 was that the > APM Block0 is not interpreted at all. Its bytes 2 and 3 tell the > block size. Do not confuse APM and HFS+. Block size in APM has no relation to block size in HFS+. Neither in Linux nor in GRUB. And GRUB never uses APM block size when reading HFS+ either. > > In fs/hfsplus/hfsplus_raw.h i see: > > #define HFSPLUS_SECTOR_SIZE 512 > #define HFSPLUS_SECTOR_SHIFT 9 > This is simply *minimal* HFS+ block size, same as in GRUB. > >> I am not sure what is intended here, but apparently Linux does not >> support APM > > It supports APM with block size 512. It supports APM with any size. It is just that APM has lower priority in Linux so MSDOS or GPT win and Linux does not support multiple partition labels on device. And again - APM is irrelevant here, we do not access HFS+ via APM, we access it via GPT in this case. If I adjust gpt3 to be of the same size as apple2 it is happily mounted by Linux. So there is absolutely no issue with block size in HFS+. > > Hrmpf. This might be the reason why HFS+ was supposed to imply > the production of GPT. > I will investigate where and how i can add a GPT partition for > HFS+ if GPT gets produced. > If you insist on covering the whole range, just add one more GPT partition after it. > >> And is the very first partition really needed? It is not used by GRUB >> anyway, and there is no requirement that each bit of media is covered. > > Vladimir wanted it. It protects against inadverted partition editing. > Not following here. The whole image is created by dedicated tool and is mainly intended for read-only media anyway.