From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Evans Subject: Bug#567468: (boot time consequences of) Linux mdadm superblock question. Date: Sun, 21 Feb 2010 23:37:49 -0800 Message-ID: <4877c76c1002212337i36f208dcyd1be7a93625d2a6@mail.gmail.com> References: <20100218102407.49f73d67@notabene.brown> <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> <873a0t4ume.fsf@frosties.localdomain> Reply-To: Michael Evans , 567468@bugs.debian.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: Resent-To: debian-bugs-dist@lists.debian.org Resent-Message-ID: In-Reply-To: <873a0t4ume.fsf@frosties.localdomain> List-Post: List-Help: List-Subscribe: List-Unsubscribe: To: Goswin von Brederlow Cc: Daniel Reurich , Neil Brown , linux-raid , 567468@bugs.debian.org List-Id: linux-raid.ids On Sun, Feb 21, 2010 at 11:06 PM, Goswin von Brederlow wrote: > martin f krafft writes: > >> also sprach Daniel Reurich [2010.02.19.0351 +0= 100]: >>> 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 th= e >>> homehost variable in the boot time required raid volumes when ever a ne= w >>> initrd is installed. =A0(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. =A0If 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 > =A0 =A0 =A0 =A0Goswin > -- > 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 =A0http://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.