From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1aCn9t-00014Z-GQ for mharc-grub-devel@gnu.org; Sat, 26 Dec 2015 06:37:13 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aCn9q-00013Y-8a for grub-devel@gnu.org; Sat, 26 Dec 2015 06:37:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aCn9p-0004Np-5b for grub-devel@gnu.org; Sat, 26 Dec 2015 06:37:10 -0500 Received: from mout.gmx.net ([212.227.15.19]:55927) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aCn9k-0004NL-HE; Sat, 26 Dec 2015 06:37:04 -0500 Received: from scdbackup.webframe.org ([79.192.89.52]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MTBLi-1Zkdtg321u-00S7yB; Sat, 26 Dec 2015 12:37:02 +0100 Date: Sat, 26 Dec 2015 12:39:05 +0100 From: "Thomas Schmitt" To: grub-devel@gnu.org Subject: Re: grub-mkrescue hfsplus GPT partition is not mountable on Linux Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit References: <26508584595220407814@scdbackup.webframe.org> In-Reply-To: <26508584595220407814@scdbackup.webframe.org> Message-Id: <26526584800101287429@scdbackup.webframe.org> X-Provags-ID: V03:K0:MpBvCUqhZUYcAEaekWNpTjdCi66cuY15FwcAAve/LPYlI8nJVgA AB9vq5sm4KK2o3/quRpZdx8i9owMGK3nlMUo4jSvKl1yyHvYDS0y0siz1ucccVIWxbpqumQ F40twGMtvE1adeR1c7JDxtL3oKJH0tQlb5fKAlmr+2YroZ7cE2u0/KyU2LrG0YIgV0oLGBc yTeTuG7P3xpSRLCda2slA== X-UI-Out-Filterresults: notjunk:1;V01:K0:/+21c5jAmEM=:pP84RjHwDM5z3NM053FChM bYdxvLc12wBw3Qpdv4ra2KwxsJWcw/fEmqxSEWDRaqRXpnMnmWYkzOuYsahu1Wsh75SARuzhz sRw4wlmowe1MIVfERoST1CW+exJD3XBYYRAo30Zp7/pwt8ddsh9ofcrbpfGCb8y/eCsrnET1Y w+EnwjMESlHfY4Rzt7q5Prit5oKdLjE3Ne7sMYFPsA33OfmL1vB9ggCpxT6RI/7rKo1Ax4FXG nebVXAQOBuCIkbYcDKleZxZkAUm3GTBuC/MAggRqbSfp19dK5cXLP+0OxxyWZQ3IZY45GSDa7 fWr3g7V3ge/9798H1Myk1IVoUdp6dz8DdRtVcU/wmHyKQXT+ueCVfJNn6Mt9m57nkNydy2PAP 2axjRqMvPMPlTvVSbE8Jo289XX0xH8q93CO8I8lF2axFVCnouzqZ96L+oNF/YjlnQsxHdZVYH 4Iwg039B9HRv7wLYNETxyGDQSKTbiO+0c1sutnmZ/j10vvkpzlLuwLUNs8ETFQVKNqtKytUh3 M5ZiWpziW17j+1nGW+SLUjiKwP9a6h5QZOtb3Zx7aqIpNbaMxJZ0sXeA9hcn9yFN8uvUCp59G 3vtZAYtRQhejVKsVnvGm67eMAbkkj2D3XJWdfjfssnTdVS5MKi5yNZ1GYY3+pN10QPN8UOgyQ 2Ws3XkEcUKbLziYxjkWIQ1IV+X/SA3exm5wJZ4K2dfTLX5atRN9q2Bfja4Xnc20+tgEKW77y5 VqIa6j6CpLjI+90tWevc6Yt3UpdSGvEf8Ko12MINvJoQUYjfUvWr2BrzPsIWl7gWgs6FAxNPK RAZu/Me X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.19 Cc: bug-xorriso@gnu.org 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: Sat, 26 Dec 2015 11:37:11 -0000 Hi, i hopefully identified the cause of the i/o error with kernel message [ 359.020970] hfsplus: walked past end of dir It seems to be an original mistake by Vladimir (who normally makes much less mistakes than i do). Since Andrei is surely more familiar with Vladimir's coding habits and quite surely has more clue about HFS+, i post my analysis for review. -------------------------------------------------------------------- In libisofs/hfsplus.c there is a function create_tree() : http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/1249/libisofs/hfsplus.c#L299 It converts file objects from the libisofs tree model into objects of the HFS+ tree model. The function returns 0 without creating a new HFS+ tree object for files which it deems to be ignorable. In case of error the return value is < 0. In case of successful creation of HFS+ object and sub objects it returns ISO_SUCCESS, which is > 0. The two callers of create_tree() return error, if they receive a return value < 0. But they increment the directory children counter without regarding return value 0. This happens in the loop for populating the root directory http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/1249/libisofs/hfsplus.c#L1660 and in the loop for recursively populating other directories http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/1249/libisofs/hfsplus.c#L400 In my test runs, two files get ignored in the root directory: /boot.catalog ... because it is not a data file in the libisofs model but rather a boot catalog. (For HFS+ this difference would not matter.) /efi.img ......... because it is explicitely hidden from HFS+. (Not so clear why libisofs/eltorito.c hides the first EFI boot image from HFS+. Shrug.) So the HFS+ root directory gets a .nchildren count of 6, but only 4 HFS+ file objects get registered for populating the root directory. The remedy is to increment .nchildren only if create_tree() returned a value > 0. After i changed both loops, i get from grub-mkrescue an ISO, where i can mount and explore /dev/sdb3 (via GPT) without i/o error. http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/1298/libisofs/hfsplus.c -------------------------------------------------------------------- Have a nice day :) Thomas