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
