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 stu
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 b
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
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 re
Possibly 'multirootdelay'?
I had the same thought, but wanted to avoid using any prefix other than
root*= since it would break tradition for this part of the kernel.
However, is there any case you can think of for wanting the values to be
different between rootdelay and the per-device scan d
On 2015-09-17 14:40, Richard Weinberger wrote:
Am 17.09.2015 um 20:37 schrieb Austin S Hemmelgarn:
On 2015-09-17 13:47, Richard Weinberger wrote:
On Thu, Sep 17, 2015 at 1:49 PM, Drew DeVault wrote:
On 2015-09-17 1:40 PM, Ortwin Glück wrote:
You can do that completely in user space from an
On 2015-09-17 13:30, Drew DeVault wrote:
That said, using the term failover for this is probably not the best
idea, many people associate it almost exclusively with online failover
and high-availability setups, and trying to do something like that with
the root file system is just asking for trou
Am 17.09.2015 um 20:35 schrieb Drew DeVault:
>> 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
Am 17.09.2015 um 20:37 schrieb Austin S Hemmelgarn:
> On 2015-09-17 13:47, Richard Weinberger wrote:
>> On Thu, Sep 17, 2015 at 1:49 PM, Drew DeVault 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 th
On 2015-09-17 13:47, Richard Weinberger wrote:
On Thu, Sep 17, 2015 at 1:49 PM, Drew DeVault 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. B
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 f
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: s
Am 17.09.2015 um 20:27 schrieb Harald Hoyer:
> 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.
>
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 majord...@vger.ke
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 -
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 n
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 mill
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
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?
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 DeVa
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
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= pa
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
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
On Thu, Sep 17, 2015 at 1:49 PM, Drew DeVault 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
That said, using the term failover for this is probably not the best
idea, many people associate it almost exclusively with online failover
and high-availability setups, and trying to do something like that with
the root file system is just asking for trouble (I'll be happy to go
into specifics as
On 2015-09-16 20:16, Drew DeVault wrote:
I would like to see Linux support multiple root devices, so that it can
attempt one and move on to the next if it is not present. I've reviewed
the relevant code during boot-up and it seems like a good place for me
to submit my first patch, but I want to b
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 va
> 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
I would like to see Linux support multiple root devices, so that it can
attempt one and move on to the next if it is not present. I've reviewed
the relevant code during boot-up and it seems like a good place for me
to submit my first patch, but I want to bring it up for discussion here
on LKML firs
30 matches
Mail list logo
