[PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Robert LeBlanc]

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 <robert@leblancnet.us>
---
 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

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Andrei Borzenkov]

17.11.2016 23:09, Robert LeBlanc пишет:
> 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

Why read returns error here and how it is related to device size?

> 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 <robert@leblancnet.us>
> ---
>  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)
> 

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Robert LeBlanc]

Based on debug info, GRUB is requesting to read the end of the drive
to read the mdadm 1.0 superblock and gets the following message:

kern/disk.c:421: Read out of range: sector 0x27fffffc8 (attempt to
read or write outside of disk 'hd0').

My understanding is that BIOS can only access 2TB of disk so this
makes sense. This patch turns this error from fatal in detecting mdadm
RAID arrays into a non-critical error so that other versions of
metadata can still be checked. Where I was running into the problem
was that we have a 5TB disk with mdadm metadata version 1.2 and we
could not get the md/0 to show up in GRUB because after the error, it
never tried to check the other mdadm metadata versions. Once this
patch was in place, the md/0 showed up and we were able to boot the
box because /boot on the mdadm RAID was below the 2TB BIOS limit.

mdadm metadata 1.0 superblock is located 8-12KB from the end of the disk
mdadm metadata 1.1 superblock is located at sector 0 of the disk/partition
mdadm metadata 1.2 superblock is located at sector 8 of the disk/partition

The loop was
for i=0; i<3; i++{
  check for the metadata
  if error {
    return NULL
  }
  return superblock info
}

So if an error occurs when checking one type of metadata, it does not
try the other types to see if they exist. This patch fixes that.

I hope that clears things up, let me know if you have additional questions.
----------------
Robert LeBlanc
PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1


On Thu, Nov 17, 2016 at 9:16 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> 17.11.2016 23:09, Robert LeBlanc пишет:
>> 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
>
> Why read returns error here and how it is related to device size?
>
>> 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 <robert@leblancnet.us>
>> ---
>>  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)
>>
>

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Andrei Borzenkov]

18.11.2016 19:49, Robert LeBlanc пишет:
> Based on debug info, GRUB is requesting to read the end of the drive
> to read the mdadm 1.0 superblock and gets the following message:
> 
> kern/disk.c:421: Read out of range: sector 0x27fffffc8 (attempt to
> read or write outside of disk 'hd0').
> 

Is MD RAID on whole disk or partition? What partition label - MBR or
GPT? Could you post fdisk -l from Linux (if your fdisk does not support
GPT, use "gdisk -l /dev/sdX")?

> My understanding is that BIOS can only access 2TB of disk so this
> makes sense. This patch turns this error from fatal in detecting mdadm
> RAID arrays into a non-critical error so that other versions of
> metadata can still be checked. Where I was running into the problem
> was that we have a 5TB disk with mdadm metadata version 1.2 and we
> could not get the md/0 to show up in GRUB because after the error, it
> never tried to check the other mdadm metadata versions. Once this
> patch was in place, the md/0 showed up and we were able to boot the
> box because /boot on the mdadm RAID was below the 2TB BIOS limit.
> 
> mdadm metadata 1.0 superblock is located 8-12KB from the end of the disk
> mdadm metadata 1.1 superblock is located at sector 0 of the disk/partition
> mdadm metadata 1.2 superblock is located at sector 8 of the disk/partition
> 
> The loop was
> for i=0; i<3; i++{
>   check for the metadata
>   if error {
>     return NULL
>   }
>   return superblock info
> }
> 
> So if an error occurs when checking one type of metadata, it does not
> try the other types to see if they exist. This patch fixes that.
> 
> I hope that clears things up, let me know if you have additional questions.
> ----------------
> Robert LeBlanc
> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1
> 
> 
> On Thu, Nov 17, 2016 at 9:16 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>> 17.11.2016 23:09, Robert LeBlanc пишет:
>>> 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
>>
>> Why read returns error here and how it is related to device size?
>>
>>> 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 <robert@leblancnet.us>
>>> ---
>>>  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)
>>>
>>

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Robert LeBlanc]

On Fri, Nov 18, 2016 at 10:31 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> 18.11.2016 19:49, Robert LeBlanc пишет:
>> Based on debug info, GRUB is requesting to read the end of the drive
>> to read the mdadm 1.0 superblock and gets the following message:
>>
>> kern/disk.c:421: Read out of range: sector 0x27fffffc8 (attempt to
>> read or write outside of disk 'hd0').
>>
>
> Is MD RAID on whole disk or partition? What partition label - MBR or
> GPT? Could you post fdisk -l from Linux (if your fdisk does not support
> GPT, use "gdisk -l /dev/sdX")?

# gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
 MBR: protective
 BSD: not present
 APM: not present
 GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 10737418240 sectors, 5.0 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 939F7AAD-AADD-481D-8896-DA0B4033C70C
Partition table holds up to 128 entries
First usable sector is 2048, last usable sector is 10737418206
Partitions will be aligned on 2048-sector boundaries
Total free space is 0 sectors (0 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
  1            2048            4095   1024.0 KiB  EF02
  2            4096     10737418206   5.0 TiB     FD00

partition # is a mdadm RAID 1 member partitioned as follows...

# sgdisk -l /dev/md123
# parted /dev/md123 print free
Model: Linux Software RAID Array (md)
Disk /dev/md123: 5497GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system     Name  Flags
       17.4kB  1049kB  1031kB  Free Space
1      1049kB  2097kB  1049kB                        bios_grub
2      2097kB  5371MB  5369MB  linux-swap(v1)
3      5371MB  6371MB  1000MB  ext2
4      6371MB  5497GB  5491GB  ext4
       5497GB  5497GB  966kB   Free Space

/dev/sdb is partitioned identically to /dev/sda

>
>> My understanding is that BIOS can only access 2TB of disk so this
>> makes sense. This patch turns this error from fatal in detecting mdadm
>> RAID arrays into a non-critical error so that other versions of
>> metadata can still be checked. Where I was running into the problem
>> was that we have a 5TB disk with mdadm metadata version 1.2 and we
>> could not get the md/0 to show up in GRUB because after the error, it
>> never tried to check the other mdadm metadata versions. Once this
>> patch was in place, the md/0 showed up and we were able to boot the
>> box because /boot on the mdadm RAID was below the 2TB BIOS limit.
>>
>> mdadm metadata 1.0 superblock is located 8-12KB from the end of the disk
>> mdadm metadata 1.1 superblock is located at sector 0 of the disk/partition
>> mdadm metadata 1.2 superblock is located at sector 8 of the disk/partition
>>
>> The loop was
>> for i=0; i<3; i++{
>>   check for the metadata
>>   if error {
>>     return NULL
>>   }
>>   return superblock info
>> }
>>
>> So if an error occurs when checking one type of metadata, it does not
>> try the other types to see if they exist. This patch fixes that.
>>
>> I hope that clears things up, let me know if you have additional questions.
>> ----------------
>> Robert LeBlanc
>> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1
>>
>>
>> On Thu, Nov 17, 2016 at 9:16 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>>> 17.11.2016 23:09, Robert LeBlanc пишет:
>>>> 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
>>>
>>> Why read returns error here and how it is related to device size?
>>>
>>>> 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 <robert@leblancnet.us>
>>>> ---
>>>>  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)
>>>>
>>>
>

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

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Andrei Borzenkov]

18.11.2016 21:06, Robert LeBlanc пишет:
> On Fri, Nov 18, 2016 at 10:31 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>> 18.11.2016 19:49, Robert LeBlanc пишет:
>>> Based on debug info, GRUB is requesting to read the end of the drive
>>> to read the mdadm 1.0 superblock and gets the following message:
>>>
>>> kern/disk.c:421: Read out of range: sector 0x27fffffc8 (attempt to
>>> read or write outside of disk 'hd0').
>>>
>>
>> Is MD RAID on whole disk or partition? What partition label - MBR or
>> GPT? Could you post fdisk -l from Linux (if your fdisk does not support
>> GPT, use "gdisk -l /dev/sdX")?
> 
> # gdisk -l /dev/sda
> GPT fdisk (gdisk) version 1.0.1
> 
> Partition table scan:
>  MBR: protective
>  BSD: not present
>  APM: not present
>  GPT: present
> 
> Found valid GPT with protective MBR; using GPT.
> Disk /dev/sda: 10737418240 sectors, 5.0 TiB
> Logical sector size: 512 bytes
> Disk identifier (GUID): 939F7AAD-AADD-481D-8896-DA0B4033C70C
> Partition table holds up to 128 entries
> First usable sector is 2048, last usable sector is 10737418206
> Partitions will be aligned on 2048-sector boundaries
> Total free space is 0 sectors (0 bytes)
> 
> Number  Start (sector)    End (sector)  Size       Code  Name
>   1            2048            4095   1024.0 KiB  EF02
>   2            4096     10737418206   5.0 TiB     FD00
> 
> partition # is a mdadm RAID 1 member partitioned as follows...
> 
> # sgdisk -l /dev/md123
> # parted /dev/md123 print free
> Model: Linux Software RAID Array (md)
> Disk /dev/md123: 5497GB
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
> Disk Flags:
> 
> Number  Start   End     Size    File system     Name  Flags
>        17.4kB  1049kB  1031kB  Free Space
> 1      1049kB  2097kB  1049kB                        bios_grub
> 2      2097kB  5371MB  5369MB  linux-swap(v1)
> 3      5371MB  6371MB  1000MB  ext2
> 4      6371MB  5497GB  5491GB  ext4
>        5497GB  5497GB  966kB   Free Space
> 
> /dev/sdb is partitioned identically to /dev/sda
> 

OK, could you please also show "ls -l" in grub CLI; if you cannot
capture serial console, attach screenshot(s). You may want to "set
pager=1" so output does not scroll off screen.

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Robert LeBlanc]

Do you want this with or without my patch?
----------------
Robert LeBlanc
PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1


On Fri, Nov 18, 2016 at 11:15 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> 18.11.2016 21:06, Robert LeBlanc пишет:
>> On Fri, Nov 18, 2016 at 10:31 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>>> 18.11.2016 19:49, Robert LeBlanc пишет:
>>>> Based on debug info, GRUB is requesting to read the end of the drive
>>>> to read the mdadm 1.0 superblock and gets the following message:
>>>>
>>>> kern/disk.c:421: Read out of range: sector 0x27fffffc8 (attempt to
>>>> read or write outside of disk 'hd0').
>>>>
>>>
>>> Is MD RAID on whole disk or partition? What partition label - MBR or
>>> GPT? Could you post fdisk -l from Linux (if your fdisk does not support
>>> GPT, use "gdisk -l /dev/sdX")?
>>
>> # gdisk -l /dev/sda
>> GPT fdisk (gdisk) version 1.0.1
>>
>> Partition table scan:
>>  MBR: protective
>>  BSD: not present
>>  APM: not present
>>  GPT: present
>>
>> Found valid GPT with protective MBR; using GPT.
>> Disk /dev/sda: 10737418240 sectors, 5.0 TiB
>> Logical sector size: 512 bytes
>> Disk identifier (GUID): 939F7AAD-AADD-481D-8896-DA0B4033C70C
>> Partition table holds up to 128 entries
>> First usable sector is 2048, last usable sector is 10737418206
>> Partitions will be aligned on 2048-sector boundaries
>> Total free space is 0 sectors (0 bytes)
>>
>> Number  Start (sector)    End (sector)  Size       Code  Name
>>   1            2048            4095   1024.0 KiB  EF02
>>   2            4096     10737418206   5.0 TiB     FD00
>>
>> partition # is a mdadm RAID 1 member partitioned as follows...
>>
>> # sgdisk -l /dev/md123
>> # parted /dev/md123 print free
>> Model: Linux Software RAID Array (md)
>> Disk /dev/md123: 5497GB
>> Sector size (logical/physical): 512B/512B
>> Partition Table: gpt
>> Disk Flags:
>>
>> Number  Start   End     Size    File system     Name  Flags
>>        17.4kB  1049kB  1031kB  Free Space
>> 1      1049kB  2097kB  1049kB                        bios_grub
>> 2      2097kB  5371MB  5369MB  linux-swap(v1)
>> 3      5371MB  6371MB  1000MB  ext2
>> 4      6371MB  5497GB  5491GB  ext4
>>        5497GB  5497GB  966kB   Free Space
>>
>> /dev/sdb is partitioned identically to /dev/sda
>>
>
> OK, could you please also show "ls -l" in grub CLI; if you cannot
> capture serial console, attach screenshot(s). You may want to "set
> pager=1" so output does not scroll off screen.
>
>

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Andrei Borzenkov]

18.11.2016 21:19, Robert LeBlanc пишет:
> Do you want this with or without my patch?

It does not matter, I want to see what grub thinks about physical disks
and their partitions.

> ----------------
> Robert LeBlanc
> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1
> 
> 
> On Fri, Nov 18, 2016 at 11:15 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>> 18.11.2016 21:06, Robert LeBlanc пишет:
>>> On Fri, Nov 18, 2016 at 10:31 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>>>> 18.11.2016 19:49, Robert LeBlanc пишет:
>>>>> Based on debug info, GRUB is requesting to read the end of the drive
>>>>> to read the mdadm 1.0 superblock and gets the following message:
>>>>>
>>>>> kern/disk.c:421: Read out of range: sector 0x27fffffc8 (attempt to
>>>>> read or write outside of disk 'hd0').
>>>>>
>>>>
>>>> Is MD RAID on whole disk or partition? What partition label - MBR or
>>>> GPT? Could you post fdisk -l from Linux (if your fdisk does not support
>>>> GPT, use "gdisk -l /dev/sdX")?
>>>
>>> # gdisk -l /dev/sda
>>> GPT fdisk (gdisk) version 1.0.1
>>>
>>> Partition table scan:
>>>  MBR: protective
>>>  BSD: not present
>>>  APM: not present
>>>  GPT: present
>>>
>>> Found valid GPT with protective MBR; using GPT.
>>> Disk /dev/sda: 10737418240 sectors, 5.0 TiB
>>> Logical sector size: 512 bytes
>>> Disk identifier (GUID): 939F7AAD-AADD-481D-8896-DA0B4033C70C
>>> Partition table holds up to 128 entries
>>> First usable sector is 2048, last usable sector is 10737418206
>>> Partitions will be aligned on 2048-sector boundaries
>>> Total free space is 0 sectors (0 bytes)
>>>
>>> Number  Start (sector)    End (sector)  Size       Code  Name
>>>   1            2048            4095   1024.0 KiB  EF02
>>>   2            4096     10737418206   5.0 TiB     FD00
>>>
>>> partition # is a mdadm RAID 1 member partitioned as follows...
>>>
>>> # sgdisk -l /dev/md123
>>> # parted /dev/md123 print free
>>> Model: Linux Software RAID Array (md)
>>> Disk /dev/md123: 5497GB
>>> Sector size (logical/physical): 512B/512B
>>> Partition Table: gpt
>>> Disk Flags:
>>>
>>> Number  Start   End     Size    File system     Name  Flags
>>>        17.4kB  1049kB  1031kB  Free Space
>>> 1      1049kB  2097kB  1049kB                        bios_grub
>>> 2      2097kB  5371MB  5369MB  linux-swap(v1)
>>> 3      5371MB  6371MB  1000MB  ext2
>>> 4      6371MB  5497GB  5491GB  ext4
>>>        5497GB  5497GB  966kB   Free Space
>>>
>>> /dev/sdb is partitioned identically to /dev/sda
>>>
>>
>> OK, could you please also show "ls -l" in grub CLI; if you cannot
>> capture serial console, attach screenshot(s). You may want to "set
>> pager=1" so output does not scroll off screen.
>>
>>

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Robert LeBlanc]

[-- Attachment #1: Type: text/plain, Size: 4542 bytes --]

I could not get GRUB rescue to use the serial console so I'm attaching
a screenshot for the unpatched version of GRUB.

Here is the patched version of GRUB

                         GNU GRUB  version 2.02~beta3

  Minimal BASH-like line editing is supported. For the first word, TAB
  lists possible command completions. Anywhere else TAB lists possible
  device or file completions. ESC at any time exits.


grub> ls -l
Device hd0: No known filesystem detected - Sector size 512B - Total size
2147483648KiB
       Partition hd0,gpt2: No known filesystem detected - Partition start at
2048KiB - Total size 5368707055.5KiB
       Partition hd0,gpt1: No known filesystem detected - Partition start at
1024KiB - Total size 1024KiB
Device md/123: No known filesystem detected - Sector size 512B - Total size
5368575936KiB
       Partition md/123,gpt4: Filesystem type ext* - Last modification time
2016-11-18 20:00:50 Friday, UUID dd584910-dab0-4d06-b768-9e7d8edf83ed -
Partition start at 6221824KiB - Total size 5362353152KiB
       Partition md/123,gpt3: Filesystem type ext* - Last modification time
2016-11-18 20:05:14 Friday, UUID 9e5fd3bf-cd08-4086-8d9e-73ac278e4a4c -
Partition start at 5244928KiB - Total size 976896KiB
       Partition md/123,gpt2: No known filesystem detected - Partition start
at 2048KiB - Total size 5242880KiB
       Partition md/123,gpt1: No known filesystem detected - Partition start
at 1024KiB - Total size 1024KiB

grub>
----------------
Robert LeBlanc
PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1


On Fri, Nov 18, 2016 at 11:24 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> 18.11.2016 21:19, Robert LeBlanc пишет:
>> Do you want this with or without my patch?
>
> It does not matter, I want to see what grub thinks about physical disks
> and their partitions.
>
>> ----------------
>> Robert LeBlanc
>> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1
>>
>>
>> On Fri, Nov 18, 2016 at 11:15 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>>> 18.11.2016 21:06, Robert LeBlanc пишет:
>>>> On Fri, Nov 18, 2016 at 10:31 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>>>>> 18.11.2016 19:49, Robert LeBlanc пишет:
>>>>>> Based on debug info, GRUB is requesting to read the end of the drive
>>>>>> to read the mdadm 1.0 superblock and gets the following message:
>>>>>>
>>>>>> kern/disk.c:421: Read out of range: sector 0x27fffffc8 (attempt to
>>>>>> read or write outside of disk 'hd0').
>>>>>>
>>>>>
>>>>> Is MD RAID on whole disk or partition? What partition label - MBR or
>>>>> GPT? Could you post fdisk -l from Linux (if your fdisk does not support
>>>>> GPT, use "gdisk -l /dev/sdX")?
>>>>
>>>> # gdisk -l /dev/sda
>>>> GPT fdisk (gdisk) version 1.0.1
>>>>
>>>> Partition table scan:
>>>>  MBR: protective
>>>>  BSD: not present
>>>>  APM: not present
>>>>  GPT: present
>>>>
>>>> Found valid GPT with protective MBR; using GPT.
>>>> Disk /dev/sda: 10737418240 sectors, 5.0 TiB
>>>> Logical sector size: 512 bytes
>>>> Disk identifier (GUID): 939F7AAD-AADD-481D-8896-DA0B4033C70C
>>>> Partition table holds up to 128 entries
>>>> First usable sector is 2048, last usable sector is 10737418206
>>>> Partitions will be aligned on 2048-sector boundaries
>>>> Total free space is 0 sectors (0 bytes)
>>>>
>>>> Number  Start (sector)    End (sector)  Size       Code  Name
>>>>   1            2048            4095   1024.0 KiB  EF02
>>>>   2            4096     10737418206   5.0 TiB     FD00
>>>>
>>>> partition # is a mdadm RAID 1 member partitioned as follows...
>>>>
>>>> # sgdisk -l /dev/md123
>>>> # parted /dev/md123 print free
>>>> Model: Linux Software RAID Array (md)
>>>> Disk /dev/md123: 5497GB
>>>> Sector size (logical/physical): 512B/512B
>>>> Partition Table: gpt
>>>> Disk Flags:
>>>>
>>>> Number  Start   End     Size    File system     Name  Flags
>>>>        17.4kB  1049kB  1031kB  Free Space
>>>> 1      1049kB  2097kB  1049kB                        bios_grub
>>>> 2      2097kB  5371MB  5369MB  linux-swap(v1)
>>>> 3      5371MB  6371MB  1000MB  ext2
>>>> 4      6371MB  5497GB  5491GB  ext4
>>>>        5497GB  5497GB  966kB   Free Space
>>>>
>>>> /dev/sdb is partitioned identically to /dev/sda
>>>>
>>>
>>> OK, could you please also show "ls -l" in grub CLI; if you cannot
>>> capture serial console, attach screenshot(s). You may want to "set
>>> pager=1" so output does not scroll off screen.
>>>
>>>
>

[-- Attachment #2: grub_5tb.png --]
[-- Type: image/png, Size: 32129 bytes --]

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Andrei Borzenkov]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

18.11.2016 23:43, Robert LeBlanc пишет:
> 
> grub> ls -l
> Device hd0: No known filesystem detected - Sector size 512B - Total size
> 2147483648KiB
>        Partition hd0,gpt2: No known filesystem detected - Partition start at
> 2048KiB - Total size 5368707055.5KiB
>        Partition hd0,gpt1: No known filesystem detected - Partition start at
> 1024KiB - Total size 1024KiB

Oh. Could you please run attached patch on top of pure GIT (without your
patch) and send me output. It adds some debug print to biosdisk driver
so we can try to guess what happens. After building, generate minimal
image to avoid too much output

bor@bor-Latitude-E5450:~/build/grub$ echo "set debug=biosdisk" >
/tmp/load.cfg
bor@bor-Latitude-E5450:~/build/grub$ pkgdatadir=$PWD ./grub-mkimage -O
i386-pc -d grub-core -o grub.img -p "(md/xxx)/" -c /tmp/load.cfg
biosdisk mdraid1x


Actual array name is irrelevant and is there simply to force raid scan.
After that copy it to /boot, go to GRUB CLI and run

multiboot /boot/grub.img
boot



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: biosdisk.patch --]
[-- Type: text/x-patch; name="biosdisk.patch", Size: 5300 bytes --]

From: Andrei Borzenkov <arvidjaar@gmail.com>
Subject: [PATCH] biosdisk: debug output for disk parameters

Add debug output to track BIOS behavior with 4Kn disks.

---
 grub-core/disk/i386/pc/biosdisk.c | 45 +++++++++++++++++++++++++++++++++++----
 include/grub/i386/pc/biosdisk.h   |  1 +
 2 files changed, 42 insertions(+), 4 deletions(-)

diff --git a/grub-core/disk/i386/pc/biosdisk.c b/grub-core/disk/i386/pc/biosdisk.c
index f0aadd1..ef69f13 100644
--- a/grub-core/disk/i386/pc/biosdisk.c
+++ b/grub-core/disk/i386/pc/biosdisk.c
@@ -84,6 +84,8 @@ grub_biosdisk_rw_int13_extensions (int ah, int drive, void *dap)
 
   grub_bios_interrupt (0x13, &regs);
   return (regs.eax >> 8) & 0xff;
+  // return regs.flags & GRUB_CPU_INT_FLAGS_CARRY ? (regs.eax >> 8) & 0xff : 0;
+
 }
 
 /*
@@ -335,6 +337,7 @@ grub_biosdisk_open (const char *name, grub_disk_t disk)
   grub_uint64_t total_sectors = 0;
   int drive;
   struct grub_biosdisk_data *data;
+  int ret;
 
   drive = grub_biosdisk_get_drive (name);
   if (drive < 0)
@@ -369,11 +372,17 @@ grub_biosdisk_open (const char *name, grub_disk_t disk)
 	  struct grub_biosdisk_drp *drp
 	    = (struct grub_biosdisk_drp *) GRUB_MEMORY_MACHINE_SCRATCH_ADDR;
 
+	  grub_dprintf ("biosdisk", "%s: int13 version=%u\n", disk->name, version);
 	  /* Clear out the DRP.  */
 	  grub_memset (drp, 0, sizeof (*drp));
 	  drp->size = sizeof (*drp);
-	  if (! grub_biosdisk_get_diskinfo_int13_extensions (drive, drp))
+	  if (! (ret = grub_biosdisk_get_diskinfo_int13_extensions (drive, drp)))
 	    {
+	      grub_dprintf ("biosdisk", "%s: DRP size=%u flags=%x c=%u h=%u s=%u t=%"
+			    PRIuGRUB_UINT64_T " bpi=%u\n",
+			    disk->name, drp->size, drp->flags, drp->cylinders, drp->heads,
+			    drp->sectors, drp->total_sectors, drp->bytes_per_sector);
+
 	      data->flags = GRUB_BIOSDISK_FLAG_LBA;
 
 	      if (drp->total_sectors)
@@ -394,16 +403,22 @@ grub_biosdisk_open (const char *name, grub_disk_t disk)
 		       disk->log_sector_size++);
 		}
 	    }
+	  else
+	    grub_dprintf ("biosdisk", "%s: int13 get ext failed %x\n", disk->name, ret);
 	}
+      else
+	grub_dprintf ("biosdisk", "%s: int13 check ext failed\n", disk->name);
     }
 
   if (! (data->flags & GRUB_BIOSDISK_FLAG_CDROM))
     {
-      if (grub_biosdisk_get_diskinfo_standard (drive,
+      if ((ret = grub_biosdisk_get_diskinfo_standard (drive,
 					       &data->cylinders,
 					       &data->heads,
-					       &data->sectors) != 0)
+					       &data->sectors)) != 0)
         {
+	  grub_dprintf ("biosdisk", "%s: get_diskinfo failed %x\n", disk->name, ret);
+
 	  if (total_sectors && (data->flags & GRUB_BIOSDISK_FLAG_LBA))
 	    {
 	      data->sectors = 63;
@@ -419,6 +434,9 @@ grub_biosdisk_open (const char *name, grub_disk_t disk)
 	      return grub_error (GRUB_ERR_BAD_DEVICE, "%s cannot get C/H/S values", disk->name);
 	    }
         }
+      else
+	grub_dprintf ("biosdisk", "%s: C/H/S=%lu/%lu/%lu\n", disk->name,
+		      data->cylinders, data->heads, data->sectors);
 
       if (data->sectors == 0)
 	data->sectors = 63;
@@ -461,6 +479,7 @@ grub_biosdisk_rw (int cmd, grub_disk_t disk,
 		  unsigned segment)
 {
   struct grub_biosdisk_data *data = disk->data;
+  int ret;
 
   /* VirtualBox fails with sectors above 2T on CDs.
      Since even BD-ROMS are never that big anyway, return error.  */
@@ -501,19 +520,37 @@ grub_biosdisk_rw (int cmd, grub_disk_t disk,
 			       disk->name);
 	}
       else
-        if (grub_biosdisk_rw_int13_extensions (cmd + 0x42, data->drive, dap))
+        if ((ret = grub_biosdisk_rw_int13_extensions (cmd + 0x42, data->drive, dap)))
 	  {
+	    grub_dprintf ("biosdisk", "%s: ext sec=%" PRIuGRUB_UINT64_T " size=%"
+			  PRIuGRUB_SIZE " ret=%u\n",
+			  disk->name, sector, size, ret);
+
 	    /* Fall back to the CHS mode.  */
 	    data->flags &= ~GRUB_BIOSDISK_FLAG_LBA;
 	    disk->total_sectors = data->cylinders * data->heads * data->sectors;
 	    return grub_biosdisk_rw (cmd, disk, sector, size, segment);
 	  }
+	else if (!(data->flags & GRUB_BIOSDISK_FLAG_DPRINT))
+	  {
+	    grub_dprintf ("biosdisk", "%s: ext sec=%" PRIuGRUB_UINT64_T " size=%"
+			  PRIuGRUB_SIZE "\n",
+			  disk->name, sector, size);
+	      data->flags |= GRUB_BIOSDISK_FLAG_DPRINT;
+	  }
     }
   else
     {
       unsigned coff, hoff, soff;
       unsigned head;
 
+      if (!(data->flags & GRUB_BIOSDISK_FLAG_DPRINT))
+	{
+	  grub_dprintf ("biosdisk", "%s: legacy sec=%" PRIuGRUB_UINT64_T " size=%"
+			PRIuGRUB_SIZE "\n",
+			disk->name, sector, size);
+	  data->flags |= GRUB_BIOSDISK_FLAG_DPRINT;
+	}
       /* It is impossible to reach over 8064 MiB (a bit less than LBA24) with
 	 the traditional CHS access.  */
       if (sector >
diff --git a/include/grub/i386/pc/biosdisk.h b/include/grub/i386/pc/biosdisk.h
index 3d80716..fa0862f 100644
--- a/include/grub/i386/pc/biosdisk.h
+++ b/include/grub/i386/pc/biosdisk.h
@@ -24,6 +24,7 @@
 
 #define GRUB_BIOSDISK_FLAG_LBA	1
 #define GRUB_BIOSDISK_FLAG_CDROM 2
+#define GRUB_BIOSDISK_FLAG_DPRINT 4
 
 #define GRUB_BIOSDISK_CDTYPE_NO_EMUL	0
 #define GRUB_BIOSDISK_CDTYPE_1_2_M	1
-- 
tg: (0d663b5..) t/biosdisk (depends on: master)

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Robert LeBlanc]

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]

On Sat, Nov 19, 2016 at 1:59 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> biosdisk mdraid1x

Here is the screenshot of the output.

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

[-- Attachment #2: biosdisk.png --]
[-- Type: image/png, Size: 26827 bytes --]

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Andrei Borzenkov]

19.11.2016 20:57, Robert LeBlanc пишет:
> On Sat, Nov 19, 2016 at 1:59 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>> biosdisk mdraid1x
> 
> Here is the screenshot of the output.
> 


So it does not even mask LBA to 32 bit, it really returns 2TB. What
system (motherboard) is it? What is disk controller? How drives are
connected (directly to motherboard or some external adapter)?

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Robert LeBlanc]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

This is on super micro and KVM. You can replicate it on a VM.

Sent from a mobile device, please excuse any typos.

On Nov 19, 2016 11:40 AM, "Andrei Borzenkov" <arvidjaar@gmail.com> wrote:

> 19.11.2016 20:57, Robert LeBlanc пишет:
> > On Sat, Nov 19, 2016 at 1:59 AM, Andrei Borzenkov <arvidjaar@gmail.com>
> wrote:
> >> biosdisk mdraid1x
> >
> > Here is the screenshot of the output.
> >
>
>
> So it does not even mask LBA to 32 bit, it really returns 2TB. What
> system (motherboard) is it? What is disk controller? How drives are
> connected (directly to motherboard or some external adapter)?
>

[-- Attachment #2: Type: text/html, Size: 997 bytes --]

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Robert LeBlanc]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

The super micro is iSCSI boot off Intel adapters. KVM is SCSI disks.

Sent from a mobile device, please excuse any typos.

On Nov 19, 2016 7:47 PM, "Robert LeBlanc" <robert@leblancnet.us> wrote:

> This is on super micro and KVM. You can replicate it on a VM.
>
> Sent from a mobile device, please excuse any typos.
>
> On Nov 19, 2016 11:40 AM, "Andrei Borzenkov" <arvidjaar@gmail.com> wrote:
>
>> 19.11.2016 20:57, Robert LeBlanc пишет:
>> > On Sat, Nov 19, 2016 at 1:59 AM, Andrei Borzenkov <arvidjaar@gmail.com>
>> wrote:
>> >> biosdisk mdraid1x
>> >
>> > Here is the screenshot of the output.
>> >
>>
>>
>> So it does not even mask LBA to 32 bit, it really returns 2TB. What
>> system (motherboard) is it? What is disk controller? How drives are
>> connected (directly to motherboard or some external adapter)?
>>
>

[-- Attachment #2: Type: text/html, Size: 1521 bytes --]

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Andrei Borzenkov]

20.11.2016 05:47, Robert LeBlanc пишет:
> This is on super micro and KVM. You can replicate it on a VM.
> 

I can't without more details. 5TB drive is correctly shown as 5TB in
QEMU KVM 2.5 here.

> Sent from a mobile device, please excuse any typos.
> 
> On Nov 19, 2016 11:40 AM, "Andrei Borzenkov" <arvidjaar@gmail.com> wrote:
> 
>> 19.11.2016 20:57, Robert LeBlanc пишет:
>>> On Sat, Nov 19, 2016 at 1:59 AM, Andrei Borzenkov <arvidjaar@gmail.com>
>> wrote:
>>>> biosdisk mdraid1x
>>>
>>> Here is the screenshot of the output.
>>>
>>
>>
>> So it does not even mask LBA to 32 bit, it really returns 2TB. What
>> system (motherboard) is it? What is disk controller? How drives are
>> connected (directly to motherboard or some external adapter)?
>>
> 

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Robert LeBlanc]

Andrei,

I sent a VM that displays the problem. It bounced from the listserv (I
kind of expected that), but should have been sent to your email
directly as well.

For my own curiosity are you against the patch I submitted? I
understand that you are trying to figure out why the sectors can't be
accessed as a larger issue. Is there something I can do to help get
this resolved?

Some more details on the hardware:
SuperMicro SYS-6028TP-HTFR
BIOS 1.1 American Megatrends Inc 08/03/2015
Intel I350 NIC firmware 1.63 (iSCSI boot)

For KVM I'm running Debian stretch with
ii  qemu-kvm
1:2.7+dfsg-3+b1                      amd64        QEMU Full
virtualization on x86 hardware



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


On Sat, Nov 19, 2016 at 11:53 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> 20.11.2016 05:47, Robert LeBlanc пишет:
>> This is on super micro and KVM. You can replicate it on a VM.
>>
>
> I can't without more details. 5TB drive is correctly shown as 5TB in
> QEMU KVM 2.5 here.
>
>> Sent from a mobile device, please excuse any typos.
>>
>> On Nov 19, 2016 11:40 AM, "Andrei Borzenkov" <arvidjaar@gmail.com> wrote:
>>
>>> 19.11.2016 20:57, Robert LeBlanc пишет:
>>>> On Sat, Nov 19, 2016 at 1:59 AM, Andrei Borzenkov <arvidjaar@gmail.com>
>>> wrote:
>>>>> biosdisk mdraid1x
>>>>
>>>> Here is the screenshot of the output.
>>>>
>>>
>>>
>>> So it does not even mask LBA to 32 bit, it really returns 2TB. What
>>> system (motherboard) is it? What is disk controller? How drives are
>>> connected (directly to motherboard or some external adapter)?
>>>
>>
>

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Robert LeBlanc]

What is the verdict on getting the RAID detection fixed?

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


On Tue, Nov 22, 2016 at 12:00 PM, Robert LeBlanc <robert@leblancnet.us> wrote:
> Andrei,
>
> I sent a VM that displays the problem. It bounced from the listserv (I
> kind of expected that), but should have been sent to your email
> directly as well.
>
> For my own curiosity are you against the patch I submitted? I
> understand that you are trying to figure out why the sectors can't be
> accessed as a larger issue. Is there something I can do to help get
> this resolved?
>
> Some more details on the hardware:
> SuperMicro SYS-6028TP-HTFR
> BIOS 1.1 American Megatrends Inc 08/03/2015
> Intel I350 NIC firmware 1.63 (iSCSI boot)
>
> For KVM I'm running Debian stretch with
> ii  qemu-kvm
> 1:2.7+dfsg-3+b1                      amd64        QEMU Full
> virtualization on x86 hardware
>
>
>
> ----------------
> Robert LeBlanc
> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1
>
>
> On Sat, Nov 19, 2016 at 11:53 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>> 20.11.2016 05:47, Robert LeBlanc пишет:
>>> This is on super micro and KVM. You can replicate it on a VM.
>>>
>>
>> I can't without more details. 5TB drive is correctly shown as 5TB in
>> QEMU KVM 2.5 here.
>>
>>> Sent from a mobile device, please excuse any typos.
>>>
>>> On Nov 19, 2016 11:40 AM, "Andrei Borzenkov" <arvidjaar@gmail.com> wrote:
>>>
>>>> 19.11.2016 20:57, Robert LeBlanc пишет:
>>>>> On Sat, Nov 19, 2016 at 1:59 AM, Andrei Borzenkov <arvidjaar@gmail.com>
>>>> wrote:
>>>>>> biosdisk mdraid1x
>>>>>
>>>>> Here is the screenshot of the output.
>>>>>
>>>>
>>>>
>>>> So it does not even mask LBA to 32 bit, it really returns 2TB. What
>>>> system (motherboard) is it? What is disk controller? How drives are
>>>> connected (directly to motherboard or some external adapter)?
>>>>
>>>
>>

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Robert LeBlanc]

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 <robert@leblancnet.us> 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 <robert@leblancnet.us>
> ---
>  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
>

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]

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 <robert@leblancnet.us> 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 <robert@leblancnet.us>
> 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 <robert@leblancnet.us>
> > ---
> >  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
>

[-- Attachment #2: Type: text/html, Size: 4100 bytes --]

Re: [PATCH] disk/mdraid1x: Fix >2TB RAID detection with BIOS

[Robert LeBlanc]

OK, I'll rework the patch and resubmit it. Thanks for the feedback.
----------------
Robert LeBlanc
PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1


On Tue, Jan 24, 2017 at 2:57 AM, Vladimir 'phcoder' Serbinenko
<phcoder@gmail.com> wrote:
> 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 <robert@leblancnet.us> 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 <robert@leblancnet.us>
>> 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 <robert@leblancnet.us>
>> > ---
>> >  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