On Tue, Feb 23, 2010 at 4:10 PM, Neil Brown wrote:
> On Tue, 23 Feb 2010 07:27:00 +0100
> martin f krafft wrote:
>
>> also sprach Neil Brown [2010.02.23.0330 +0100]:
>> > The problem to protect against is any consequence of rearranging
>> > devices while the host is off, including attaching devi
On Tue, 23 Feb 2010 07:27:00 +0100
martin f krafft wrote:
> also sprach Neil Brown [2010.02.23.0330 +0100]:
> > The problem to protect against is any consequence of rearranging
> > devices while the host is off, including attaching devices that
> > previously were attached to a different compute
also sprach Neil Brown [2010.02.23.0330 +0100]:
> The problem to protect against is any consequence of rearranging
> devices while the host is off, including attaching devices that
> previously were attached to a different computer.
How often does this happen, and how grave/dangerous are the effe
On Mon, 22 Feb 2010 10:16:32 +0100
martin f krafft wrote:
> also sprach Piergiorgio Sartor [2010.02.21.2113
> +0100]:
> > I do not see how the "homehost" plays a role, here.
>
> Neil,
>
> Could you please put forth the argument for why the homehost must
> match, and why unconditional auto-ass
> Could you please put forth the argument for why the homehost must
> match, and why unconditional auto-assembly is not desirable?
> Realistically, what problems are we protecting against?
I can think of one or two.
In the case of network boot, where the kernel and initrd served up via
tftp, bu
On Mon, 2010-02-22 at 10:11 +0100, martin f krafft wrote:
> also sprach Goswin von Brederlow [2010.02.22.0806 +0100]:
> > > Yes, it would be useful to have a system UUID that could be
> > > generated by the installer and henceforth written to the newly
> > > installed system. This is probably some
also sprach Piergiorgio Sartor [2010.02.21.2113
+0100]:
> I do not see how the "homehost" plays a role, here.
Neil,
Could you please put forth the argument for why the homehost must
match, and why unconditional auto-assembly is not desirable?
Realistically, what problems are we protecting again
also sprach Michael Evans [2010.02.22.0837 +0100]:
> I don't know how whatever was mentioned previously would work for
> that, but I do have a solution.
[…]
> Incremental assembly, or examine with all block devices to
> generate a new mdadm.conf file.
Please see the thread for reasons why incre
also sprach Goswin von Brederlow [2010.02.22.0806 +0100]:
> > Yes, it would be useful to have a system UUID that could be
> > generated by the installer and henceforth written to the newly
> > installed system. This is probably something the LSB should push.
> > But you could also bring it up for
On Sun, Feb 21, 2010 at 11:06 PM, Goswin von Brederlow
wrote:
> martin f krafft writes:
>
>> also sprach Daniel Reurich [2010.02.19.0351 +0100]:
>>> But if a generated 'system uuid' value (I just suggested the root fs
>>> UUID because it would be highly unlikely to be unchanged, and nobody
>>> w
martin f krafft writes:
> also sprach Daniel Reurich [2010.02.19.0351 +0100]:
>> But if a generated 'system uuid' value (I just suggested the root fs
>> UUID because it would be highly unlikely to be unchanged, and nobody
>> would be likely to fiddle with it) was copied into a file
>> called /et
Hi,
> Indeed, it does. However, I could not find out how it does device
> naming? From what I understand, mdadm will only assemble devices
> using the name stored in the superblocks iff the homehost matches,
> so dracut either doesn't provide for this and requires the use of
> UUIDs to mount files
On Sun, 2010-02-21 at 20:11 +0100, martin f krafft wrote:
> also sprach Daniel Reurich [2010.02.21.2004 +0100]:
> > On Sun, 2010-02-21 at 18:14 +0100, martin f krafft wrote:
> > > also sprach Daniel Reurich [2010.02.19.0351
> > > +0100]:
> > > > But if a generated 'system uuid' value (I just sug
On Mon, 2010-02-22 at 08:04 +1300, Daniel Reurich wrote:
> On Sun, 2010-02-21 at 18:14 +0100, martin f krafft wrote:
> > also sprach Daniel Reurich [2010.02.19.0351
> > +0100]:
> > > But if a generated 'system uuid' value (I just suggested the root fs
> > > UUID because it would be highly unlikel
also sprach Daniel Reurich [2010.02.21.2004 +0100]:
> On Sun, 2010-02-21 at 18:14 +0100, martin f krafft wrote:
> > also sprach Daniel Reurich [2010.02.19.0351
> > +0100]:
> > > But if a generated 'system uuid' value (I just suggested the root fs
> > > UUID because it would be highly unlikely to
On Sun, 2010-02-21 at 18:14 +0100, martin f krafft wrote:
> also sprach Daniel Reurich [2010.02.19.0351 +0100]:
> > But if a generated 'system uuid' value (I just suggested the root fs
> > UUID because it would be highly unlikely to be unchanged, and nobody
> > would be likely to fiddle with it) w
also sprach Piergiorgio Sartor [2010.02.19.1016
+0100]:
> There is the kernel boot paramenter "rd_NO_MDADMCONF", which
> forces "dracut" to do not use the "mdadm.conf" in the initramfs
> image.
>
> My impression is that it uses the "mdadm -I" functionality.
Indeed, it does. However, I could not
also sprach Daniel Reurich [2010.02.19.0351 +0100]:
> But if a generated 'system uuid' value (I just suggested the root fs
> UUID because it would be highly unlikely to be unchanged, and nobody
> would be likely to fiddle with it) was copied into a file
> called /etc/system_uuid and copied into th
Hi,
> True. You'd have to update the superblock UUID right after creation
> of the filesystem. That doesn't sound like a robust strategy to
> making mdadm.conf optional.
it seems that, with "dracut", "mdadm.conf" is optional.
There is the kernel boot paramenter "rd_NO_MDADMCONF",
which forces "d
On Fri, 2010-02-19 at 13:42 +1300, martin f krafft wrote:
> also sprach Neil Brown [2010.02.18.1834 +1300]:
> > But it would be rather awkward to store the uuid of the root
> > filesystem in the metadata for the array that stores the root
> > filesystem (and so is created before the root filesyste
also sprach Neil Brown [2010.02.18.1834 +1300]:
> But it would be rather awkward to store the uuid of the root
> filesystem in the metadata for the array that stores the root
> filesystem (and so is created before the root filesystem)...
True. You'd have to update the superblock UUID right after
21 matches
Mail list logo
