Bug#567468: md homehost (was: Bug#567468: (boot time consequences of) Linux mdadm superblock) question.
On Tue, 23 Feb 2010 07:27:00 +0100 martin f krafft madd...@madduck.net wrote: also sprach Neil Brown ne...@suse.de [2010.02.23.0330 +0100]: The problem to protect against is any consequence of rearranging devices while the host is off, including attaching devices that previously were attached to a different computer. How often does this happen, and how grave/dangerous are the effects? a/ no idea. b/ it all depends... It is the sort of thing that happens when something has just gone drastically wrong and you need to stitch things back together again as quickly as you can. You aren't exactly panicing, but you are probably hasty and don't want anything else to go wrong. If the array from the 'other' machine with the same name has very different content, then things could go wrong in various different ways if we depended on that name. It is true that the admin would have to by physically present and could presumably get a console and 'fix' things. But it would be best if they didn't have too. They may not even know clearly what to do to 'fix' things - because it always worked perfectly before, but this time when in a particular hurry, something strange goes wrongs. I've been there, I don't want to inflict it on others. But if '/' is mounted by a name in /dev/md/, I want to be sure mdadm puts the correct array at that name no matter what other arrays might be visible. Of course it would be nice if this happened, but wouldn't it be acceptable to assume that if someone swaps drives between machines that they ought to know how to deal with the consequences, or at least be ready to tae additional steps to make sure the system still boots as desired? No. We cannot assume that an average sys-admin will have a deep knowledge of md and mdadm. Many do, many don't. But in either case the behaviour must be predictable. After all, Debian is for when you have better things to do than fixing systems Even if the wrong array appeared as /dev/md0 and was mounted as root device, is there any actual problem, other than inconvenience? Remember that the person who has previously swapped the drives is physically in front of (or behind ;)) the machine. I am unconvinced. I think we should definitely switch to using filesystem-UUIDs over device names, and that is the only real solution to the problem, no? What exactly are you unconvinced of? I agree completely that mounting filesystems by UUID is the right way to go. (I also happen to think that assembly md arrays by UUID is the right way to go too, but while people seem happy to put fs uuids in /etc/fstab, they seem less happy to put md uuids in /etc/mdadm.conf). As you say in another email: The only issue homehost protects against, I think, is machines that use /dev/md0 directly from grub.conf or fstab. That is exactly correct. If no code or config file depends on a name like /dev/mdX or /dev/md/foo, then you don't need to be concerned about the whole homehost thing. You can either mount by fs-uuid, or mount e.g. /dev/disk/by-id/md-uuid-8fd0af3f:4fbb94ea:12cc2127:f9855db5 NeilBrown -- 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/20100224111006.7024c...@notabene.brown
Bug#567468: md homehost (was: Bug#567468: (boot time consequences of) Linux mdadm superblock) question.
On Tue, Feb 23, 2010 at 4:10 PM, Neil Brown ne...@suse.de wrote: On Tue, 23 Feb 2010 07:27:00 +0100 martin f krafft madd...@madduck.net wrote: also sprach Neil Brown ne...@suse.de [2010.02.23.0330 +0100]: The problem to protect against is any consequence of rearranging devices while the host is off, including attaching devices that previously were attached to a different computer. How often does this happen, and how grave/dangerous are the effects? a/ no idea. b/ it all depends... It is the sort of thing that happens when something has just gone drastically wrong and you need to stitch things back together again as quickly as you can. You aren't exactly panicing, but you are probably hasty and don't want anything else to go wrong. If the array from the 'other' machine with the same name has very different content, then things could go wrong in various different ways if we depended on that name. It is true that the admin would have to by physically present and could presumably get a console and 'fix' things. But it would be best if they didn't have too. They may not even know clearly what to do to 'fix' things - because it always worked perfectly before, but this time when in a particular hurry, something strange goes wrongs. I've been there, I don't want to inflict it on others. But if '/' is mounted by a name in /dev/md/, I want to be sure mdadm puts the correct array at that name no matter what other arrays might be visible. Of course it would be nice if this happened, but wouldn't it be acceptable to assume that if someone swaps drives between machines that they ought to know how to deal with the consequences, or at least be ready to tae additional steps to make sure the system still boots as desired? No. We cannot assume that an average sys-admin will have a deep knowledge of md and mdadm. Many do, many don't. But in either case the behaviour must be predictable. After all, Debian is for when you have better things to do than fixing systems Even if the wrong array appeared as /dev/md0 and was mounted as root device, is there any actual problem, other than inconvenience? Remember that the person who has previously swapped the drives is physically in front of (or behind ;)) the machine. I am unconvinced. I think we should definitely switch to using filesystem-UUIDs over device names, and that is the only real solution to the problem, no? What exactly are you unconvinced of? I agree completely that mounting filesystems by UUID is the right way to go. (I also happen to think that assembly md arrays by UUID is the right way to go too, but while people seem happy to put fs uuids in /etc/fstab, they seem less happy to put md uuids in /etc/mdadm.conf). As you say in another email: The only issue homehost protects against, I think, is machines that use /dev/md0 directly from grub.conf or fstab. That is exactly correct. If no code or config file depends on a name like /dev/mdX or /dev/md/foo, then you don't need to be concerned about the whole homehost thing. You can either mount by fs-uuid, or mount e.g. /dev/disk/by-id/md-uuid-8fd0af3f:4fbb94ea:12cc2127:f9855db5 NeilBrown -- To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Would a permissible behavior be to add a third case: If an entry is not detected in the mdadm.conf file AND the homehost is not found to match ask on the standard console what to do with something like a 30 second timeout; as well as being noisy in the kernel log so the admin knows why it was slow. Really there should probably be two questions: 1) Do you want to run this? 2) What name do you want? (with the defaults being yes, and the currently chosen alternate name pattern). -- 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/4877c76c1002232012j55e77adcs16d958fa6e922...@mail.gmail.com
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
On Sun, Feb 21, 2010 at 11:06 PM, Goswin von Brederlow goswin-...@web.de wrote: martin f krafft madd...@madduck.net writes: 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. 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 -- To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to majord...@vger.kernel.org More majordomo info at http://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. -- 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/4877c76c1002212337i36f208dcyd1be7a93625d...@mail.gmail.com
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
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. If auto-assembly of all RAIDs bears dangers and must be regulated, then we must either have host-specific initramfs's, or be able to determine the homehost value early during boot otherwise. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
also sprach Michael Evans mjevans1...@gmail.com [2010.02.22.0837 +0100]: 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. Please see the thread for reasons why incremental assembly works only with an mdadm.conf file, or if you can uniquely identify the system before the root filesystem is mounted. Please see the thread for reasons why unconditional auto-assembly of all available arrays may not be desirable. 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. I fundamentally agree. However, driving this change from mdadm will be impossible. If that is the way to go, then we must first ensure that device names become deprecated, and that everyone uses /dev/disk/by-uuid/*. Only then can we start relying on it. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: md homehost (was: Bug#567468: (boot time consequences of) Linux mdadm superblock) question.
also sprach Piergiorgio Sartor piergiorgio.sar...@nexgo.de [2010.02.21.2113 +0100]: I do not see how the homehost plays a role, here. Neil, 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? Thanks, -- martin | http://madduck.net/ | http://two.sentenc.es/ fitter, healthier, more productive like a pig, in a cage, on antibiotics -- radiohead spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
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: md homehost (was: Bug#567468: (boot time consequences of) Linux mdadm superblock) question.
On Mon, 22 Feb 2010 10:16:32 +0100 martin f krafft madd...@madduck.net wrote: also sprach Piergiorgio Sartor piergiorgio.sar...@nexgo.de [2010.02.21.2113 +0100]: I do not see how the homehost plays a role, here. Neil, 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? The problem to protect against is any consequence of rearranging devices while the host is off, including attaching devices that previously were attached to a different computer. mdadm will currently assembly any array that it finds, but will not give a predictable name to anything that looks like it might be imported from a different host. So if you have 'md0' on each of two computers, one computer dies and you move the devices from that computer to the other, then as long as the bios boots of the right drive, mdadm will assemble the local array as 'md0' and the other array as 'something else'. There are two ways that mdadm determines than array is 'local'. 1/ is the uuid listed against an array in mdadm.conf 2/ is the 'homehost' encoded in the metadata. If either of those is true, the array is local and gets a predictable name. If neither, the name gets an _%d suffix. This is only an issue if you use device name (.e.g /dev/md0 or /dev/md/root) to mount the root filesystem. If you use mount-by-uuid then it clearly doesn't matter what name mdadm assembles the array under. In that case, the fs UUID (stored on the initramfs or similar) will assure the necessary uniqueness and mdadm need not worry about homehost. But if '/' is mounted by a name in /dev/md/, I want to be sure mdadm puts the correct array at that name no matter what other arrays might be visible. Does that clarify things enough? NeilBrown -- 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/20100223133028.279e0...@notabene.brown
Bug#567468: md homehost (was: Bug#567468: (boot time consequences of) Linux mdadm superblock) question.
also sprach Neil Brown ne...@suse.de [2010.02.23.0330 +0100]: The problem to protect against is any consequence of rearranging devices while the host is off, including attaching devices that previously were attached to a different computer. How often does this happen, and how grave/dangerous are the effects? But if '/' is mounted by a name in /dev/md/, I want to be sure mdadm puts the correct array at that name no matter what other arrays might be visible. Of course it would be nice if this happened, but wouldn't it be acceptable to assume that if someone swaps drives between machines that they ought to know how to deal with the consequences, or at least be ready to tae additional steps to make sure the system still boots as desired? Even if the wrong array appeared as /dev/md0 and was mounted as root device, is there any actual problem, other than inconvenience? Remember that the person who has previously swapped the drives is physically in front of (or behind ;)) the machine. I am unconvinced. I think we should definitely switch to using filesystem-UUIDs over device names, and that is the only real solution to the problem, no? -- martin | http://madduck.net/ | http://two.sentenc.es/ Escape Meta Alt Control Shift spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
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. 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. -- martin | http://madduck.net/ | http://two.sentenc.es/ arguments are extremely vulgar, for everyone in good society holds exactly the same opinion. -- oscar wilde spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
also sprach Piergiorgio Sartor piergiorgio.sar...@nexgo.de [2010.02.19.1016 +0100]: There is the kernel boot paramenter rd_NO_MDADMCONF, which forces dracut to do not use the mdadm.conf in the initramfs image. My impression is that it uses the mdadm -I functionality. Indeed, it does. However, I could not find out how it does device naming? From what I understand, mdadm will only assemble devices using the name stored in the superblocks iff the homehost matches, so dracut either doesn't provide for this and requires the use of UUIDs to mount filesystems (making the array name secondary), or it needs to know what the homehost is. For this, it either needs mdadm.conf, or the hostname must be stored in the initramfs. Could you research this and let us know how dracut invokes mdadm? -- martin | http://madduck.net/ | http://two.sentenc.es/ licht wird alles, was ich fasse - friedrich nietzsche spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
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. 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. -- martin | http://madduck.net/ | http://two.sentenc.es/ truth is stranger than fiction, but it is because fiction is obliged to stick to possibilities; truth isnt. -- mark twain spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
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.
Hi, Indeed, it does. However, I could not find out how it does device naming? From what I understand, mdadm will only assemble devices using the name stored in the superblocks iff the homehost matches, so dracut either doesn't provide for this and requires the use of UUIDs to mount filesystems (making the array name secondary), or it needs to know what the homehost is. For this, it either needs mdadm.conf, or the hostname must be stored in the initramfs. uhm, I guess it just assemble the array, then the /etc/fstab will take care to mount the proper bits, using, for example, the LABEL mechanism. My setup has LVM over RAID, so first the array is put together, then LVM looks for its own things, then the volumes are mounted. It seems mdadm can scan assemby, so can LVM. In the end there are LVM volumes, which have a well defined name. I do not see how the homehost plays a role, here. Could you research this and let us know how dracut invokes mdadm? Well, thanks that you asked, I can have a look, but, as usual, I cannot promise anything. bye, -- piergiorgio -- 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/20100221201304.gb2...@lazy.lzy
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
martin f krafft madd...@madduck.net writes: 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. 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 -- 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/873a0t4ume@frosties.localdomain
Bug#567468: (boot time consequences of) Linux mdadm superblock question.
Hi, 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. it seems that, with dracut, mdadm.conf is optional. There is the kernel boot paramenter rd_NO_MDADMCONF, which forces dracut to do not use the mdadm.conf in the initramfs image. This seems to work also if / is on mdX. I just tried it, and it was running fine. I did not check the details, i.e. I've no proof dracut was not cheating. My impression is that it uses the mdadm -I functionality. There are other interesting kernel boot options, like: rd_MD_UUID=md uuid bye, -- piergiorgio -- 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/20100219091619.ga2...@lazy.lzy
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#567468: (boot time consequences of) Linux mdadm superblock question.
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. -- martin | http://madduck.net/ | http://two.sentenc.es/ stupidity management for the superuser is a user space issue in unix systems. -- alan cox spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
