martin f krafft <madduck@xxxxxxxxxxx> writes:
> also sprach Daniel Reurich <daniel@xxxxxxxxxxxxxxxx> [2010.02.19.0351 +0100]:
>> But if a generated 'system uuid' value (I just suggested the root fs
>> UUID because it would be highly unlikely to be unchanged, and nobody
>> would be likely to fiddle with it) was copied into a file
>> called /etc/system_uuid and copied into the initrd, then we could add
>> put into mdadms hook script in initramfs-tools, to verify and update the
>> homehost variable in the boot time required raid volumes when ever a new
>> initrd is installed. (This generally happens on debian whenever a
>> kernel is installed and mdadm is installed or upgraded.
>
> Neil's point is that no such value exists. The root filesystem UUID
> is not available when the array is created. And updating the
> homehost in the RAID metadata at boot time would defeat the purpose
> of homehost in the first place.
>
>> As an added protection we could include checks in mdadm shutdown
>> script a check that warns when mdadm.conf doesn't exist and the
>> /etc/system_uuid doesn't match the homehost value in the boottime
>> assembled raid volumes. If we did use the root filesystem UUID
>> for this, we could compare that as well.
>
> Debian has no policy for this. There is no way to warn a user and
> interrupt the shutdown process.
>
>> It would be useful to have a tool similar to /bin/hostname that
>> could be used to create|read|verify|update the system uuid, which
>> would update all the relevant locations which store and check
>> against this system uuid.
>
> 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?
MfG
Goswin
--
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
