From: "Thomas Schmitt" <scdbackup@gmx.net>
To: grub-devel@gnu.org
Subject: Re: How important is the MBR partition offset of grub-mkrescue ?
Date: Mon, 04 Nov 2013 15:03:45 +0100 [thread overview]
Message-ID: <5455651330173591329@scdbackup.webframe.org> (raw)
In-Reply-To: <20131104160843.5c0cabd2@opensuse.site>
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
next prev parent reply other threads:[~2013-11-04 14:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-02 18:57 How important is the MBR partition offset of grub-mkrescue ? Thomas Schmitt
2013-11-02 23:42 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-11-03 12:21 ` Thomas Schmitt
2013-11-03 13:05 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-11-03 15:21 ` Thomas Schmitt
2013-11-03 15:48 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-11-03 16:19 ` Thomas Schmitt
2013-11-03 16:32 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-11-03 17:16 ` Thomas Schmitt
2013-11-04 12:08 ` Andrey Borzenkov
2013-11-04 14:03 ` Thomas Schmitt [this message]
2013-11-04 14:10 ` Andrey Borzenkov
2013-11-04 14:21 ` Thomas Schmitt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5455651330173591329@scdbackup.webframe.org \
--to=scdbackup@gmx.net \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).