Bug#570516: md UUID changed
On 19.08.2012 21:13, Ivo De Decker wrote: Hi, On Mon, Feb 21, 2011 at 11:59:25AM +, Steve McIntyre wrote: The hostname didn’t change. However the latter might be possible, I don’t really know. The MD array was built from lenny’s d-i. I've just started to upgrade my main fileserver at home from Lenny to Squeeze, and I think I've been bitten by this bug (or something very similar) in a big way. I've started off with a system running a locally-built 2.6.28 kernel and a number of RAID devices, all configured with version 0.9 superblocks (the default in Lenny, AFAICT). It seems both the reports for this bug are for upgrades from lenny to squeeze. Is this bug still relevant for wheezy? Does this problem still happen? If the problem is related to an upgrade from lenny, the bug should be marked as fixed in mdadm 3.2.2-1, as we don't support upgrades from lenny to something post-squeeze. Since no one had any idea where it come from to start with, and whenever this is related to upgrading or not, no one still have an idea what to do with it... :) /mjt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570516: md UUID changed
On Sun, Aug 19, 2012 at 07:13:33PM +0200, Ivo De Decker wrote: Hi, On Mon, Feb 21, 2011 at 11:59:25AM +, Steve McIntyre wrote: The hostname didn’t change. However the latter might be possible, I don’t really know. The MD array was built from lenny’s d-i. I've just started to upgrade my main fileserver at home from Lenny to Squeeze, and I think I've been bitten by this bug (or something very similar) in a big way. I've started off with a system running a locally-built 2.6.28 kernel and a number of RAID devices, all configured with version 0.9 superblocks (the default in Lenny, AFAICT). It seems both the reports for this bug are for upgrades from lenny to squeeze. Is this bug still relevant for wheezy? Does this problem still happen? If the problem is related to an upgrade from lenny, the bug should be marked as fixed in mdadm 3.2.2-1, as we don't support upgrades from lenny to something post-squeeze. As Michael says, we have no idea what causes the bug. Please don't close it just because it's old. -- Steve McIntyre, Cambridge, UK.st...@einval.com Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs. -- Matt Mackall -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570516: md UUID changed
Hi, On Mon, Feb 21, 2011 at 11:59:25AM +, Steve McIntyre wrote: The hostname didn’t change. However the latter might be possible, I don’t really know. The MD array was built from lenny’s d-i. I've just started to upgrade my main fileserver at home from Lenny to Squeeze, and I think I've been bitten by this bug (or something very similar) in a big way. I've started off with a system running a locally-built 2.6.28 kernel and a number of RAID devices, all configured with version 0.9 superblocks (the default in Lenny, AFAICT). It seems both the reports for this bug are for upgrades from lenny to squeeze. Is this bug still relevant for wheezy? Does this problem still happen? If the problem is related to an upgrade from lenny, the bug should be marked as fixed in mdadm 3.2.2-1, as we don't support upgrades from lenny to something post-squeeze. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#570516: md UUID changed
Processing commands for cont...@bugs.debian.org: severity 570516 grave Bug #570516 [mdadm] mdadm: UUID changed upon upgrade Severity set to 'grave' from 'normal' thanks Stopping processing here. Please contact me if you need assistance. -- 570516: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570516 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570516: md UUID changed
severity 570516 grave thanks On Thu, May 27, 2010 at 07:42:29AM +0200, Josselin Mouette wrote: Le mercredi 26 mai 2010 à 18:25 +1000, Neil Brown a écrit : also sprach Neil Brown ne...@suse.de [2010.05.26.1004 +0200]: It looks like mdadm -A --update=homehost or --auto-update-homehost was used. With v0.90 metadata, the homehost is recorded by storing a hash of it in the uuid (as there is no-where else to store something like that). So arrays on the same homehost will have the same second-half of the uuid. Even if the hostname didn't change? Only if the hostname changed, or the hostname had not previously been encoded in the uuid. The hostname didn’t change. However the latter might be possible, I don’t really know. The MD array was built from lenny’s d-i. I've just started to upgrade my main fileserver at home from Lenny to Squeeze, and I think I've been bitten by this bug (or something very similar) in a big way. I've started off with a system running a locally-built 2.6.28 kernel and a number of RAID devices, all configured with version 0.9 superblocks (the default in Lenny, AFAICT). Using my 2.6.28 kernel and mdadm version 2.6.7.2-3, things work fine. I've installed only the squeeze kernel (2.6.32) and rebooted with that, to make sure that it boots. Unfortunately, it doesn't. I see a lot of messages from the RAID assembly step, complaining that various of the RAID0 devices are missing components. Hmmm, OK. So let's go back to the old kernel and re-check. However, now when I use the 2.6.28 system I get similar problems. Previously-working devices are now not working. I'm seeing complaints all over the place that homehost definitions don't match when trying to assemble devices. *I* did not change anything here, so it suggests that something (the kernel RAID layer? mdadm init scripts in the initramfs?) has modified my superblocks in a broken way and stopped my system booting. Since then, I've tried to force update of the homehost/uuid settings in the superblocks, but to no avail. Then I saw that I was on the old superblock version that didn't store the homehost itself. I've only managed to get things up and running by actually recreating the RAID1 devices by hand, using the same settings as the previous devices. Scary stuff... :-( Yet if I reboot into the new kernel again, things fall apart again. Even on a newly-created v1.2 device. Help! -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570516: md UUID changed
also sprach Steve McIntyre st...@einval.com [2011.02.21.1259 +0100]: However, now when I use the 2.6.28 system I get similar problems. Previously-working devices are now not working. I'm seeing complaints all over the place that homehost definitions don't match when trying to assemble devices. *I* did not change anything here, so it suggests that something (the kernel RAID layer? mdadm init scripts in the initramfs?) has modified my superblocks in a broken way and stopped my system booting. As the bug report (and Neil) says, this could be related to homehost, but I cannot quite figure out how this would happen. It is true that mdadm on Debian was using --auto-update-homehost up until 3.0-1, because IIRC that was the only way to provide a migration path from before-homehost to then. Why the UUID would now change is complete outside of my knowledge and imagination. I have never seen this problem. Since then, I've tried to force update of the homehost/uuid settings in the superblocks, but to no avail. Then I saw that I was on the old superblock version that didn't store the homehost itself. They do store them, but as part of the UUID. However, without --auto-update-homehost, I do not see a way in which the UUID should be updated. I've only managed to get things up and running by actually recreating the RAID1 devices by hand, using the same settings as the previous devices. Scary stuff... :-( Yet if I reboot into the new kernel again, things fall apart again. Even on a newly-created v1.2 device. Try this instead: In initramfs, remove the /etc/mdadm/mdadm.conf file and replace it with a scan: mdadm -Escpartitions /etc/mdadm/mdadm.conf then -A (assemble) your arrays, either individually or with -Asayes. Then boot your system. Once the system is up, compare the output of /usr/share/mdadm/mkconf with the contents of /etc/mdadm/mdadm.conf and update the file with the data from the command output. When done, run update-initramfs -u and now the system should boot. This bug has been puzzling me all along, which is why I have not been able to fix it. I am sorry it caused you grief. -- .''`. martin f. krafft madduck@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/sig-policy/999bbcc4/current)
Bug#570516: md UUID changed
On Mon, Feb 21, 2011 at 03:12:43PM +0100, Martin Krafft wrote: also sprach Steve McIntyre st...@einval.com [2011.02.21.1259 +0100]: However, now when I use the 2.6.28 system I get similar problems. Previously-working devices are now not working. I'm seeing complaints all over the place that homehost definitions don't match when trying to assemble devices. *I* did not change anything here, so it suggests that something (the kernel RAID layer? mdadm init scripts in the initramfs?) has modified my superblocks in a broken way and stopped my system booting. As the bug report (and Neil) says, this could be related to homehost, but I cannot quite figure out how this would happen. It is true that mdadm on Debian was using --auto-update-homehost up until 3.0-1, because IIRC that was the only way to provide a migration path from before-homehost to then. Why the UUID would now change is complete outside of my knowledge and imagination. I have never seen this problem. I'm surprised too - I've never seen anything like this before either, and I've been using md for many years on this and other systems. Since then, I've tried to force update of the homehost/uuid settings in the superblocks, but to no avail. Then I saw that I was on the old superblock version that didn't store the homehost itself. They do store them, but as part of the UUID. However, without --auto-update-homehost, I do not see a way in which the UUID should be updated. I've only managed to get things up and running by actually recreating the RAID1 devices by hand, using the same settings as the previous devices. Scary stuff... :-( Yet if I reboot into the new kernel again, things fall apart again. Even on a newly-created v1.2 device. Try this instead: In initramfs, remove the /etc/mdadm/mdadm.conf file and replace it with a scan: mdadm -Escpartitions /etc/mdadm/mdadm.conf then -A (assemble) your arrays, either individually or with -Asayes. Then boot your system. Once the system is up, compare the output of /usr/share/mdadm/mkconf with the contents of /etc/mdadm/mdadm.conf and update the file with the data from the command output. When done, run update-initramfs -u and now the system should boot. Hmmm, OK. I'll try that tonight when I'm in front of the system again. This bug has been puzzling me all along, which is why I have not been able to fix it. I am sorry it caused you grief. Ack. If I can help debug in any way, just let me know. -- Steve McIntyre, Cambridge, UK.st...@einval.com I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell. -- Linus Torvalds -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570516: md UUID changed
also sprach Steve McIntyre st...@einval.com [2011.02.21.1542 +0100]: This bug has been puzzling me all along, which is why I have not been able to fix it. I am sorry it caused you grief. Ack. If I can help debug in any way, just let me know. Reproducing it in a controlled way would be the best. My attempts under KVM so far have not been successful. -- .''`. martin f. krafft madduck@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/sig-policy/999bbcc4/current)
