Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1226943 > unrolled thread

Re: Failover root devices

Back to article view | Back to linux.kernel

Contents

  Re: Failover root devices Ortwin Glück <odi@odi.ch> - 2015-09-17 13:50 +0200
    Re: Failover root devices Drew DeVault <sir@cmpwn.com> - 2015-09-17 14:00 +0200
      Re: Failover root devices Richard Weinberger <richard.weinberger@gmail.com> - 2015-09-17 19:50 +0200
        Re: Failover root devices Drew DeVault <sir@cmpwn.com> - 2015-09-17 19:50 +0200
          Re: Failover root devices Richard Weinberger <richard@nod.at> - 2015-09-17 20:00 +0200
            Re: Failover root devices Drew DeVault <sir@cmpwn.com> - 2015-09-17 20:10 +0200
              Re: Failover root devices Richard Weinberger <richard@nod.at> - 2015-09-17 20:20 +0200
                Re: Failover root devices Drew DeVault <sir@cmpwn.com> - 2015-09-17 20:20 +0200
                  Re: Failover root devices Richard Weinberger <richard@nod.at> - 2015-09-17 20:20 +0200
                    Re: Failover root devices Drew DeVault <sir@cmpwn.com> - 2015-09-17 20:30 +0200
                      Re: Failover root devices Drew DeVault <sir@cmpwn.com> - 2015-09-17 20:30 +0200
                        Re: Failover root devices Ortwin Glück <odi@odi.ch> - 2015-09-18 17:00 +0200
                          Re: Failover root devices Drew DeVault <sir@cmpwn.com> - 2015-09-18 17:10 +0200
                            Re: Failover root devices Ortwin Glück <odi@odi.ch> - 2015-09-18 17:10 +0200
                              Re: Failover root devices Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-18 17:40 +0200
                      Re: Failover root devices Richard Weinberger <richard@nod.at> - 2015-09-17 20:30 +0200
                Re: Failover root devices Harald Hoyer <harald.hoyer@gmail.com> - 2015-09-17 20:30 +0200
                  Re: Failover root devices Drew DeVault <sir@cmpwn.com> - 2015-09-17 20:30 +0200
                    Re: Failover root devices Richard Weinberger <richard@nod.at> - 2015-09-17 20:40 +0200
                      Re: Failover root devices Drew DeVault <sir@cmpwn.com> - 2015-09-17 20:40 +0200
                        Re: Failover root devices Richard Weinberger <richard@nod.at> - 2015-09-17 20:50 +0200
                  Re: Failover root devices Richard Weinberger <richard@nod.at> - 2015-09-17 20:30 +0200
        Re: Failover root devices Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-17 20:40 +0200
          Re: Failover root devices Richard Weinberger <richard@nod.at> - 2015-09-17 20:50 +0200
            Re: Failover root devices Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-18 16:50 +0200

Page 1 of 2  [1] 2  Next page →

#1226943 — Re: Failover root devices

 > I would like to see Linux support multiple root devices

You can do that completely in user space from an initramfs.

 From your init script you can do what you want. You may even parse /proc/cmdline and use the root= 
parameter as you propose. Then mount whatever root device you want by whatever method you like and 
finally
  exec switch_root /mnt/root /sbin/init "$@"

See here for example scripts for initramfs:
http://www.linuxfromscratch.org/blfs/view/svn/postlfs/initramfs.html

Above script actually makes it easy by supporting disk labels: root=LABEL=ROOT will boot the first 
available partition that is labelled ROOT. It is independent of the device name and works nice when 
you switch hardware vs. virtual machines for instance.

Ortwin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1226945

On 2015-09-17  1:40 PM, Ortwin Glück wrote:
> You can do that completely in user space from an initramfs.

Yep, I'm aware of that. I think it would still be useful for the kernel
to support it. Bonus - if the kernel supports it, there's a standard way
of doing it that would propegate down to the various initramfs designs
of the distros without having me write patches against all of them.
Right?

I'm working on an initramfs-based solution that meets my own needs, for
what it's worth.

> Above script actually makes it easy by supporting disk labels:
> root=LABEL=ROOT will boot the first available partition that is labelled
> ROOT. It is independent of the device name and works nice when you switch
> hardware vs. virtual machines for instance.

This is a neat idea, I'll check it out.

--
Drew DeVault
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1227256

On Thu, Sep 17, 2015 at 1:49 PM, Drew DeVault <sir@cmpwn.com> wrote:
> On 2015-09-17  1:40 PM, Ortwin Glück wrote:
>> You can do that completely in user space from an initramfs.
>
> Yep, I'm aware of that. I think it would still be useful for the kernel
> to support it. Bonus - if the kernel supports it, there's a standard way
> of doing it that would propegate down to the various initramfs designs
> of the distros without having me write patches against all of them.
> Right?

I really don't see why we need this feature in-kernel as it can be
done perfectly fine
in userspace. Every non-trivial system needs an initramfs anyway these days.

-- 
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1227257

> I really don't see why we need this feature in-kernel as it can be
> done perfectly fine
> in userspace. Every non-trivial system needs an initramfs anyway these days.

Most initramfs systems will parse the root= line of your kernel command 
line and use it to remount root. The kernel seems like the best place to 
establish this, since the various initramfs solutions will implement the 
same format just to support parsing the kernel command line correctly. I 
mean, maybe that's not enough to justify putting it in the kernel, but 
that's why I see the kernel as the appropriate place to implement this 
feature.

--
Drew DeVault
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1227263

Am 17.09.2015 um 19:49 schrieb Drew DeVault:
>> I really don't see why we need this feature in-kernel as it can be
>> done perfectly fine
>> in userspace. Every non-trivial system needs an initramfs anyway these days.
> 
> Most initramfs systems will parse the root= line of your kernel command line and use it to remount root. The kernel seems like the best place to establish this, since the various
> initramfs solutions will implement the same format just to support parsing the kernel command line correctly. I mean, maybe that's not enough to justify putting it in the kernel,
> but that's why I see the kernel as the appropriate place to implement this feature.

Better send a patch to dracut folks. :-)
Major distros use it and if the feature is nice other initramfs implementations will adopt it too.

Thanks,
//richard

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1227269

> Better send a patch to dracut folks. :-)
> Major distros use it and if the feature is nice other initramfs implementations will adopt it too.

dracut is the common one sure, but I'm still not confident that it's the 
right place to put this. How would that feature look? Would we have the 
root= parameter use a format that's specific to dracut and no longer a 
sane kernel parameter? Would we use a second parameter and discard the 
root= parameter? I think all of these are suboptimal solutions. No, the 
right way, I think, is to implement this in the kernel and let the init 
systems take it from there themselves.

--
Drew DeVault
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1227278

Am 17.09.2015 um 20:05 schrieb Drew DeVault:
>> Better send a patch to dracut folks. :-)
>> Major distros use it and if the feature is nice other initramfs implementations will adopt it too.
> 
> dracut is the common one sure, but I'm still not confident that it's the right place to put this. How would that feature look? Would we have the root= parameter use a format that's
> specific to dracut and no longer a sane kernel parameter? Would we use a second parameter and discard the root= parameter? I think all of these are suboptimal solutions. No, the
> right way, I think, is to implement this in the kernel and let the init systems take it from there themselves.

I'd patch dracut to support kernel command lines like "root=/dev/diskX root=/dev/diskY". initramfs is allowed to parse/use the command line.
So, you can do what you want.

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1227281

> I'd patch dracut to support kernel command lines like "root=/dev/diskX root=/dev/diskY". initramfs is allowed to parse/use the command line.
> So, you can do what you want.

Is there precedent for using the same parameter name several times? That 
sounds dangerous and short-sighted.

--
Drew DeVault
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1227282

Am 17.09.2015 um 20:18 schrieb Drew DeVault:
>> I'd patch dracut to support kernel command lines like "root=/dev/diskX root=/dev/diskY". initramfs is allowed to parse/use the command line.
>> So, you can do what you want.
> 
> Is there precedent for using the same parameter name several times? That sounds dangerous and short-sighted.

Depends on how you patch dracut. ;-)
You can also add a "try_roots=/dev/diskX;/dev/diskY"...

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1227304

> Depends on how you patch dracut. ;-)
> You can also add a "try_roots=/dev/diskX;/dev/diskY"...

That comes back around to my earlier email:

 >Would we use a second parameter and discard the root= parameter? I 
 >think all of these are suboptimal solutions.

I'm not a fan of this idea. What downside is there to implementing it in 
the kernel? It trickles down in a consistent way and bonus points for 
supporting systems that don't use an initramfs.

--
Drew DeVault
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1227305

> The kernel is already super complicated and has millions of lines of code. If it can be done nicely in userspace, let's do it there
> and keep the kernel maintainable.

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.

--
Drew DeVault
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1227964

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1227996

> 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)?

I don't think these are problems that aren't already inherent in a 
single root device via root=.

> 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.

If you have physical access then the machine is yours to do with as you 
please.

--
Drew DeVault
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1228006

> If you have physical access then the machine is yours to do with as you please.

Thinking of ATMs or voting machines that is a bold statement :-)

Thinking of mobile phones it depends on your jurisdiction.

Ortwin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1228074

[Multipart message — attachments visible in raw view] — view raw

On 2015-09-18 11:04, Ortwin Glück wrote:
>> If you have physical access then the machine is yours to do with as
>> you please.
>
> Thinking of ATMs or voting machines that is a bold statement :-)
Many voting machines already have known ACE exploits already (I 
distinctly remember a while back some CS students demonstrated a 
'modern' voting machine playing PAC-Man without modifying any of the 
hardware at all), and those that have network access or other accessible 
peripheral connections are inherently insecure, period.

And most ATM's (at least in the US) run Windows (_shivers_) XP or 
eCommStation (the current commercial version of OS/2 (yes it still lives 
on), neither of which is particularly secure even when it comes to 
remote access to the system, and even then, the kind of access you need 
would involve3 directly tampering with the system.

Irrespective of that, neither one should be configured to work like 
that.  The intent is for custom setups primarily, if some company 
decides to use this in an insecure way, that's their problem, not ours 
(it's really easy to use a wide number of kernel features in ways that 
compromise security, that doesn't mean we should just rip those out).
>
> Thinking of mobile phones it depends on your jurisdiction.
This isn't a legal ruling, it's a simple statement of fact, if someone 
has physical access to a system, they effectively have root access, 
period.  While this is not probably what the above comment was directly 
referring to, it is an established fact.

[toc] | [prev] | [next] | [standalone]

#1227307

Am 17.09.2015 um 20:21 schrieb Drew DeVault:
> I'm not a fan of this idea. What downside is there to implementing it in the kernel? It trickles down in a consistent way and bonus points for supporting systems that don't use an
> initramfs.

The kernel is already super complicated and has millions of lines of code. If it can be done nicely in userspace, let's do it there
and keep the kernel maintainable.

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1227297

On 17.09.2015 20:17, Richard Weinberger wrote:
> Am 17.09.2015 um 20:05 schrieb Drew DeVault:
>>> Better send a patch to dracut folks. :-)
>>> Major distros use it and if the feature is nice other initramfs implementations will adopt it too.
>>
>> dracut is the common one sure, but I'm still not confident that it's the right place to put this. How would that feature look? Would we have the root= parameter use a format that's
>> specific to dracut and no longer a sane kernel parameter? Would we use a second parameter and discard the root= parameter? I think all of these are suboptimal solutions. No, the
>> right way, I think, is to implement this in the kernel and let the init systems take it from there themselves.
> 
> I'd patch dracut to support kernel command lines like "root=/dev/diskX root=/dev/diskY". initramfs is allowed to parse/use the command line.
> So, you can do what you want.
> 
> Thanks,
> //richard


https://github.com/haraldh/dracut/blob/master/modules.d/95rootfs-block/rootfallback.sh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1227301

> https://github.com/haraldh/dracut/blob/master/modules.d/95rootfs-block/rootfallback.sh

Neat. Did you ever submit this upstream? Is there a discussion to read?

--
Drew DeVault
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1227311

Am 17.09.2015 um 20:29 schrieb Drew DeVault:
>> https://github.com/haraldh/dracut/blob/master/modules.d/95rootfs-block/rootfallback.sh
> 
> Neat. Did you ever submit this upstream? Is there a discussion to read?

Harald is the main developer...

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1227322

> Harald is the main developer...

Hah, egg on my face. I still see one big issue with this - no waiting 
for the root device to come online. If the primary device is slow to get 
going, then it will be skipped in favor of the secondary device even if 
present.

--
Drew DeVault
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web