From mboxrd@z Thu Jan 1 00:00:00 1970 From: Goswin von Brederlow Subject: Re: (boot time consequences of) Linux mdadm superblock question. Date: Mon, 22 Feb 2010 08:06:33 +0100 Message-ID: <873a0t4ume.fsf@frosties.localdomain> References: <20100218102407.49f73d67@notabene.brown> <20100218025809.GA20358@khazad-dum.debian.net> <20100218032610.GB1991@lapse.rw.madduck.net> <1266465801.11568.183.camel@localhost.localdomain> <20100218044004.GC5136@lapse.rw.madduck.net> <20100218161012.704b43a6@notabene.brown> <20100218052145.GA7178@lapse.rw.madduck.net> <20100218163448.0d3f3107@notabene.brown> <20100219004237.GC25162@lapse.rw.madduck.net> <1266547875.11568.1552.camel@localhost.localdomain> <20100221171445.GB17267@lapse.rw.madduck.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: <20100221171445.GB17267@lapse.rw.madduck.net> (martin f. krafft's message of "Sun, 21 Feb 2010 18:14:45 +0100") Sender: linux-raid-owner@vger.kernel.org To: Daniel Reurich Cc: Neil Brown , linux-raid , 567468@bugs.debian.org List-Id: linux-raid.ids martin f krafft writes: > also sprach Daniel Reurich [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