From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Reurich Subject: Re: Bug#567468: (boot time consequences of) Linux mdadm superblock question. Date: Mon, 22 Feb 2010 23:42:22 +1300 Message-ID: <1266835342.24834.333.camel@localhost.localdomain> References: <20100218032610.GB1991@lapse.rw.madduck.net> <1266465801.11568.183.camel@localhost.localdomain> <20100218044004.GC5136@lapse.rw.madduck.net> <20100218161012.704b43a6@notabene.brown> <20100218052145.GA7178@lapse.rw.madduck.net> <20100218163448.0d3f3107@notabene.brown> <20100219004237.GC25162@lapse.rw.madduck.net> <1266547875.11568.1552.camel@localhost.localdomain> <20100221171445.GB17267@lapse.rw.madduck.net> <873a0t4ume.fsf@frosties.localdomain> <20100222091110.GC2641@lapse.rw.madduck.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100222091110.GC2641@lapse.rw.madduck.net> Sender: linux-raid-owner@vger.kernel.org To: martin f krafft Cc: Goswin von Brederlow , 567468@bugs.debian.org, Neil Brown , linux-raid List-Id: linux-raid.ids 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 something the LSB should push. > > > But you could also bring it up for discussion on debian-devel. > > > > How would that work with network boot where the initrd would have to > > work for multiple hosts? > > Right now, that doesn't work either, except with the traditional > method of simply assembling all arrays found. Neil has implemented > the homehost feature to prevent that. Arguably that's to protect > against a circumstance that is rather rare, and one might not > want/need it. However, if used, then it is true: > > Unless the homehost in the superblock matches the local value, you > need mdadm.conf to assemble the devices, because the superblock > information won't be trusted if the homehost doesn't match. > > To be able to determine whether the homehost matches, you need to > know the value for the system after the initramfs was unpacked. > Therefore, the homehost value must either be stored in the > initramfs, which makes it non-portable, or we must use a unique > identifier of the system that is available from ROM, e.g. the CPU > ID. I don't think that's standardised. Actually, in this case one could use the dhcp assigned hostname or boot network cards mac address to provide the homehost search string. -- Daniel Reurich. Centurion Computer Technology (2005) Ltd Mobile 021 797 722