On Wed, Apr 27, 2016 at 8:09 AM, Karel Zak wrote:
> On Tue, Apr 26, 2016 at 02:51:01PM -0700, Gwendal Grignou wrote:
>> Julius and I were looking at the code when we spotted the issue.
>>
>> As Julius said, "just pass a boot param", is not easy on certain
>> machines, like phone.
On Wed, Apr 27, 2016 at 8:09 AM, Karel Zak wrote:
> On Tue, Apr 26, 2016 at 02:51:01PM -0700, Gwendal Grignou wrote:
>> Julius and I were looking at the code when we spotted the issue.
>>
>> As Julius said, "just pass a boot param", is not easy on certain
>> machines, like phone. It is not user
Hi,
On Wed, Apr 27, 2016 at 8:09 AM, Karel Zak wrote:
> On Tue, Apr 26, 2016 at 02:51:01PM -0700, Gwendal Grignou wrote:
>> Julius and I were looking at the code when we spotted the issue.
>>
>> As Julius said, "just pass a boot param", is not easy on certain
>> machines, like
Hi,
On Wed, Apr 27, 2016 at 8:09 AM, Karel Zak wrote:
> On Tue, Apr 26, 2016 at 02:51:01PM -0700, Gwendal Grignou wrote:
>> Julius and I were looking at the code when we spotted the issue.
>>
>> As Julius said, "just pass a boot param", is not easy on certain
>> machines, like phone. It is not
On Tue, Apr 26, 2016 at 02:51:01PM -0700, Gwendal Grignou wrote:
> Julius and I were looking at the code when we spotted the issue.
>
> As Julius said, "just pass a boot param", is not easy on certain
> machines, like phone. It is not user friendly either.
> The system won't boot at all, a
On Tue, Apr 26, 2016 at 02:51:01PM -0700, Gwendal Grignou wrote:
> Julius and I were looking at the code when we spotted the issue.
>
> As Julius said, "just pass a boot param", is not easy on certain
> machines, like phone. It is not user friendly either.
> The system won't boot at all, a
On 2016-04-27 02:00, Ard Biesheuvel wrote:
On 26 April 2016 at 22:34, Elliott, Robert (Persistent Memory)
wrote:
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Davidlohr Bueso
Sent: Tuesday,
On 2016-04-27 02:00, Ard Biesheuvel wrote:
On 26 April 2016 at 22:34, Elliott, Robert (Persistent Memory)
wrote:
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Davidlohr Bueso
Sent: Tuesday, April 26, 2016 1:34
On 26 April 2016 at 22:34, Elliott, Robert (Persistent Memory)
wrote:
>
>
>> -Original Message-
>> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
>> ow...@vger.kernel.org] On Behalf Of Davidlohr Bueso
>> Sent: Tuesday, April 26, 2016 1:34 PM
>> To: Karel
On 26 April 2016 at 22:34, Elliott, Robert (Persistent Memory)
wrote:
>
>
>> -Original Message-
>> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
>> ow...@vger.kernel.org] On Behalf Of Davidlohr Bueso
>> Sent: Tuesday, April 26, 2016 1:34 PM
>> To: Karel Zak
>> Cc: Julius
On Tue, Apr 26, 2016 at 2:15 PM, Davidlohr Bueso wrote:
> On Tue, 26 Apr 2016, Elliott, Robert (Persistent Memory) wrote:
>
>
> I have nothing against the agpt, just pass a boot param and voila,
> you can use it. This is not some sort of recent regression we are
> talking
On Tue, Apr 26, 2016 at 2:15 PM, Davidlohr Bueso wrote:
> On Tue, 26 Apr 2016, Elliott, Robert (Persistent Memory) wrote:
>
>
> I have nothing against the agpt, just pass a boot param and voila,
> you can use it. This is not some sort of recent regression we are
> talking about here. How is this
On Tue, 26 Apr 2016, Elliott, Robert (Persistent Memory) wrote:
The UEFI specification is not ambiguous - you should always look
for the backup GPT Header at the last LBA:
"Two GPT Header structures are stored on the device: the primary
and the backup. The primary GPT Header must be located in
On Tue, 26 Apr 2016, Elliott, Robert (Persistent Memory) wrote:
The UEFI specification is not ambiguous - you should always look
for the backup GPT Header at the last LBA:
"Two GPT Header structures are stored on the device: the primary
and the backup. The primary GPT Header must be located in
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Davidlohr Bueso
> Sent: Tuesday, April 26, 2016 1:34 PM
> To: Karel Zak
> Cc: Julius Werner ; linux-...@vger.kernel.org;
>
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Davidlohr Bueso
> Sent: Tuesday, April 26, 2016 1:34 PM
> To: Karel Zak
> Cc: Julius Werner ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org;
>> I guess "force_gpt" (and "gpt" on kernel command line) exists to force
>> users to think and care about a reason why the device has unreadable
>> (broken) primary GPT header.
>
>
> Yes, from find_valid_gpt():
>
> * If the Primary GPT header is not valid, the Alternate GPT header
> * is not
>> I guess "force_gpt" (and "gpt" on kernel command line) exists to force
>> users to think and care about a reason why the device has unreadable
>> (broken) primary GPT header.
>
>
> Yes, from find_valid_gpt():
>
> * If the Primary GPT header is not valid, the Alternate GPT header
> * is not
On 2016-04-26 14:10, Davidlohr Bueso wrote:
On Tue, 26 Apr 2016, Austin S. Hemmelgarn wrote:
At the absolute minimum, we should be logging (at least at a warning
level) that we had to fall back the the backup GPT. If somebody is
dealing with a disk that had a torn write to the primary GPT,
On 2016-04-26 14:10, Davidlohr Bueso wrote:
On Tue, 26 Apr 2016, Austin S. Hemmelgarn wrote:
At the absolute minimum, we should be logging (at least at a warning
level) that we had to fall back the the backup GPT. If somebody is
dealing with a disk that had a torn write to the primary GPT,
On Tue, 26 Apr 2016, Karel Zak wrote:
On Mon, Apr 25, 2016 at 06:06:46PM -0700, Julius Werner wrote:
The GUID Partiton Table layout maintains two synonymous partition tables
on a block device, one starting in sector 1 and one in the very last
sectors of the block device. This is useful if one
On Tue, 26 Apr 2016, Karel Zak wrote:
On Mon, Apr 25, 2016 at 06:06:46PM -0700, Julius Werner wrote:
The GUID Partiton Table layout maintains two synonymous partition tables
on a block device, one starting in sector 1 and one in the very last
sectors of the block device. This is useful if one
On Tue, 26 Apr 2016, Austin S. Hemmelgarn wrote:
At the absolute minimum, we should be logging (at least at a warning
level) that we had to fall back the the backup GPT. If somebody is
dealing with a disk that had a torn write to the primary GPT, that's
one thing, but this could also be
On Tue, 26 Apr 2016, Austin S. Hemmelgarn wrote:
At the absolute minimum, we should be logging (at least at a warning
level) that we had to fall back the the backup GPT. If somebody is
dealing with a disk that had a torn write to the primary GPT, that's
one thing, but this could also be
On 2016-04-25 21:06, Julius Werner wrote:
The GUID Partiton Table layout maintains two synonymous partition tables
on a block device, one starting in sector 1 and one in the very last
sectors of the block device. This is useful if one of the tables gets
accidentally corrupted (e.g. through a
On 2016-04-25 21:06, Julius Werner wrote:
The GUID Partiton Table layout maintains two synonymous partition tables
on a block device, one starting in sector 1 and one in the very last
sectors of the block device. This is useful if one of the tables gets
accidentally corrupted (e.g. through a
On Mon, Apr 25, 2016 at 06:06:46PM -0700, Julius Werner wrote:
> The GUID Partiton Table layout maintains two synonymous partition tables
> on a block device, one starting in sector 1 and one in the very last
> sectors of the block device. This is useful if one of the tables gets
> accidentally
On Mon, Apr 25, 2016 at 06:06:46PM -0700, Julius Werner wrote:
> The GUID Partiton Table layout maintains two synonymous partition tables
> on a block device, one starting in sector 1 and one in the very last
> sectors of the block device. This is useful if one of the tables gets
> accidentally
The GUID Partiton Table layout maintains two synonymous partition tables
on a block device, one starting in sector 1 and one in the very last
sectors of the block device. This is useful if one of the tables gets
accidentally corrupted (e.g. through a partial write because of an
unexpected power
The GUID Partiton Table layout maintains two synonymous partition tables
on a block device, one starting in sector 1 and one in the very last
sectors of the block device. This is useful if one of the tables gets
accidentally corrupted (e.g. through a partial write because of an
unexpected power
30 matches
Mail list logo