From: Phillip Susi <psusi@cfl.rr.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Cc: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
Subject: Re: Raid5 regression
Date: Wed, 04 May 2011 14:37:13 -0400 [thread overview]
Message-ID: <4DC19CD9.20702@cfl.rr.com> (raw)
In-Reply-To: <4DC16F14.1040505@gmail.com>
On 5/4/2011 11:21 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Does it happen with grub-fstest ? Some BIOSes are known to chop away
> some sectors in the end of disk.
That seems to be what is going on. I went back to the Maverick version
of grub and it gets no complaints, until I set debug=raid. Then I can
see the same type of messages about the duplicate detection.
Comparing the two versions of raid.c, it looks like the old version just
made the debug print when it found the duplicate superblock, and then
carried on, replacing the previously found device. The new version of
insert_array() returns a grub_error().
So the net result is that even though it always was detecting the
superblock on both the whole disk and on the partition, it used to let
the one found on the partition supersede so everything worked, but now
it keeps the one on the whole disk and so things break.
How should this conflict be resolved? I would think that the partition
should take precedence like it used to.
next prev parent reply other threads:[~2011-05-04 18:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-03 14:33 Raid5 regression Phillip Susi
2011-05-03 15:30 ` Phillip Susi
2011-05-03 20:39 ` Phillip Susi
2011-05-03 21:15 ` Jérôme Poulin
2011-05-04 6:17 ` Vladimir 'φ-coder/phcoder' Serbinenko
2011-05-04 11:23 ` Goswin von Brederlow
2011-05-04 13:49 ` Phillip Susi
2011-05-04 15:09 ` Phillip Susi
2011-05-04 15:21 ` Vladimir 'φ-coder/phcoder' Serbinenko
2011-05-04 18:37 ` Phillip Susi [this message]
2011-05-04 19:01 ` Goswin von Brederlow
2011-05-04 20:23 ` Vladimir 'φ-coder/phcoder' Serbinenko
2011-05-05 14:38 ` Phillip Susi
2011-05-05 16:57 ` Goswin von Brederlow
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=4DC19CD9.20702@cfl.rr.com \
--to=psusi@cfl.rr.com \
--cc=grub-devel@gnu.org \
--cc=phcoder@gmail.com \
/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.