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. If auto-assembly of all RAIDs bears dangers and must be regulated, then we must either have host-specific initramfs's, or be able to determine the homehost value early during boot otherwise. -- .''`. martin f. krafft <madduck@xxx> Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduck http://vcs-pkg.org `- Debian - when you have better things to do than fixing systems
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
