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 :-) Holding the whole system hostage and forcing manual action is *not* user-friendly behavior. Linux is no longer just something for hobbyist hackers to install on their converted Windows machines at home... it is a mature, modern operating system kernel used on a wide range of devices (server farms, phones, embedded systems, etc.) and it should behave like one. Not all of these platforms necessarily make it easy for the user to drop into grub and add some command line parameters, and it's the kernel's job to provide a suitable environment for all of them so that policy decisions can be left to userspace. So yes, userspace should resolve this problem, but in order to do that you need to allow userspace to boot first! dmesg is one suitable way to communicate the problem, and there are others which I wouldn't be opposed to either, but no matter which channel we choose the kernel still has to continue booting to allow the rest of the OS to deal with it. Whether to ignore, silently repair or fail to boot from a corrupted primary GPT is a policy decision and it should be made in user space... if you need to retain the current behavior, it's easy to add an init script that greps for GPT warnings and hangs to your distro. -- 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
