From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VdKm4-0003B1-6A for mharc-grub-devel@gnu.org; Mon, 04 Nov 2013 09:05:00 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42015) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdKlv-00031Q-Jw for grub-devel@gnu.org; Mon, 04 Nov 2013 09:04:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VdKlo-0003bL-1U for grub-devel@gnu.org; Mon, 04 Nov 2013 09:04:51 -0500 Received: from mout.gmx.net ([212.227.15.18]:59939) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdKln-0003ZT-Oa for grub-devel@gnu.org; Mon, 04 Nov 2013 09:04:43 -0500 Received: from scdbackup.webframe.org ([87.167.191.213]) by mail.gmx.com (mrgmx003) with ESMTP (Nemesis) id 0LxgM7-1Vj10M3HeV-017G1w for ; Mon, 04 Nov 2013 15:04:41 +0100 Date: Mon, 04 Nov 2013 15:03:45 +0100 From: "Thomas Schmitt" To: grub-devel@gnu.org Subject: Re: How important is the MBR partition offset of grub-mkrescue ? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <20131104160843.5c0cabd2@opensuse.site> In-Reply-To: <20131104160843.5c0cabd2@opensuse.site> Message-Id: <5455651330173591329@scdbackup.webframe.org> X-Provags-ID: V03:K0:HNIAbu4ttdidjxTe52iOPtZ9TA+mtpLFJmM3QcHh/r+H95mdU+r W60asjV8l2wh6ch63nbjAZfjUEUu+Vslc1FTKHDkc8nj16fhCPUbVK8V/p49HzzMW5uEsh4 iJoa2LK0Qy4FH8yE757C5HrlVTa1eeUjtsTTyPh+6W8cutkDUH5qwC/PY5pM9MBChk2QB4V w3K9QmN7VsFQkayOpe2og== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 212.227.15.18 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: Mon, 04 Nov 2013 14:04:59 -0000 Hi, Andrey Borzenkov: > I confirm this. The culprit is this rule in 60-persistent-storage.rules: > > # for partitions import parent information > ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*" > > I'm not really sure how exactly to fix it. [...] > I'm interested in which information actually needs to be > imported from parent. May be it should be less aggressive. In its broadness it looks like a mistake. Bringing the filesystem label from the overall device to the partition makes few sense. I cannot spot a rule that would exclude DEVTYPE "disk" from ./by-label. So i assume that the partition link overwrote the device link. I am very unkeen with udev. Just imitating a skilled programmer i think that this could be a fix: ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*", \ ENV{ID_FS_LABEL}="" , ENV{ID_FS_LABEL_ENC}="" , \ ENV{ID_FS_TYPE}="" , ENV{ID_FS_USAGE}="" I am not sure whether ID_PART_TABLE_TYPE is intended to propagate from storage device to partition. At least it could make some sense. Ok. Bold try. Adding the setters to the parent import. Running udevadm control --reload-rules. Plugging stick with partition start LBA 1. Success ! epidemic-4.1-b1-1-ts-amd64 -> ../../sdb So it seems that really the "disk" link was overwritten by the "partition" link. This will still happen if grub-mkrescue was used with extra option -partition_offset 16. But in that case it is intentional and beautifying. (And even if it does not happen, it makes no difference.) > I.e. normally it is assumed that device is either partitioned or not. > Situation when we have filesystem on a whole disk *and* individual > partitions ... not sure. Obviously this was not foreseen when the rules were written. Is there an upstream with whom one could discuss this issue and who - in best case - could propagate an improvement downstream ? Can GRUB2 do advertising for above change in the rule set ? Have a nice day :) Thomas