On Mon, 2010-02-22 at 10:11 +0100, martin f krafft wrote: > also sprach Goswin von Brederlow <goswin-v-b@xxxxxx> [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 -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
