https://bugzilla.novell.com/show_bug.cgi?id=798275 https://bugzilla.novell.com/show_bug.cgi?id=798275#c2 --- Comment #2 from Jan Engelhardt <jengelh@inai.de> 2013-01-13 02:35:59 CET --- Created an attachment (id=520037) --> (http://bugzilla.novell.com/attachment.cgi?id=520037) screenshot -- 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=798275 https://bugzilla.novell.com/show_bug.cgi?id=798275#c4 Jan Engelhardt <jengelh@inai.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #520036|0 |1 is obsolete| | --- Comment #4 from Jan Engelhardt <jengelh@inai.de> 2013-02-16 13:00:50 CET --- Created an attachment (id=524986) --> (http://bugzilla.novell.com/attachment.cgi?id=524986) /var/log/YaST Steps to reproduce: 1. Using the rescue system or some preexisting system, create a RAID1 spanning /dev/sda1 and /dev/sdb1, preferably with 1.0 superblock. 2. Stop the newly-created array and zero out /dev/sda. 3. Start the installation DVD. Once the shell becomes available on tty2, cat /proc/mdstat shows: Personalities : raid 0, 1, 6, 5, 4, 10, multipath md127 : inactive sdb1[1](S) 2095092 blocks super 1.0 unused devices: <none> 4. yasts partitioner shows that (a) sda has no partitions, (b) sdb has sdb1 of type 0xFD RAID, (c) md127 is not shown anywhere 5. Delete sdb1. 6. Create partition sdb1, with ext4 for the "/" mountpoint. 7. Once actual installation begins, mkfs fails. -- 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=798275 https://bugzilla.novell.com/show_bug.cgi?id=798275#c Jiří Suchomel <jsuchome@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aschnell@suse.com AssignedTo|yast2-maintainers@suse.de |fehr@suse.com -- 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=798275 https://bugzilla.novell.com/show_bug.cgi?id=798275#c6 Neil Brown <nfbrown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|nfbrown@suse.com | --- Comment #6 from Neil Brown <nfbrown@suse.com> 2013-02-26 01:45:05 UTC --- I'm not sure if it was intention of accident, but it has always been that way, at least as long has it has been possible to mark devices as busy (2.6.0 I think). So I think the fact that it hasn't been reported before it just "luck". Presumably the array was left in this inactive state by mdadm, but that doesn't surprise me. It will normally only do that when you are assembling an array by hand: mdadm -A /dev/md0 /dev/sda1 for example. Normally the boot process does something like: mdadm -As which, I think, doesn't leave 'inactive' arrays. Do you know what would have started the array in this case? -- 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=798275 https://bugzilla.novell.com/show_bug.cgi?id=798275#c8 Jan Engelhardt <jengelh@inai.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fcrozat@suse.com --- Comment #8 from Jan Engelhardt <jengelh@inai.de> 2013-02-26 18:13:46 CET ---

I would suspect some udev magic

Damn right! In 12.3 (normal system, not the installer), I noticed that md components imported via iscsiadm suddenly were md-assembled as well. _That_ was annoying, especially if it's shared storage that one is not supposed to activate on more than one machine. Putting the blame on systemd/udev. Please pass it along :) -- 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=798275 https://bugzilla.novell.com/show_bug.cgi?id=798275#c10 --- Comment #10 from Robert Milasan <rmilasan@suse.com> 2013-02-26 19:22:31 UTC --- The number of the raid is based on the number of the minor of the raid device, so if kernel event says that the raid has minor 127 then the device is md127. I think this usually happens when creating a raid device in this way: # mdadm --create /dev/md/raid1 -e 1.2 --raid-devices=2 -l 1 /dev/sdb1 /dev/sdc1 # cat /sys/block/md127/uevent MAJOR=9 MINOR=127 DEVNAME=md127 DEVTYPE=disk but when creating the raid like this: # mdadm --create /dev/md0 -e 1.2 --raid-devices=2 -l 1 /dev/sdb1 /dev/sdc1 # /sys/block/md0/uevent MAJOR=9 MINOR=0 DEVNAME=md0 DEVTYPE=disk The actual minor will be 0 like we just named it, or at least this is what I believe it happens, but from the udev point of you, I can't really do anything. -- 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=798275 https://bugzilla.novell.com/show_bug.cgi?id=798275#c12 Neil Brown <nfbrown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|nfbrown@suse.com | --- Comment #12 from Neil Brown <nfbrown@suse.com> 2013-02-26 23:24:17 UTC --- Yes, autoassembly from udev running "mdadm -I" - of course. Though I understand your "bad feeling", I think this is really what we want long-term, so we need to be able to deal with it. Back to the original problem: mkfs fails. At that point, or possibly earlier, the installer should detect that the device is busy and do something about it. Detecting that it is busy is easy: open(O_EXCL). Finding out why is a little harder, but not by much. When md has grabbed the device, /sys/block/$DEVNAME/holders will contain an entry 'md*' - 'md127' in this case. If you just know the major/minor numbers, you can get this via /sys/dev/block/$major:$minor/holders/* So you could just find that and tell 'mdadm' to '--stop' the array. But you probably want to report the array as owning the device in the first place. How does the install currently enumerate md arrays? Presumably we can enhance whatever mechanism it uses to enumerate the inactive arrays too. I'd be happy to modify "mdadm" to report something more useful for inactive arrays if that is what the installer uses. -- 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=798275 https://bugzilla.novell.com/show_bug.cgi?id=798275#c14 Neil Brown <nfbrown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|nfbrown@suse.com | --- Comment #14 from Neil Brown <nfbrown@suse.com> 2013-02-27 09:40:20 UTC --- Hi Robert, I can't see how that is relevant to the current problem. It doesn't really matter which number is used. The issue (I thought) is that an array is keeping the device busy. numbers like 0 and 1 and 2 are often explicitly assigned to array, so if we find some devices which don't have a number assigned we shouldn't use some low number, as that might conflict with some later devices that we might find. So we choose a number that is likely to not be the explicit name for an array. We start at 127 and count down. -- 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=798275 https://bugzilla.novell.com/show_bug.cgi?id=798275#c16 --- Comment #16 from Thomas Fehr <fehr@suse.com> 2013-02-27 12:11:11 UTC --- The problem with the busy raid set aside (we certainly can fix that, now that we know about the different behavior). So far I could not really believe that the behavior is really intentional and assumed the behavior is a bug or an unwanted side effect. But so be it. Just some more remarks about the reason I consider the new behavior suboptimal: 1) most users will be confused if their raid that was named /dev/md0 for ages is now named /dev/md127 2) all updates that have former names (/dev/md0, /dev/md1) in fstab will of course fail 3) if you attach a disk containing raid signatures (maybe temporarily), to a system (e.g. by iscsi, usb), most people will be surprised to find automatically (active or inactive) raid devices in the system 4) if you detach the disk again, you have raid device in /proc/partition and /proc/mdstat that use block device that do not exist any more in /proc/partitions To illustrate the point 3) and 4) I did some quick tests on my 12.3 RC2 test install: # first all is pretty standard f134:~ # tail /proc/partitions 8 35 6139898 sdc3 8 48 6291456 sdd 8 49 49976 sdd1 8 50 99800 sdd2 8 51 6139898 sdd3 8 64 6291456 sde 8 65 49976 sde1 8 66 99800 sde2 8 67 6139898 sde3 11 0 4420608 sr0 f134:~ # cat /proc/mdstat Personalities : [raid10] [raid1] [raid0] unused devices: <none> # now I attach a disk with raids via iscsi f134:~ # iscsiadm .... -login f134:~ # tail /proc/partitions 8 67 6139898 sde3 11 0 4420608 sr0 8 80 1048576 sdf 8 81 290816 sdf1 8 82 755712 sdf2 8 96 1048576 sdg 8 97 290816 sdg1 8 98 755712 sdg2 9 127 290496 md127 9 126 1510400 md126 f134:~ # cat /proc/mdstat Personalities : [raid10] [raid1] [raid0] md126 : active raid0 sdg2[1] sdf2[0] 1510400 blocks super 1.2 512k chunks md127 : active (auto-read-only) raid1 sdg1[1] sdf1[0] 290496 blocks super 1.2 [2/2] [UU] unused devices: <none> # so now I have unknowingly two active raid devices on my system # now I unattach the iscsi disks again f134:~ # iscsiadm .... --logout f134:~ # tail /proc/partitions 8 49 49976 sdd1 8 50 99800 sdd2 8 51 6139898 sdd3 8 64 6291456 sde 8 65 49976 sde1 8 66 99800 sde2 8 67 6139898 sde3 11 0 4420608 sr0 9 127 290496 md127 9 126 1510400 md126 f134:~ # cat /proc/mdstat Personalities : [raid10] [raid1] [raid0] md126 : active raid0 sdg2[1] sdf2[0] 1510400 blocks super 1.2 512k chunks md127 : active (auto-read-only) raid1 sdg1[1] sdf1[0](F) 290496 blocks super 1.2 [2/1] [_U] unused devices: <none> # so disks are gone but raid devices are still there # and even claim to be active # the disks sdf and sdg seem not to be really gone since if I attach the # same iscsi disk again it gets sdh and sdi as block device f134:~ # iscsiadm .... -login f134:~ # tail /proc/partitions 8 67 6139898 sde3 11 0 4420608 sr0 9 127 290496 md127 9 126 1510400 md126 8 112 1048576 sdh 8 113 290816 sdh1 8 114 755712 sdh2 8 128 1048576 sdi 8 129 290816 sdi1 8 130 755712 sdi2 f134:~ # cat /proc/mdstat Personalities : [raid10] [raid1] [raid0] md126 : active raid0 sdg2[1] sdf2[0] 1510400 blocks super 1.2 512k chunks md127 : active (auto-read-only) raid1 sdg1[1] sdf1[0](F) 290496 blocks super 1.2 [2/1] [_U] unused devices: <none> f134:~ # So for me all these effects create additional confusion for not too much gain. -- 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=798275 https://bugzilla.novell.com/show_bug.cgi?id=798275#c17 --- Comment #17 from Neil Brown <nfbrown@suse.com> 2013-02-27 22:58:56 UTC --- (In reply to comment #16)

Just some more remarks about the reason I consider the new behavior suboptimal: 1) most users will be confused if their raid that was named /dev/md0 for ages is now named /dev/md127

That should not happen. If it was created as "/dev/md0", then the name "0" will be stored in the metadata and so "/dev/md0" will be used when the device is discovered and an array is assembled. However if you plug the device into a different host, then that host might have its own "/dev/md0" array, so mdadm will give this new one a different name. At install time, the computer "looks" like a new different machine because the hostname is different so it will tend to use "/dev/md127" devices. If the install image has HOSTHOST <ignore> in mdadm.conf, then the mdadm will think all devices found belong to "this" host and will use the most appropriate name.

2) all updates that have former names (/dev/md0, /dev/md1) in fstab will of course fail

See 1) above.

3) if you attach a disk containing raid signatures (maybe temporarily), to a system (e.g. by iscsi, usb), most people will be surprised to find automatically (active or inactive) raid devices in the system

No more than they might be surprised when the plug in a USB device to find that the filesystem on it has been mounted and a window pops up showing the contents of that filesystem.

4) if you detach the disk again, you have raid device in /proc/partition and /proc/mdstat that use block device that do not exist any more in /proc/partitions

That would be a bug. The udev rules file contains: ACTION=="remove", ENV{ID_PATH}=="?*", RUN+="/sbin/mdadm -If $name --path $env{ID_PATH}" ACTION=="remove", ENV{ID_PATH}!="?*", RUN+="/sbin/mdadm -If $name" so that when a device is removed, "mdadm -If $device" is called, which should remove it from any active array. I guess removing the last device will not actually shutdown the array - it should but doesn't yet.

f134:~ # cat /proc/mdstat Personalities : [raid10] [raid1] [raid0] md126 : active raid0 sdg2[1] sdf2[0] 1510400 blocks super 1.2 512k chunks

md127 : active (auto-read-only) raid1 sdg1[1] sdf1[0] 290496 blocks super 1.2 [2/2] [UU]

unused devices: <none> # so now I have unknowingly two active raid devices on my system

Exactly as expected. Note that the RAID1 array is "auto-read-only" so no resync/recovery will start until something actually writes to the device. So this is not really different from automatically mounting the filesystem.

# now I unattach the iscsi disks again f134:~ # iscsiadm .... --logout f134:~ # tail /proc/partitions 8 49 49976 sdd1 8 50 99800 sdd2 8 51 6139898 sdd3 8 64 6291456 sde 8 65 49976 sde1 8 66 99800 sde2 8 67 6139898 sde3 11 0 4420608 sr0 9 127 290496 md127 9 126 1510400 md126 f134:~ # cat /proc/mdstat Personalities : [raid10] [raid1] [raid0] md126 : active raid0 sdg2[1] sdf2[0] 1510400 blocks super 1.2 512k chunks

md127 : active (auto-read-only) raid1 sdg1[1] sdf1[0](F) 290496 blocks super 1.2 [2/1] [_U]

unused devices: <none> # so disks are gone but raid devices are still there # and even claim to be active

This is not intended, so it's a bug. Thanks for reporting it! 'sdf1' should have been removed from the array - I think I know what it wasn't. The "raid0" situation should involve simply stopping the array. That should be easy enough to manage. I wonder how I can signal udisks to unmount the device if it has been mounted ... I'll have to look into that. -- 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=798275 https://bugzilla.novell.com/show_bug.cgi?id=798275#c19 --- Comment #19 from Bernhard Wiedemann <bwiedemann@suse.com> 2013-02-28 17:00:18 CET --- This is an autogenerated message for OBS integration: This bug (798275) was mentioned in https://build.opensuse.org/request/show/156846 Factory / libstorage -- 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=798275 https://bugzilla.novell.com/show_bug.cgi?id=798275#c21 --- Comment #21 from Jan Engelhardt <jengelh@inai.de> 2013-03-01 12:50:14 CET --- Neil, can we have something in mdadm(8) to show partially-assembled arrays as well? I think it is inconsistent to have them in /proc/mdstat when `mdadm -D /dev/mdN` says the array is not there. -- 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=798275 https://bugzilla.novell.com/show_bug.cgi?id=798275#c24 Thomas Fehr <fehr@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #24 from Thomas Fehr <fehr@suse.com> 2013-04-29 09:20:32 UTC --- The backport for this fix is already in SLES11 SP3 code base. So we should be fine there and in 12.3 and Factory. -- 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.