Bug#567468: (boot time consequences of) Linux mdadm superblock question.
On Sun, 2010-02-21 at 20:11 +0100, martin f krafft wrote:
> also sprach Daniel Reurich <daniel@centurion.net.nz> [2010.02.21.2004 +0100]:
> > 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
>
> You said "update the homehost variable in the boot time required
> raid volumes initrd is installed."
>
I was referring to "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"
I should rephrase this to: We could use an 'OS install time' generated
'system uuid' which could simply be the root filesystems uuid copied
into a file, that get's included in the initrd image. This 'system
uuid' could then be used as the homehost value for mdadm auto assembly
purposes.
> > > > 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.
>
> No, because the whole point of homehost is that it should not be
> automatically updated.
>
Your right. It should only be updated if it differs when
initramfs-tools runs, because it's what's in the initrd that will count
(at least for mdadm assembly purposes).
--
Daniel Reurich.
Centurion Computer Technology (2005) Ltd
Mobile 021 797 722
Reply to: