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 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 <madd...@d.o>      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/)

Reply via email to