Re: Bug#597563: grub-common: grub-probe segfaults scanning lvm devices

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig57187BA8571BB9342AE57BB3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

As was recommended I forward the remaining part to linux-raid mailing lis=
t.
In short: on his system mdraid, raid5, 4 devices, metadata (presumably)
0.90, two devices have index 0.
If such situation is valid please advice me on how such situation should
be handled.
@Matthew: could you supply mdadm -Q outputput and *last* 64K of every dis=
k?
On 01/08/2011 05:08 AM, Matthew Gabeler-Lee wrote:
> On Fri, 7 Jan 2011, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
>> I believe it to be a problem with raid5. Could you try the latest
>> upstream? If problem persists I would need following dumps:
>> dd if=3D/dev/sd[abcd]3 of=3D[abcd].img bs=3D1024 count=3D64
>> dd if=3D/dev/md2 of=3D2.img bs=3D1024 count=3D64
>> grub-fstest -c 4 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3 hex -l
>> '(md2)+128' > g2.img
>
> OK, built grub from latest bzr trunk.
>
> From my past workarounds, I effectively have a list of all the
> invocations of grub-probe that grub-install/grub-setup runs on my
> system. Most of those work fine now. The only thing that isn't fine
> is that most invocations spit out a message "error: found two disks
> with the number 0" but give a correct answer and exit successfully.
>
> If I run grub-probe with enough --verbose arguments, then that message
> gets this context:
>
> grub-core/disk/raid.c:699: Scanning for RAID devices on disk hd2
> grub-core/kern/disk.c:245: Opening `hd2'...
> ./grub-probe: info: the size of hd2 is 1465149168.
> error: found two disks with the number 0.
> grub-core/kern/disk.c:330: Closing `hd2'.
>
> So, it seems maybe you're right that there's something funky with the
> raid5. The outputs you requested are attached. The grub-fstest
> invocation complained that -l is not a valid option, I hope the output
> without it is still what you want / need. I included the full output
> of one of the complaining grub-probe invocations too, on the guess
> that it might be helpful.
>
> FWIW, the raid5 array in question has had every disk swapped at least
> once in its life span, including from growing from 3 to 4 disks, and
> from smaller to larger disks, not to mention one or two disk failures
> along the way.
>


--=20
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



--------------enig57187BA8571BB9342AE57BB3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF0EAREKAAYFAk0oW3kACgkQNak7dOguQglp4AD4unhg3tQazNTyMUtLCbt7 y9mu
bPoALYb6oYtTT7EihAEAgDIELSFp+3hkU8wlKh1mXq+zRDJIyJIPJHzZEgoz 4HI=
=/mif
-----END PGP SIGNATURE-----

--------------enig57187BA8571BB9342AE57BB3--
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Bug#597563: grub-common: grub-probe segfaults scanning lvm devices

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

---1371069890-1362913481-1294527255=:14736
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Sat, 8 Jan 2011, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

> As was recommended I forward the remaining part to linux-raid mailing lis=
t.
> In short: on his system mdraid, raid5, 4 devices, metadata (presumably)
> 0.90, two devices have index 0.
> If such situation is valid please advice me on how such situation should
> be handled.
> @Matthew: could you supply mdadm -Q outputput and *last* 64K of every dis=
k?

$ sudo mdadm -QD /dev/md2
/dev/md2:
Version : 0.90
Creation Time : Mon Mar 27 14:04:18 2006
Raid Level : raid5
Array Size : 2185667136 (2084.41 GiB 2238.12 GB)
Used Dev Size : 728555712 (694.80 GiB 746.04 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 2
Persistence : Superblock is persistent

Update Time : Sat Jan 8 17:40:20 2011
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 64K

UUID : 01e2f978:88d1f867:34e1e46c:f3c01470
Events : 0.32040050

Number Major Minor RaidDevice State
0 8 35 0 active sync /dev/sdc3
1 8 19 1 active sync /dev/sdb3
2 8 3 2 active sync /dev/sda3
3 8 51 3 active sync /dev/sdd3

The actual last 64k of all the partitions in the array is all zeros.=20
So is the 64k up to the end of the "Used Dev Size". What has some data=20
in it is the 64k after that. I hope that has the superblock data I=20
presume you're looking for. I.e. dd if=3D/dev/sdX3 bs=3D1024=20
skip=3D728555712 count=3D64.

--=20
=09-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG pubkey fingerprint: A57F B354 FD30 A502 795B 9637 3EF1 3F22 A85E 2AD1
---1371069890-1362913481-1294527255=:14736
Content-Type: APPLICATION/octet-stream; name=last64k.tar.bz2
Content-Transfer-Encoding: BASE64
Content-ID:
Content-Description:
Content-Disposition: attachment; filename=last64k.tar.bz2

QlpoOTFBWSZTWc8QUogACmB/3//ADkpoWf+EBEcAVH7u3kQAUAApQABABKAA
dGAJfMAB/AABw00wQyGmmRkwgGmgDCaNMmABA0OGmmCGQ00yMmEA00AYTRpk
wAIGhw00wQyGmmRkwgGmgDCaNMmABA0CpIiIyjU8U8TSMPUNRkYGQDQaGiaN
N6oeyp3Nc5jBMTeijKZdg4+U0nlMZ16M2qcWgtukxmbMYTKVERiURCSpSVjN
+KOkdOPCcEcUYxMRWzJuGUq1rl4vF4yRhFIqEcBQgQ+Pw57xm/Xu96sIzC5v
N9R19oyReKRO5RKKiQDTJgdmXjlP9ylyjSck8+EMhksksWyC8J4TkNsukqsK
SdBqtE+RUceibsc8YRvcdo850dEw5z2G8dkqM51mybqB7D26DakmCopki0Wt
F7GjtReLsM+gxSjLGHv5vh8csY545knQbmGO4xi0VLZy/JCjaNs2y7GOYqSj
WWSbWxJ1IWvVe638npfR9TunC6j5mYnDDUXPy/7xTSfY7w/sbJ0ozn1P6lp8
jCH3j7bA4Ib6o+8b549RXpNNqnTNJUazUeY5TVOI4U/DGTVlNmaSjUVJEkk1
muFp/4u5IpwoSGeIKUQA

---1371069890-1362913481-1294527255=:14736--

Re: Bug#597563: grub-common: grub-probe segfaults scanning lvm devices

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4BB0777A03C9D191B18B8D12
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 01/08/2011 11:53 PM, Matthew Gabeler-Lee wrote:
> On Sat, 8 Jan 2011, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
>> As was recommended I forward the remaining part to linux-raid mailing
>> list.
>> In short: on his system mdraid, raid5, 4 devices, metadata (presumably=
)
>> 0.90, two devices have index 0.
>> If such situation is valid please advice me on how such situation shou=
ld
>> be handled.
>> @Matthew: could you supply mdadm -Q outputput and *last* 64K of every
>> disk?
>
Sorry, I've noticed that I've looked into the wrong place all the long.
md2 is fine. I suppose it's a problem with md0 (all mdraid are assembled
at the beginning). Since md0 is raid1, its misassembly wouldn't have any
influence (we don't write to devices). mdstat lists both md0 and md1 as
having no duplicate indices. I would need info on md0 for this (now
minor) remaining bug.
> $ sudo mdadm -QD /dev/md2
> /dev/md2:
> Version : 0.90
> Creation Time : Mon Mar 27 14:04:18 2006
> Raid Level : raid5
> Array Size : 2185667136 (2084.41 GiB 2238.12 GB)
> Used Dev Size : 728555712 (694.80 GiB 746.04 GB)
> Raid Devices : 4
> Total Devices : 4
> Preferred Minor : 2
> Persistence : Superblock is persistent
>
> Update Time : Sat Jan 8 17:40:20 2011
> State : clean
> Active Devices : 4
> Working Devices : 4
> Failed Devices : 0
> Spare Devices : 0
>
> Layout : left-symmetric
> Chunk Size : 64K
>
> UUID : 01e2f978:88d1f867:34e1e46c:f3c01470
> Events : 0.32040050
>
> Number Major Minor RaidDevice State
> 0 8 35 0 active sync /dev/sdc3
> 1 8 19 1 active sync /dev/sdb3
> 2 8 3 2 active sync /dev/sda3
> 3 8 51 3 active sync /dev/sdd3
>
> The actual last 64k of all the partitions in the array is all zeros.
> So is the 64k up to the end of the "Used Dev Size". What has some
> data in it is the 64k after that. I hope that has the superblock data
> I presume you're looking for. I.e. dd if=3D/dev/sdX3 bs=3D1024
> skip=3D728555712 count=3D64.
>


--=20
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



--------------enig4BB0777A03C9D191B18B8D12
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREKAAYFAk0o9IwACgkQNak7dOguQgnH5wEAmJY4L9OSFOL6A93ufvZH K6B7
iV6lo8smLTvwuOrfnXsA/jq+wIyet9K6r/0ZKzrVnJjEKC7KceEFsTeIRmql cfYO
=lcJ7
-----END PGP SIGNATURE-----

--------------enig4BB0777A03C9D191B18B8D12--
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Bug#597563: grub-common: grub-probe segfaults scanning lvm devices

This is a multi-part message in MIME format.
--------------030002090204090605050507
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1/8/2011 18:34, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Sorry, I've noticed that I've looked into the wrong place all the long.
> md2 is fine. I suppose it's a problem with md0 (all mdraid are assembled
> at the beginning). Since md0 is raid1, its misassembly wouldn't have any
> influence (we don't write to devices). mdstat lists both md0 and md1 as
> having no duplicate indices. I would need info on md0 for this (now
> minor) remaining bug.
$ sudo mdadm -QD /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Mon Mar 27 14:03:04 2006
Raid Level : raid1
Array Size : 2008000 (1961.27 MiB 2056.19 MB)
Used Dev Size : 2008000 (1961.27 MiB 2056.19 MB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Sat Jan 8 18:35:47 2011
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0

UUID : 9364f7a2:d74695d5:7d8db3a0:3b5f9e48
Events : 0.10758124

Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
2 8 1 2 active sync /dev/sda1
3 8 49 3 active sync /dev/sdd1

Output of "for i in a b c d ; do sudo dd if=/dev/sd${i}1
of=sd${i}1.last64k.img skip=$((2008000)) bs=1024 count=64 ; done" is attached.

--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG pubkey fingerprint: A57F B354 FD30 A502 795B 9637 3EF1 3F22 A85E 2AD1


--------------030002090204090605050507
Content-Type: application/octet-stream;
name="last64k.md0.tar.bz2"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="last64k.md0.tar.bz2"

QlpoOTFBWSZTWQcPIEcAClT///3AIkFgyf+MBUOkFP7ungZAAhoBXSAIAEAE goAARAOcwAHc
AAOMjTJiaDJkwmmQMhoDQGmTQwAmgMcZGmTE0GTJhNMgZDQGgNMmhgBNAY4y NMmJoMmTCaZA
yGgNAaZNDACaAwVJTREyFHhT9UbRB6ZIeoYRtR6Zqj1BjJtJpPUeZTpNR0jX jGaw9Oc3zjNJ
4dgum/9JdtkyZCxiKIi8oiElSkrdjwReNyPKfXFofKLxmNsq668Wi0WjWi+K RSQsUREg3ign
Bw7WW6+NYcJg3MIwjw5TCLIn1USiiQDiKjkO7iMQviXl90Li6wtCbBUSqXVE 8xpuI0GWOeLI
7hunefobJmKjYjIZsyyRniiRuH6+g+SSXqilRj5ebPkwjLGONmNrLFm8Xx4o rYONRS4xxNrJ
iXxWSLRi7y2ufdC/HiipL85RxlGg6CxqNGX/dGsTsOsuj6MUnTC61Vn90W0G o5HUwPG33rMp
PshccHd1ToL46zzD3jXjKdB/RaHZGA3Ycu4ujsjsPgYf+VvGk7TUc5pO0Y/+ O8zQsdx3n5nM
feYppKkSSSajSTA+Iu5IpwoSAOHkCOA=
--------------030002090204090605050507--
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Bug#597563: grub-common: grub-probe segfaults scanning lvm devices

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig62A84A63D98987118FE2EF6F
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 01/09/2011 12:38 AM, Matthew Gabeler-Lee wrote:
> On 1/8/2011 18:34, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> Sorry, I've noticed that I've looked into the wrong place all the long=

>> md2 is fine. I suppose it's a problem with md0 (all mdraid are assembl=
ed
>> at the beginning). Since md0 is raid1, its misassembly wouldn't have a=
ny
>> influence (we don't write to devices). mdstat lists both md0 and md1 a=
s
>> having no duplicate indices. I would need info on md0 for this (now
>> minor) remaining bug.
I have a hypothesis. Does last partition on any device span, s.t. it
leaves less than 64K after it until the end of device? If so then GRUB
sees the same metadata sector as the one at the end of device and as at
the end of partition. With 1.x metadata sector contains its own location
on the device. With 0.90 I can see no such field. Is there a way to
check for such condition with 0.90?

--=20
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



--------------enig62A84A63D98987118FE2EF6F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREKAAYFAk0o+WAACgkQNak7dOguQgnLqgD/WDmjE7uCa4ouxMkxvroM YEtE
nftIyRbBws+K4RZHNCYBAIHsBdlyqVJcalcsTGliG1eevoh2RdTcKdYbm/ND rRa8
=jBf8
-----END PGP SIGNATURE-----

--------------enig62A84A63D98987118FE2EF6F--
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Bug#597563: grub-common: grub-probe segfaults scanning lvm devices

On 1/8/2011 18:55, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> I have a hypothesis. Does last partition on any device span, s.t. it
> leaves less than 64K after it until the end of device? If so then GRU=
B
> sees the same metadata sector as the one at the end of device and as =
at
> the end of partition. With 1.x metadata sector contains its own locat=
ion
> on the device. With 0.90 I can see no such field. Is there a way to
> check for such condition with 0.90?
I created the last partition on each disk running as close to the end o=
f the=20
disk as fdisk would allow. Since the partitions were created on cylind=
er=20
boundaries, however, it looks like the last partition ends 2MB before t=
he=20
end of the physical device. Reading the data between the end of the la=
st=20
partition and the end of the disk gives all zeros for three of the four=
=20
disks, but /dev/sdb gives what looks like it might have an mdraid super=
block=20
in it:

$ sudo fdisk -lu /dev/sdb

Disk /dev/sdb: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
Units =3D sectors of 1 * 512 =3D 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x994d834b

Device Boot Start End Blocks Id System
/dev/sdb1 * 63 4016249 2008093+ fd Linux raid auto=
detect
/dev/sdb2 4016250 8032499 2008125 fd Linux raid auto=
detect
/dev/sdb3 8032500 1465144064 728555782+ fd Linux raid auto=
detect
$ sudo dd if=3D/dev/sdb bs=3D512 skip=3D1465144064 2>/dev/null | hd
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |..........=
.....|
*
00260000 fc 4e 2b a9 00 00 00 00 5a 00 00 00 03 00 00 00 |.N+.....Z.=
.....|
00260010 00 00 00 00 a2 f7 64 93 e8 36 28 44 01 00 00 00 |......d..6=
(D....|
00260020 80 f3 0e 00 03 00 00 00 02 00 00 00 00 00 00 00 |..........=
.....|
00260030 00 00 00 00 d5 95 46 d7 a0 b3 8d 7d 48 9e 5f 3b |......F...=
}H._;|
00260040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |..........=
.....|
*
00260080 6f 90 65 49 01 00 00 00 02 00 00 00 03 00 00 00 |o.eI......=
.....|
00260090 00 00 00 00 01 00 00 00 eb 34 81 5b 52 25 90 00 |.........4=
[R%..|
002600a0 00 00 00 00 52 25 90 00 00 00 00 00 ff ff ff ff |....R%....=
.....|
002600b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |..........=
.....|
*
00260200 00 00 00 00 08 00 00 00 01 00 00 00 00 00 00 00 |..........=
.....|
00260210 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |..........=
.....|
00260220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |..........=
.....|
*
00260280 01 00 00 00 08 00 00 00 11 00 00 00 01 00 00 00 |..........=
.....|
00260290 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |..........=
.....|
002602a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |..........=
.....|
*
00260300 02 00 00 00 08 00 00 00 30 00 00 00 02 00 00 00 |........0.=
.....|
00260310 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |..........=
.....|
*
00260f80 02 00 00 00 08 00 00 00 30 00 00 00 02 00 00 00 |........0.=
.....|
00260f90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |..........=
.....|
*
0027e000

mdadm seems to confirm this. mdadm --examine /dev/sd[acd] gives "no md=
=20
superblock", but on /dev/sdb, I get this (note that the device size at =
least=20
is bogus, since the disk itself is only 750GB):

$ sudo mdadm --examine /dev/sdb
/dev/sdb:
Magic : a92b4efc
Version : 0.90.03
UUID : 9364f7a2:d74695d5:7d8db3a0:3b5f9e48
Creation Time : Mon Mar 27 14:03:04 2006
Raid Level : raid1
Used Dev Size : 979840 (957.04 MiB 1003.36 MB)
Array Size : 979840 (957.04 MiB 1003.36 MB)
Raid Devices : 2
Total Devices : 3
Preferred Minor : 0

Update Time : Thu Jan 8 00:34:39 2009
State : clean
Active Devices : 2
Working Devices : 3
Failed Devices : 0
Spare Devices : 1
Checksum : 5b8134eb - correct
Events : 9446738


Number Major Minor RaidDevice State
this 2 8 48 2 spare /dev/sdd

0 0 8 1 0 active sync /dev/sda1
1 1 8 17 1 active sync /dev/sdb1
2 2 8 48 2 spare /dev/sdd

--=20
-Matt
"Reality is that which, when you stop believing in it, doesn't go away"=

-- Philip K. Dick
GPG pubkey fingerprint: A57F B354 FD30 A502 795B 9637 3EF1 3F22 A85E 2A=
D1

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html