From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1cVxrb-0004ou-4K for mharc-grub-devel@gnu.org; Tue, 24 Jan 2017 04:58:07 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVxrY-0004kx-LG for grub-devel@gnu.org; Tue, 24 Jan 2017 04:58:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cVxrX-0006WM-87 for grub-devel@gnu.org; Tue, 24 Jan 2017 04:58:04 -0500 Received: from mail-ua0-x243.google.com ([2607:f8b0:400c:c08::243]:33575) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cVxrX-0006WI-2I for grub-devel@gnu.org; Tue, 24 Jan 2017 04:58:03 -0500 Received: by mail-ua0-x243.google.com with SMTP id d5so15844239uag.0 for ; Tue, 24 Jan 2017 01:58:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=p/iGnuC1DZewi6VbNEtYEmxshqL6mETkG5ayz0jjIzI=; b=Zzed8Dt/rSo/YVYuSKzx8xBCzlsMq1M6xX2GM9KqVo9itbXl7qVA5cpu3MIROTVlli y6w/aLfrGUKIKMuoLQYkKK0TT3kS8pM9ytKVikSYO2R2O/XFccG/MEewmiovjaKxZ4FW bU0m3dtCpCIXo01M50vt4gHoIj4ZkQ3UV+q5qC6XaOd0Do8X0nwCLMB2Q1CFnX4ZziK4 QlzlaRJEnuuPFv92JW28Dri8E0KP1k2AXqO7Y/QLfJkvNz39PylWudhj8/ttEm/E5ngx i0q7SN+gfhyaowU4Ge433Cd3iOjXhp4g/OcS3MBj1o6L8flTFUFCx5QYNsRBA+0ZXUUl SfDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=p/iGnuC1DZewi6VbNEtYEmxshqL6mETkG5ayz0jjIzI=; b=S5HKHrsKGH3l4le2W37VQNHdQvMiC51Ad4Fp39A0wZ5xH1khSCDKRsurM5FZGtPnZ2 nYUBKPo4SuO8ABjfady1gF+gYesfwzqBJmxJn7IrfiOaMcas8hFZhrxHRvts3gDwckr9 dEqmkEigJRN4rChXVQEwu6dx9vCK1QlZoef2aT/OwNYD/gKW+snKhXZ4zdLgHeyxysGj +0VlM+v+eSRHgN3fbBGOyb1opms1BKQDbKUAzYQLIql0E2Y3/UrA3riQhvWsr/odddxW BNH2oZbbCa9CxG3CwYStVGxnJZ1mIlNFicLNuerS8DlZa40PUnnvkYKt2PfelFugeLqi DbLg== X-Gm-Message-State: AIkVDXJ7tWWRPGp/+c7VptpCktps9kyAR2FB4FlrlvJU0VBYyRfP4AqAh8lZEklq0RCSjoxzbhe1tGJzzWXPVg== X-Received: by 10.159.37.71 with SMTP id 65mr13891337uaz.134.1485251882167; Tue, 24 Jan 2017 01:58:02 -0800 (PST) MIME-Version: 1.0 References: <20161117200907.18342-1-robert@leblancnet.us> In-Reply-To: From: "Vladimir 'phcoder' Serbinenko" Date: Tue, 24 Jan 2017 09:57:51 +0000 Message-ID: Subject: Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS To: The development of GNU GRUB , Robert LeBlanc Content-Type: multipart/alternative; boundary=94eb2c12308ad6b3580546d4263a X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c08::243 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 09:58:06 -0000 --94eb2c12308ad6b3580546d4263a Content-Type: text/plain; charset=UTF-8 This fix is buggy as you don't reset grub_errno on this path. Also you probably want to ignore only a single error type GRUB_ERR_OUT_OF_RANGE as others are likely still fatal. On Wed, 11 Jan 2017, 20:26 Robert LeBlanc wrote: > Can we get this fix merged in? > > Thanks > ---------------- > Robert LeBlanc > PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 > > > On Thu, Nov 17, 2016 at 1:09 PM, Robert LeBlanc > wrote: > > When a mdadm RAID array is on a drive larger than 2TB, the array is not > > able to be detected and as such even if the array has a partition that > > holds /boot under the 2TB limit, it is unable to boot the machine. This > > is caused by metadata 1.0 being tested first which allocates the > > superblock at the end of the device. When it tries to access the end of > > the device it throws an error and the code returns without trying to > > find the superblock at other locations (metadata 1.1 and 1.2). This > > patch changes the error to not be fatal and allow for the checking for > > the other metadata versions and allowing the machine to boot as long as > > /boot is under the 2TB BIOS limit. This won't cause issues with 1.0 > > metadata because GRUB is able to read the partitions from the front of > > the drive/partition without having to determine the data offset, since > > the data for metadata 1.0 starts at sector 0. > > > > Signed-off-by: Robert LeBlanc > > --- > > grub-core/disk/mdraid1x_linux.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/grub-core/disk/mdraid1x_linux.c > b/grub-core/disk/mdraid1x_linux.c > > index 7cc80d3..cc7350c 100644 > > --- a/grub-core/disk/mdraid1x_linux.c > > +++ b/grub-core/disk/mdraid1x_linux.c > > @@ -148,7 +148,7 @@ grub_mdraid_detect (grub_disk_t disk, > > > > if (grub_disk_read (disk, sector, 0, sizeof (struct > grub_raid_super_1x), > > &sb)) > > - return NULL; > > + continue; > > > > if (sb.magic != grub_cpu_to_le32_compile_time (SB_MAGIC) > > || grub_le_to_cpu64 (sb.super_offset) != sector) > > -- > > 2.10.1 > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > --94eb2c12308ad6b3580546d4263a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This fix is buggy as you don't reset grub_errno on this path. Also you = probably want to ignore only a single error type GRUB_ERR_OUT_OF_RANGE as o= thers are likely still fatal.

On Wed, 11 Jan 2017, 20:26 Robert LeBlanc <robert@leblancnet.us> wrote:
Can we get this fix merged in?

Thanks
----------------
Robert LeBlanc
PGP Fingerprint 79A2 9CA4 6CC4 45DD A904=C2=A0 C70E E654 3BB2 FA62 B9F1


On Thu, Nov 17, 2016 at 1:09 PM, Robert LeBlanc <robert@leblancnet.us= > wrote:
> When a mdadm RAID array is on a drive larger than 2TB, the array is no= t
> able to be detected and as such even if the array has a partition that=
> holds /boot under the 2TB limit, it is unable to boot the machine. Thi= s
> is caused by metadata 1.0 being tested first which allocates the
> superblock at the end of the device. When it tries to access the end o= f
> the device it throws an error and the code returns without trying to > find the superblock at other locations (metadata 1.1 and 1.2). This > patch changes the error to not be fatal and allow for the checking for=
> the other metadata versions and allowing the machine to boot as long a= s
> /boot is under the 2TB BIOS limit. This won't cause issues with 1.= 0
> metadata because GRUB is able to read the partitions from the front of=
> the drive/partition without having to determine the data offset, since=
> the data for metadata 1.0 starts at sector 0.
>
> Signed-off-by: Robert LeBlanc <robert@leblancnet.us>
> ---
>=C2=A0 grub-core/disk/mdraid1x_linux.c | 2 +-
>=C2=A0 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/grub-core/disk/mdraid1x_linux.c b/grub-core/disk/mdraid1x= _linux.c
> index 7cc80d3..cc7350c 100644
> --- a/grub-core/disk/mdraid1x_linux.c
> +++ b/grub-core/disk/mdraid1x_linux.c
> @@ -148,7 +148,7 @@ grub_mdraid_detect (grub_disk_t disk,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (grub_disk_read (disk, sector, 0, sizeof= (struct grub_raid_super_1x),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0&sb))
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0return NULL;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0continue;
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (sb.magic !=3D grub_cpu_to_le32_compile_= time (SB_MAGIC)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|| grub_le_to_cpu64 (sb.super_= offset) !=3D sector)
> --
> 2.10.1
>

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/l= istinfo/grub-devel
--94eb2c12308ad6b3580546d4263a--