On 5/4/2011 4:23 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
Ideally by using 1.1 metadata. It's in the end of the device but
contains enough data to unambigously tell if it belongs to disk or
partition.
You mean 1.0? I guess I'll have to try that.
On 03.05.2011 23:15, Jérôme Poulin wrote:
On Tue, May 3, 2011 at 4:39 PM, Phillip Susi ps...@cfl.rr.com wrote:
After enabling raid debug output and then loading mdraid09.mod, I can see
that it is scanning and detecting the superblock on both (hdx) and
(hdx,msdos1).
I've had this problem too,
Phillip Susi ps...@cfl.rr.com writes:
After enabling raid debug output and then loading mdraid09.mod, I can
see that it is scanning and detecting the superblock on both (hdx) and
(hdx,msdos1).
On 5/3/2011 10:33 AM, Phillip Susi wrote:
After upgrading an Ubuntu server from Maverick to Natty
On 5/4/2011 7:23 AM, Goswin von Brederlow wrote:
That is a problem mdadm has (had?) too. The problem arises when the
alignment of the partition and its size causes the metadata of the
partition to be also valid for the disk (as in the partition ends
exactly at the end of the disk).
One of the
Something has gone wrong with the disk size detection. Grub thinks the
size of the disk is 488396800 sectors instead of the 488397168 that
fdisk reports. This shorter size causes the partition to appear to run
right up to the end of the disk and thus, the raid superblock is found
both at the
On 04.05.2011 17:09, Phillip Susi wrote:
Something has gone wrong with the disk size detection. Grub thinks
the size of the disk is 488396800 sectors instead of the 488397168
that fdisk reports. This shorter size causes the partition to appear
to run right up to the end of the disk and thus,
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
Phillip Susi ps...@cfl.rr.com writes:
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
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.
Now it breaks less then
After upgrading an Ubuntu server from Maverick to Natty ( grub2 version
1.99-rc1-13ubuntu3 ) the system no longer will boot. Grub complains
about the raid5 array:
error: Found two disks with the index 0 for RAID md0
error: Found two disks with the index 1 for RAID md0
error: Found two disks
Wasn't there a change made recently to support the new md metadata
formats? I wonder if that is causing grub to detect the raid superblock
both at the end of the physical disk, as well as within the partition,
causing it to see the members twice?
On 5/3/2011 10:33 AM, Phillip Susi wrote:
After enabling raid debug output and then loading mdraid09.mod, I can
see that it is scanning and detecting the superblock on both (hdx) and
(hdx,msdos1).
On 5/3/2011 10:33 AM, Phillip Susi wrote:
After upgrading an Ubuntu server from Maverick to Natty ( grub2 version
1.99-rc1-13ubuntu3 ) the
On Tue, May 3, 2011 at 4:39 PM, Phillip Susi ps...@cfl.rr.com wrote:
After enabling raid debug output and then loading mdraid09.mod, I can see
that it is scanning and detecting the superblock on both (hdx) and
(hdx,msdos1).
I've had this problem too, it is a bug that should be fixed, phcoder
13 matches
Mail list logo