[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87fufta2gi.fsf@concordia.ellerman.id.au>
Date: Thu, 25 May 2017 16:13:33 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Rob Landley <rob@...dley.net>,
Yury Norov <ynorov@...iumnetworks.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
Prarit Bhargava <prarit@...hat.com>,
Yang Shi <yang.shi@...aro.org>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Kees Cook <keescook@...omium.org>,
Emese Revfy <re.emese@...il.com>,
Petr Mladek <pmladek@...e.com>,
Fabian Frederick <fabf@...net.be>
Subject: Re: Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS_MOUNT") breaks boot
Hi Rob,
This is breaking a bunch of my powerpc boxes, for the exact same reason,
they use a config that has DEVTMPFS_MOUNT=y and that trips up the
initramfs.
Rob Landley <rob@...dley.net> writes:
> On 05/23/2017 03:01 AM, Yury Norov wrote:
>> On Mon, May 22, 2017 at 09:07:54PM -0500, Rob Landley wrote:
>>> Your userspace mounted a tmpfs over /dev when it couldn't mount a second
>>> identical instance of devtmpfs over itself. If you had a static /dev in
>>> initramfs but didn't configure _in_ devtmpfs to your kernel, your broken
>>> error path would have taken that out too with a pointless tmpfs mount.
>>
>> CONFIG_DEVTMPFS_MOUNT is enabled on my machine, so I think your
>> suggestion is correct. But I didn't do that specifically - I run
>> almost default kernel based on Ubuntu 14.04 config and environment.
>
> I.E. ubuntu has a bug: they enabled CONFIG_DEVTMPFS_MOUNT and then
> launchd an initramfs instead (which didn't do the automount they
> requested so why request it), but if CONFIG_DEVTMPFS_MOUNT actually
> starts working in initramfs they have an insane error path that breaks
> the system, and does nothing _except_ break the system.
Sure. But prior to your patch the only reason mounting devtmpfs could
fail was because of something being broken, it was never automatically
mounted. So we've changed the set of possibilities out from under the
initramfs scripts.
I agree it's not the greatest error handling ever, but it's pretty rude
to break booting on existing working setups. If nothing else it makes
bisection a nightmare.
>> So the proper way is to remove broken
>> config option and introduce new one. BTW, I see it is used once in
>> drivers/base/devtmpfs.c.
>
> How does removing the broken config option (or renaming it to
> CONFIG_DEFTMPFS_UBUNTU_IS_BROKEN) _not_ impact systems that were
> previously happily using it in the contexts where it already worked?
I don't think that's what Yury's suggesting, and indeed it wouldn't work.
What would work, is to add a new config option, perhaps
CONFIG_DEVTMPFS_MOUNT_INITRAMFS, which is 'default n'. Then existing
setups continue to work, and people who want it mounted in the initramfs
can enable the new option.
cheers
Powered by blists - more mailing lists