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

[Michael Evans <mjevans1983@gmail.com>]

On Sun, Feb 21, 2010 at 11:06 PM, Goswin von Brederlow
<goswin-v-b@web.de> wrote:
> martin f krafft <madduck@madduck.net> writes:
>
>> also sprach Daniel Reurich <daniel@centurion.net.nz> [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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

I don't know how whatever was mentioned previously would work for
that, but I do have a solution.

Incremental assembly, or examine with all block devices to generate a
new mdadm.conf file.  Then run only devices which are in a complete
state.  The next step would be not mount by uuid, but mount by label.
Presuming you have a consistently labeled rootfs in your deployment
(say mandating that the / filesystem be labeled 'root' or some other
value and that no other FS may share that same label) then it should
work out just fine.