All of lore.kernel.org
 help / color / mirror / Atom feed
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



  reply	other threads:[~2013-11-04 14:05 UTC|newest]

Thread overview: 15+ 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 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
2013-11-04 15:44               ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.