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.