[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Sun, 2010-02-21 at 18:14 +0100, martin f krafft wrote:
> 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.

I said copy
> 
> > 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.

We could use the mdadm to fix it though to ensure the system won't end
up in an unbootable state. 
> 
> > 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.
> 
I guess it's about time I subscribed to that list too then.



-- 
Daniel Reurich.

Centurion Computer Technology (2005) Ltd
Mobile 021 797 722






Reply to: