From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754760AbbIRO7T (ORCPT ); Fri, 18 Sep 2015 10:59:19 -0400 Received: from [62.179.121.32] ([62.179.121.32]:57040 "EHLO fep12.mx.upcmail.net" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752205AbbIRO7Q (ORCPT ); Fri, 18 Sep 2015 10:59:16 -0400 X-SourceIP: 77.58.229.21 X-Authenticated-Sender: odi.ch@hispeed.ch Subject: Re: Failover root devices To: Drew DeVault , Richard Weinberger References: <55FAA6BB.3060008@odi.ch> <20150917114955.GA2600@homura> <55FAFD1D.8030305@cmpwn.com> <55FAFDE1.2020707@nod.at> <55FB00E6.3090801@cmpwn.com> <55FB03B8.2000101@nod.at> <55FB03E8.3000604@cmpwn.com> <55FB0441.6040709@nod.at> <55FB0498.9060301@cmpwn.com> <55FB0531.3050006@nod.at> <55FB0646.1020704@cmpwn.com> Cc: "linux-kernel@vger.kernel.org" From: =?UTF-8?Q?Ortwin_Gl=c3=bcck?= Message-ID: <55FC26B5.7080308@odi.ch> Date: Fri, 18 Sep 2015 16:59:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55FB0646.1020704@cmpwn.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17.09.2015 20:28, Drew DeVault wrote: > I don't think this is a strong argument against this feature. The implementation of this feature > will be pretty straightfoward - only a small part of the code has to actually change its behavior > and it can do without changing the interfaces it already relies on. On top of that, I don't think it > can be done "nicely" in userspace anyway. I personally think this is opening a can of worms. Now it's just a list of alternative root devices. But the kernel knows absolutely nothing about these. When is it fine to try an alternative? Why did the first one not work? Did we just not wait long enough? Or is it a failed RAID device? Or is it an encrypted disk that needs setup? Or is it on NFS and the network is not available (or we are lacking driver firmware)? It could actually introduce security problems: if I know that a device will fallback to an alternative root (under my control), I can try and DOS the primary root. In short: if a simple root device doesn't work for you, you should *really* use an initramfs. One could even argue to remove the boot= parameter altogether and always use initramfs :-) Ortwin