https://bugzilla.novell.com/show_bug.cgi?id=288454#c1 --- Comment #1 from carbonneaux mathieu 2007-06-29 07:26:44 MST --- Created an attachment (id=148938) --> (https://bugzilla.novell.com/attachment.cgi?id=148938) backup of downvg meta -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=288454#c3 --- Comment #3 from carbonneaux mathieu 2007-06-29 10:24:04 MST --- i found why my /dev/sdc are corrupted at boot... is in /etc/init.d/boot.md script... they try to reconstruct an old md device... on the /dev/sdc... the probleme is in /sbin/mdrun that is executed if mdadm fail and or /etc/mdadm.conf not exist or be zero... on 10.0 this probleme not apear... and i've no 10.0 to compare how it do the jobs in the past... the probleme is that the /dev/sdc have been used in md device in the past and have reused without md device in lvm... but mdadm -E detect old superblock... #mdadm -E /dev/sdc /dev/sdc: Magic : a92b4efc Version : 00.90.00 UUID : d73bd14b:b24d3823:b7c1dbb9:0f728c3f Creation Time : Sun Jul 25 15:16:56 2004 Raid Level : raid5 Device Size : 244198464 (232.89 GiB 250.06 GB) Array Size : 732595392 (698.66 GiB 750.18 GB) Raid Devices : 4 Total Devices : 3 Preferred Minor : 0 Update Time : Sun Aug 29 01:09:39 2004 State : clean Active Devices : 3 Working Devices : 3 Failed Devices : 0 Spare Devices : 0 Checksum : 8bc15bc2 - correct Events : 0.6301 Layout : left-symmetric Chunk Size : 32K Number Major Minor RaidDevice State this 2 8 32 2 active sync /dev/sdc 0 0 8 16 0 active sync /dev/sdb 1 1 8 0 1 active sync /dev/sda 2 2 8 32 2 active sync /dev/sdc 3 3 0 0 3 faulty removed is why they try to reconstruct md device from old superblock... i'm not sure is good way to auto-reconstruct md without human intervention... without prompt... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=288454#c4 Thomas Fehr changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fehr@novell.com AssignedTo|fehr@novell.com |mmarek@novell.com --- Comment #4 from Thomas Fehr 2007-07-02 05:14:07 MST --- Thanks for investigating this problem so thouroughly. Since I am not the maintainer of mdadm (where /etc/init.d/boot.md belongs to) I will reassign this bug to maintainer of mdadm package so that this could be investigated properly. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=288454#c5 --- Comment #5 from Michal Marek 2007-07-03 05:38:08 MST --- Hmm, can this be avoided? The md superblock is near the end of the device, in this case it obviously survived the change... BTW 10.0 called raidautorun as a fallback, I wonder why this problem didn't occur there as well... I'll have to look closer. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=288454#c7 --- Comment #7 from Michal Marek 2007-07-26 04:11:21 MST --- Created an attachment (id=153203) --> (https://bugzilla.novell.com/attachment.cgi?id=153203) boot.md This boot.md should only look for partitions (and not require any helpers like mdrun or raidautorun). Also if you 'touch /etc/mdadm.conf', it will skip assembling the arrays completely. So in the rescue system, it will try to autoassemble partitions that have an md superblock. It will also do that in the installed system if /etc/mdadm.conf doesn't exist. Otherwise it will respect the config. This is unfortunately no bugfix, just a hope that a less automatic array assembly will cause less problems... BTW, Neil, your input would be appreciated :-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=288454#c8 Neil Brown changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|nfbrown@novell.com | --- Comment #8 from Neil Brown 2007-07-26 19:35:55 MST --- Awkward. I must admit that I am not a fan of auto-assembly at all. It is just to hard to assemble the wanted arrays, but not the unwanted one. I always recommend having an mdadm.conf that actually has what you want listed. But if some people depend on auto-assembly, I guess we need to keep supporting it. Recent mdadm has a 'homehost' concept and can be told to only auto-assemble array that were created for 'this' host. However I don't think that would actually help in this case. If "mdadm --zero-superblock /dev/sdc" got run before a device was used for something else that would help, but forcing that to happen would be hard. mdadm always removes old md superblocks before reusing a device, but it doesn't remove old dm metadata, and nor does dm remove old md metadata. I think there are no really easy solutions, and that the best way forward in general is to deprecate auto-assembly. For this specific situation, "mdadm --zero-superblock /dev/sdc" should get you out of trouble. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=288454#c10 Michal Marek changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Blocker |Normal Summary|lv lost when update opensuse|boot.md auto-assembly can cause problems |from 10.0 to 10.2... | --- Comment #10 from Michal Marek 2007-07-27 07:44:35 MST --- I submitted the above script to factory. As there's still room for improvement (eg. dropping auto-assembly completely ;)), I'll leave this bug open with lowel severity. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=288454#c12 --- Comment #12 from Michal Marek 2007-07-27 08:03:26 MST --- But this is done by yast2-storage (which calls raidautorun, which is even more careful by only looking at 'linux raid' partitions), not by boot.md, right? And we probably shouldn't drop auto-assembly in the rescue system either (done by boot.md). But in the installed system, it seems less useful. But I don't feel like dropping it completely in installed system now before Beta1, because chances are that another Blocker would appear that the arrays are suddenly no longer (auto-)assembled and so on. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=288454#c14 --- Comment #14 from carbonneaux mathieu 2007-07-28 04:42:20 MST --- i think auto assemble must be a rescue operation only and must be driven interactively not automaticly... like in yast2-storage menu for exemple... and i think that only raid defined device must be auto assembled at boot ... and only if no mbadm.conf exist... but is think.. Best Regards, Mathieu -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=288454 Michal Marek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |suse-beta@cboltz.de Component|Update Problems |Basesystem Product|openSUSE 10.2 |openSUSE 11.0 Version|Final |unspecified -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.