Re: Bug#567468: (boot time consequences of) Linux mdadm superblock question.

[Daniel Reurich <daniel@centurion.net.nz>]

On Mon, 2010-02-22 at 10:11 +0100, martin f krafft wrote:
> also sprach Goswin von Brederlow <goswin-v-b@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 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