Re: [PATCH] block: partitions: efi: Always check for alternative GPT at end of drive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Wed, Apr 27, 2016 at 8:09 AM, Karel Zak <kzak@xxxxxxxxxx> 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 friendly either.
>> The system won't boot at all, a typical user will have to do a full
>> reinstall to fix the error.
>
> And how typical user will fix the problem with corrupted primary
> header after successful boot? I mean, use alternative header (without
> force_gpt) is a good idea if we know that user will not ignore the
> problem. The current solution is to force user to do anything.
>
> It would be nice to have support for this issue in userspace
> and switch for example to single user mode, or so...
>
> I'm also have doubts that printk() is the best way how to report
> this issue to userspace if we want to trigger any action :-)

Presumably:

* We ended up in this situation because something (auto update,
partition resizer, etc) was making changes to the GPT and got
interrupted (power cycle, crash, etc).

* The something that was making changes will run again after the
system boots up.

* The something that was making changes will presumably be smart
enough to figure out how to fix things up.

* If we can't even boot up, that something has no chance...


...or, if we ended up in this situation because a cosmic ray hit our
storage device and corrupted the primary GPT then I'd say that we
should keep using the alternate and not care that userspace won't do
anything to fix it.  Hopefully cosmic rays are super rare and the
changes of a second one hitting and killing the secondary GPT are slim
to none.  If you're using this disk in outer space and cosmic rays are
common, presumably you've got some massive ECC going on and maybe you
even have userspace that expects periodic sector failures and knows
how to handle it.


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



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux