Bug#567468: (boot time consequences of) Linux mdadm superblock question.
On Mon, 2010-02-22 at 10:11 +0100, martin f krafft wrote: also sprach Goswin von Brederlow goswin-...@web.de [2010.02.22.0806 +0100]: 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? Right now, that doesn't work either, except with the traditional method of simply assembling all arrays found. Neil has implemented the homehost feature to prevent that. Arguably that's to protect against a circumstance that is rather rare, and one might not want/need it. However, if used, then it is true: Unless the homehost in the superblock matches the local value, you need mdadm.conf to assemble the devices, because the superblock information won't be trusted if the homehost doesn't match. To be able to determine whether the homehost matches, you need to know the value for the system after the initramfs was unpacked. Therefore, the homehost value must either be stored in the initramfs, which makes it non-portable, or we must use a unique identifier of the system that is available from ROM, e.g. the CPU ID. I don't think that's standardised. Actually, in this case one could use the dhcp assigned hostname or boot network cards mac address to provide the homehost search string. -- Daniel Reurich. Centurion Computer Technology (2005) Ltd Mobile 021 797 722 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1266835342.24834.333.ca...@localhost.localdomain
Bug#567468: md homehost (was: Bug#567468: (boot time consequences of) Linux mdadm superblock) question.
Could you please put forth the argument for why the homehost must match, and why unconditional auto-assembly is not desirable? Realistically, what problems are we protecting against? I can think of one or two. In the case of network boot, where the kernel and initrd served up via tftp, but the required filesystems are per host raid volumes served up ala ATAoverEthernet, iSCSI etc storage network. This could use the boot network device MAC or dhcp assigned hostname to as the homehost search paramater. This would of course require someway to tell mdadm how to obtain this homehost parameter. This could work well where different groups of hosts using different raid volumes for the root (or other) filesystems, each with a MAC group (first 3 or 4 MAC fields) is used to identify that groups homehost search parameter. Another scenario, is a dual boot system that has separate raid volumes for the respective root filesystems, along with a separate initrd image for each OS. A system uuid stored in the initrd would work in this case for the homehost search parameter. -- Daniel Reurich. Centurion Computer Technology (2005) Ltd Mobile 021 797 722 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1266837111.24834.365.ca...@localhost.localdomain
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 dan...@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 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1266779075.24834.22.ca...@localhost.localdomain
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
On Mon, 2010-02-22 at 08:04 +1300, Daniel Reurich wrote: On Sun, 2010-02-21 at 18:14 +0100, martin f krafft wrote: also sprach Daniel Reurich dan...@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 I meant to say: I said copy it into a file that get's stored in the initrd image which can be used for the homehost in mdadm auto-detection of root raid. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1266779436.24834.26.ca...@localhost.localdomain
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 dan...@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 dan...@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 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1266780384.24834.39.ca...@localhost.localdomain
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
On Fri, 2010-02-19 at 13:42 +1300, martin f krafft wrote: also sprach Neil Brown ne...@suse.de [2010.02.18.1834 +1300]: But it would be rather awkward to store the uuid of the root filesystem in the metadata for the array that stores the root filesystem (and so is created before the root filesystem)... True. You'd have to update the superblock UUID right after creation of the filesystem. That doesn't sound like a robust strategy to making mdadm.conf optional. Are you suggesting that when mdadm finds some bits that looks like the form an array it should test-assemble it, look inside for a filesystem, extra the uuid of that filesystem and compare against some known uuid before deciding whether to assemble that array or not? I hope not. Hehe, that would be fun, wouldn't it? ;) So I don't think I know what is really being proposed. I really would like to make mdadm.conf optional and still have things work incrementally from initrd. 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. 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. 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. One could expect LVM would be another prime candidate for system uuid usage to bind vg's to the host for boot. But maybe I'm just getting a bit carried away here. -- Daniel Reurich. Centurion Computer Technology (2005) Ltd Mobile 021 797 722 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1266547875.11568.1552.ca...@localhost.localdomain
Bug#450762: initramfs-tools: Unable to detect LVM on Raid for root partition.
Package: initramfs-tools Severity: important mdadm correctly assembles the raid1, but the vgchange -ay $vg fails to find the volume group. I did a little hack to /scripts/local-top/lvm2 that calls vgchange -ay again if it failed the first time succeeds in finding the volume group. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=en_NZ, LC_CTYPE=en_NZ (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
