From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1RrDwX-0004BD-EG for mharc-grub-devel@gnu.org; Sat, 28 Jan 2012 14:28:09 -0500 Received: from eggs.gnu.org ([140.186.70.92]:55522) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrDwU-00048u-HZ for grub-devel@gnu.org; Sat, 28 Jan 2012 14:28:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RrDwT-0005nq-Ds for grub-devel@gnu.org; Sat, 28 Jan 2012 14:28:06 -0500 Received: from mail-wi0-f169.google.com ([209.85.212.169]:60630) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrDwT-0005nj-42 for grub-devel@gnu.org; Sat, 28 Jan 2012 14:28:05 -0500 Received: by wibhj13 with SMTP id hj13so2890795wib.0 for ; Sat, 28 Jan 2012 11:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=AR4AYN3/jiWOpbvGhaVTcW5GCV+Ii99HIXHYO9svj8c=; b=LOwpytLpHGwXxEEXEavu72sLtJzFHBUJBlVSVJKmy/U0kxfQC6Rxc91ZiUaXx9DdZY bCfJlkA0MY+8TjTD/zElu/jNxmQm1EGYDxqPyOyLvb4cSmHB1GgA7EN9OL9rLJCRoZ4Y PBywTkST9qDmjyOBUyS7/4rzABbm8/ffzbW4w= Received: by 10.180.93.132 with SMTP id cu4mr19061696wib.9.1327778883261; Sat, 28 Jan 2012 11:28:03 -0800 (PST) Received: from fedora.x201.phnet (94-26.62-81.cust.bluewin.ch. [81.62.26.94]) by mx.google.com with ESMTPS id ho4sm19702160wib.3.2012.01.28.11.28.01 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 28 Jan 2012 11:28:02 -0800 (PST) Message-ID: <4F244C3F.4020102@gmail.com> Date: Sat, 28 Jan 2012 20:27:59 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: [Patch] Robustly search for ZFS labels & uberblocks References: <4E838F85.6060001@gmail.com> <1326973014.6387.224.camel@watermelon.coderich.net> <4F1C1ABD.1010303@gmail.com> <1327719035.9477.68.camel@watermelon.coderich.net> <4F23EF3C.9050407@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.212.169 Cc: Darik Horn , Richard Laager , Zachary Bedell 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, 28 Jan 2012 19:28:07 -0000 On 28.01.2012 19:40, Darik Horn wrote: > 2012/1/28 Vladimir 'φ-coder/phcoder' Serbinenko: >> I already commented on 10_linux.in changes. They are pretty sloppy. (mostly >> is "it works for me and I don't care about other legitimate configs") > How do you want these things changed? I searched the email archive > and couldn't find where you gave an example of another legitimate > configuration, or suggested to how improve any of the related > submissions by Robert Millan, Richard Laager, or Zachary Bedell. Even if I didn't do before (I didn't recheck), I did it in another message in this thread > Keep in mind that ZoL cannot resolve the grub mdnobj number, or use > the Solaris bootpath or devid. The only thing that matters on the > Linux command line is the pool name, and everything else is for > interface compatibility with Solaris. Even this is already one piece of info which will be resolved wrong. (Also note that if you need only this particular info you should probably consider zfsinfo. In this case it doesn't matter because it's still wrong though) > Also note that this code is in the latest ZFS patch: > > if (strcmp (name, "mirror")&& !sscanf (name, "mirror-%u",&dummy) > && !sscanf (name, "raidz%u",&dummy) > > That format doesn't match the `zpool status` output on my current > Solaris and Linux computers. The vdev names now have the RAID level > number and a dash character like this: > > raidz1-0 > raidz1-1 > raidz2-0 > raidz3-0 Does adding "&& !sscanf (name, "raidz1-%u",&dummy)&& && !sscanf (name, "raidz2-%u",&dummy)&& !sscanf (name, "raidz3-%u",&dummy)" resolve this problem? -- Regards Vladimir 'φ-coder/phcoder' Serbinenko