From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VdIxv-0002gh-Cd for mharc-grub-devel@gnu.org; Mon, 04 Nov 2013 07:09:07 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdIxl-0002UB-HC for grub-devel@gnu.org; Mon, 04 Nov 2013 07:09:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VdIxd-0005Ux-07 for grub-devel@gnu.org; Mon, 04 Nov 2013 07:08:57 -0500 Received: from mail-la0-x229.google.com ([2a00:1450:4010:c03::229]:40776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdIxc-0005Uk-OF for grub-devel@gnu.org; Mon, 04 Nov 2013 07:08:48 -0500 Received: by mail-la0-f41.google.com with SMTP id el20so5388009lab.28 for ; Mon, 04 Nov 2013 04:08:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=y5zvaDO7aHKbNdq9cUe2qfnG3LVFqgnS4Wu02x3irMI=; b=RCZDW4paOP3/KTNtzUggxMSQLK5a/vqSFHhdgWcEVBxkcgBo/HJ2NUr/A1tdz8IdVg C6Ncpw5TC3XJRwDz1O9ZfvJ0sgaMvAQ8OkdBIIdDse7b+3C/Cmo8FPjxQdSi/0R1325H 7EDU1XQxw3i3CpFc2LIPt47nHomaMOGJ5VuimLOhmX2iMBcwT5Goq4rkIyFysgF5luXW EiJox3JhuzhAaWprp0vJEs06RYdrAcEkLG04broRDjXRqrFVzRuH2yhfSACL+Ts5Owa1 mmwr3n1q0oDC2wSH2M1R2j33avZ1Y1wiHk3Ziqmy+2s04PPNdPlEhqKOiSEAs0mz8WBR 4sTg== X-Received: by 10.112.128.166 with SMTP id np6mr11198529lbb.7.1383566926953; Mon, 04 Nov 2013 04:08:46 -0800 (PST) Received: from opensuse.site (ppp91-76-174-89.pppoe.mtu-net.ru. [91.76.174.89]) by mx.google.com with ESMTPSA id k3sm10272472lbs.0.2013.11.04.04.08.46 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 04 Nov 2013 04:08:46 -0800 (PST) Date: Mon, 4 Nov 2013 16:08:43 +0400 From: Andrey Borzenkov To: The development of GNU GRUB Subject: Re: How important is the MBR partition offset of grub-mkrescue ? Message-ID: <20131104160843.5c0cabd2@opensuse.site> In-Reply-To: <1974651407333528403@scdbackup.webframe.org> References: <52767048.9050902@gmail.com> <1974651407333528403@scdbackup.webframe.org> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.18; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::229 Cc: linux-hotplug@vger.kernel.org, scdbackup@gmx.net 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 12:09:06 -0000 В Sun, 03 Nov 2013 18:16:09 +0100 "Thomas Schmitt" пишет: > Hi, > > i believe to have found the udev rules in Debian 6 which > govern the population of /dev/disk/by-label. > > File > /lib/udev/rules.d/60-persistent-storage.rules > has > # probe filesystem metadata of disks > KERNEL!="sr*", IMPORT{program}="/sbin/blkid -o udev -p $tempnode" > ... > ENV{ID_FS_LABEL_ENC}=="?*", ENV{ID_FS_USAGE}=="filesystem|other", \ > SYMLINK+="disk/by-label/$env{ID_FS_LABEL_ENC}" > > I understand that if blkid sets variable ID_FS_LABEL_ENC to > a non-empty value, then this will become the link name in ./by-label. > The link target is the device that is being examined by the rule. > > From a USB stick with partition start LBA 1, i get: > > $ /sbin/blkid -o udev -p /dev/sdb > ID_PART_TABLE_TYPE=dos > ID_FS_LABEL=epidemic-4.1-b1-1-ts-amd64 > ID_FS_LABEL_ENC=epidemic-4.1-b1-1-ts-amd64 > ID_FS_TYPE=iso9660 > ID_FS_USAGE=filesystem > $ /sbin/blkid -o udev -p /dev/sdb1 > $ > > So why the hell does /dev/sdb1 become link target ? > Its ID_FS_LABEL_ENC must be empty. > > Any idea how to get a verbous log of these decisions ? > 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.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. I'm interested in which information actually needs to be imported from parent. May be it should be less aggressive. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrey Borzenkov Date: Mon, 04 Nov 2013 12:08:43 +0000 Subject: Re: How important is the MBR partition offset of grub-mkrescue ? Message-Id: <20131104160843.5c0cabd2@opensuse.site> List-Id: References: <52767048.9050902@gmail.com> <1974651407333528403@scdbackup.webframe.org> In-Reply-To: <1974651407333528403@scdbackup.webframe.org> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: base64 To: The development of GNU GRUB Cc: linux-hotplug@vger.kernel.org, scdbackup@gmx.net 9yBTdW4sIDAzIE5vdiAyMDEzIDE4OjE2OjA5ICswMTAwCiJUaG9tYXMgU2NobWl0dCIgPHNjZGJh Y2t1cEBnbXgubmV0PiDQydvF1DoKCj4gSGksCj4gCj4gaSBiZWxpZXZlIHRvIGhhdmUgZm91bmQg dGhlIHVkZXYgcnVsZXMgaW4gRGViaWFuIDYgd2hpY2gKPiBnb3Zlcm4gdGhlIHBvcHVsYXRpb24g b2YgL2Rldi9kaXNrL2J5LWxhYmVsLgo+IAo+IEZpbGUKPiAgIC9saWIvdWRldi9ydWxlcy5kLzYw LXBlcnNpc3RlbnQtc3RvcmFnZS5ydWxlcwo+IGhhcwo+ICAgIyBwcm9iZSBmaWxlc3lzdGVtIG1l dGFkYXRhIG9mIGRpc2tzCj4gICBLRVJORUwhPSJzcioiLCBJTVBPUlR7cHJvZ3JhbX09Ii9zYmlu L2Jsa2lkIC1vIHVkZXYgLXAgJHRlbXBub2RlIgo+ICAgLi4uCj4gICBFTlZ7SURfRlNfTEFCRUxf RU5DfT0iPyoiLCAgICAgRU5We0lEX0ZTX1VTQUdFfT0iZmlsZXN5c3RlbXxvdGhlciIsIFwKPiAg ICAgICAgICAgU1lNTElOSys9ImRpc2svYnktbGFiZWwvJGVudntJRF9GU19MQUJFTF9FTkN9Igo+ IAo+IEkgdW5kZXJzdGFuZCB0aGF0IGlmIGJsa2lkIHNldHMgdmFyaWFibGUgSURfRlNfTEFCRUxf RU5DIHRvCj4gYSBub24tZW1wdHkgdmFsdWUsIHRoZW4gdGhpcyB3aWxsIGJlY29tZSB0aGUgbGlu ayBuYW1lIGluIC4vYnktbGFiZWwuCj4gVGhlIGxpbmsgdGFyZ2V0IGlzIHRoZSBkZXZpY2UgdGhh dCBpcyBiZWluZyBleGFtaW5lZCBieSB0aGUgcnVsZS4KPiAKPiBGcm9tIGEgVVNCIHN0aWNrIHdp dGggcGFydGl0aW9uIHN0YXJ0IExCQSAxLCBpIGdldDoKPiAKPiAgICQgL3NiaW4vYmxraWQgLW8g dWRldiAtcCAvZGV2L3NkYiAKPiAgIElEX1BBUlRfVEFCTEVfVFlQRT1kb3MKPiAgIElEX0ZTX0xB QkVMPWVwaWRlbWljLTQuMS1iMS0xLXRzLWFtZDY0Cj4gICBJRF9GU19MQUJFTF9FTkM9ZXBpZGVt aWMtNC4xLWIxLTEtdHMtYW1kNjQKPiAgIElEX0ZTX1RZUEU9aXNvOTY2MAo+ICAgSURfRlNfVVNB R0U9ZmlsZXN5c3RlbQo+ICAgJCAvc2Jpbi9ibGtpZCAtbyB1ZGV2IC1wIC9kZXYvc2RiMQo+ICAg JAo+IAo+IFNvIHdoeSB0aGUgaGVsbCBkb2VzIC9kZXYvc2RiMSBiZWNvbWUgbGluayB0YXJnZXQg Pwo+IEl0cyBJRF9GU19MQUJFTF9FTkMgbXVzdCBiZSBlbXB0eS4KPiAKPiBBbnkgaWRlYSBob3cg dG8gZ2V0IGEgdmVyYm91cyBsb2cgb2YgdGhlc2UgZGVjaXNpb25zID8KPiAKCkkgY29uZmlybSB0 aGlzLiBUaGUgY3VscHJpdCBpcyB0aGlzIHJ1bGUgaW4gNjAtcGVyc2lzdGVudC1zdG9yYWdlLnJ1 bGVzOgoKIyBmb3IgcGFydGl0aW9ucyBpbXBvcnQgcGFyZW50IGluZm9ybWF0aW9uCkVOVntERVZU WVBFfT0icGFydGl0aW9uIiwgSU1QT1JUe3BhcmVudH09IklEXyoiCgpJJ20gbm90IHJlYWxseSBz dXJlIGhvdyBleGFjdGx5IHRvIGZpeCBpdC4gSS5lLiBub3JtYWxseSBpdCBpcyBhc3N1bWVkCnRo YXQgZGV2aWNlIGlzIGVpdGhlciBwYXJ0aXRpb25lZCBvciBub3QuIFNpdHVhdGlvbiB3aGVuIHdl IGhhdmUKZmlsZXN5c3RlbSBvbiBhIHdob2xlIGRpc2sgKmFuZCogaW5kaXZpZHVhbCBwYXJ0aXRp b25zIC4uLiBub3Qgc3VyZS4KCkknbSBpbnRlcmVzdGVkIGluIHdoaWNoIGluZm9ybWF0aW9uIGFj dHVhbGx5IG5lZWRzIHRvIGJlIGltcG9ydGVkIGZyb20KcGFyZW50LiBNYXkgYmUgaXQgc2hvdWxk IGJlIGxlc3MgYWdncmVzc2l2ZS4KLS0KVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNl bmQgdGhlIGxpbmUgInVuc3Vic2NyaWJlIGxpbnV4LWhvdHBsdWciIGluCnRoZSBib2R5IG9mIGEg bWVzc2FnZSB0byBtYWpvcmRvbW9Admdlci5rZXJuZWwub3JnCk1vcmUgbWFqb3Jkb21vIGluZm8g YXQgIGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbA==