On Tue, 23 Feb 2010 07:27:00 +0100
martin f krafft madd...@madduck.net wrote:
also sprach Neil Brown ne...@suse.de [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
On Tue, Feb 23, 2010 at 4:10 PM, Neil Brown ne...@suse.de wrote:
On Tue, 23 Feb 2010 07:27:00 +0100
martin f krafft madd...@madduck.net wrote:
also sprach Neil Brown ne...@suse.de [2010.02.23.0330 +0100]:
The problem to protect against is any consequence of rearranging
devices while the
On Sun, Feb 21, 2010 at 11:06 PM, Goswin von Brederlow
goswin-...@web.de wrote:
martin f krafft madd...@madduck.net writes:
also sprach Daniel Reurich dan...@centurion.net.nz [2010.02.19.0351 +0100]:
But if a generated 'system uuid' value (I just suggested the root fs
UUID because it would be
also sprach Goswin von Brederlow goswin-...@web.de [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
also sprach Michael Evans mjevans1...@gmail.com [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
also sprach Piergiorgio Sartor piergiorgio.sar...@nexgo.de [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
On Mon, 2010-02-22 at 10:11 +0100, martin f krafft wrote:
also sprach Goswin von Brederlow goswin-...@web.de [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
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, but
On Mon, 22 Feb 2010 10:16:32 +0100
martin f krafft madd...@madduck.net wrote:
also sprach Piergiorgio Sartor piergiorgio.sar...@nexgo.de [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
also sprach Neil Brown ne...@suse.de [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
also sprach Daniel Reurich dan...@centurion.net.nz [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
also sprach Piergiorgio Sartor piergiorgio.sar...@nexgo.de [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.
also sprach Daniel Reurich dan...@centurion.net.nz [2010.02.21.2004 +0100]:
On Sun, 2010-02-21 at 18:14 +0100, martin f krafft wrote:
also sprach Daniel Reurich dan...@centurion.net.nz [2010.02.19.0351
+0100]:
But if a generated 'system uuid' value (I just suggested the root fs
UUID
On Sun, 2010-02-21 at 18:14 +0100, martin f krafft wrote:
also sprach Daniel Reurich dan...@centurion.net.nz [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
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 dan...@centurion.net.nz [2010.02.19.0351
+0100]:
But if a generated 'system uuid' value (I just suggested the root fs
UUID because it would be
On Sun, 2010-02-21 at 20:11 +0100, martin f krafft wrote:
also sprach Daniel Reurich dan...@centurion.net.nz [2010.02.21.2004 +0100]:
On Sun, 2010-02-21 at 18:14 +0100, martin f krafft wrote:
also sprach Daniel Reurich dan...@centurion.net.nz [2010.02.19.0351
+0100]:
But if a
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
martin f krafft madd...@madduck.net writes:
also sprach Daniel Reurich dan...@centurion.net.nz [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)
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 dracut to
On Fri, 2010-02-19 at 13:42 +1300, martin f krafft wrote:
also sprach Neil Brown ne...@suse.de [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
also sprach Neil Brown ne...@suse.de [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
21 matches
Mail list logo
