https://bugzilla.novell.com/show_bug.cgi?id=743717 https://bugzilla.novell.com/show_bug.cgi?id=743717#c1 --- Comment #1 from Jiri Stavinoha 2012-01-29 23:48:53 UTC --- After further testing I have to say changing the md paths correct nothing. Sorry but it is not easy to verify because system is able to boot for 10 times in series and then 4x fail... However I have tried to upgrade to factory systemd and installed systemd-39-1.1.x86_64.rpm with libcryptsetup4-1.4.1-2.1.x86_64.rpm dependency (12.1 uses libcryptsetup1) and after more than 20 boots I did not meet this problem again so I believe it is fixed. Btw: when booting with this factory systemd then as soon as boot is complete, system is not clearing the boot output and switching to console immediately but is waiting about 30s (may be it is for debugging but maybe there is some kind of time out so something went wrong anyway - however all md arrays are fine). -- 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=743717 https://bugzilla.novell.com/show_bug.cgi?id=743717#c2 --- Comment #2 from Frederic Crozat 2012-01-30 15:35:41 UTC --- which systemd was tested on 12.1 ? please make sure to use 12.1 maintenance update for systemd, or even better, package from home:fcrozat:systemd / systemd, it contains additional fixes. -- 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=743717 https://bugzilla.novell.com/show_bug.cgi?id=743717#c4 --- Comment #4 from Frederic Crozat 2012-01-31 14:48:58 UTC --- could you try booting with systemd.log_level=debug systemd.log_target=kmsg and attach dmesg output when it is failing ? I'm not sure it is a systemd or a udev bug (or an udev bug in mkinitrd..) -- 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=743717 https://bugzilla.novell.com/show_bug.cgi?id=743717#c6 --- Comment #6 from Jiri Stavinoha 2012-01-31 19:05:22 UTC --- Created an attachment (id=473591) --> (http://bugzilla.novell.com/attachment.cgi?id=473591) systemd 37-3.6.1 dmesg output dmesg with systemd-37-3.6.1.x86_64.rpm package. -- 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=743717 https://bugzilla.novell.com/show_bug.cgi?id=743717#c8 --- Comment #8 from Jiri Stavinoha 2012-02-01 21:46:33 UTC --- it is clean 12.1 system with latest 12.1 updates and only systemd and systemd-sysvinit v39 packages from factory. The only difference is 3.1.9 kernel from OBS but, and this is important, this problem still persists with kernel 3.1.0 from pure 12.1. I already tried ome:fcrozat:systemd/systemd but no difference. cat /proc/mdstat Personalities : [raid1] [raid0] [raid10] [raid6] [raid5] [raid4] md1 : active raid1 sda6[0] sdb6[1] 104376 blocks super 1.0 [2/2] [UU] bitmap: 0/7 pages [0KB], 8KB chunk md3 : active raid1 sda8[0] sdb8[1] 278807904 blocks super 1.0 [2/2] [UU] bitmap: 10/266 pages [40KB], 512KB chunk md2 : active raid1 sdb7[1] sda7[0] 31463196 blocks super 1.0 [2/2] [UU] bitmap: 1/241 pages [4KB], 64KB chunk fdisk -l /dev/sda <= same applies to /dev/sdb Disk /dev/sda: 500.1 GB, 500106780160 bytes 255 heads, 63 sectors/track, 60801 cylinders, total 976771055 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x634843be Device Boot Start End Blocks Id System /dev/sda1 * 2048 104859647 52428800 7 HPFS/NTFS/exFAT /dev/sda2 104872320 734025914 314576797+ 5 Extended /dev/sda3 734025915 976768064 121371075 7 HPFS/NTFS/exFAT /dev/sda5 104872383 113274314 4200966 82 Linux swap / Solaris /dev/sda6 113274378 113483159 104391 fd Linux raid autodetect /dev/sda7 113483223 176409764 31463271 fd Linux raid autodetect /dev/sda8 176409828 734025914 278808043+ fd Linux raid autodetect Personally I believe it works fine due to different libcryptsetup package (there are no crypted fs but may be it does not matter). -- 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=743717 https://bugzilla.novell.com/show_bug.cgi?id=743717#c10 Frederic Crozat changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nfbrown@suse.com --- Comment #10 from Frederic Crozat 2012-02-03 14:00:01 UTC --- interesting too would be output of systemctl status md.service and check /var/log/messages for md errors. -- 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=743717 https://bugzilla.novell.com/show_bug.cgi?id=743717#c12 --- Comment #12 from Frederic Crozat 2012-02-07 10:38:18 UTC --- I still can't reproduce your issue. and from systemd log output, it looks like md.service (ie /etc/init.d/boot.md ) is outputting an error because /dev/md3 is already used. Not sure it is systemd related. -- 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=743717 https://bugzilla.novell.com/show_bug.cgi?id=743717#c14 --- Comment #14 from Steve Revilak 2012-02-22 04:48:07 UTC --- Created an attachment (id=477198) --> (http://bugzilla.novell.com/attachment.cgi?id=477198) fstab, crypttab, mdadm.conf and dmesg output, showing /dev/md1 "already in use" -- 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=743717 https://bugzilla.novell.com/show_bug.cgi?id=743717#c16 --- Comment #16 from Steve Revilak 2012-02-26 19:33:33 UTC --- I installed systemd-sysvinit-37-3.153.1.x86_64 systemd-37-3.153.1.x86_64 from http://download.opensuse.org/repositories/home:/fcrozat:/systemd/openSUSE_12... We are making progress. Upon reboot, systemd activated both of my system's raid partitions (`/', which is unencrypted, and `/home', which is luks-encrypted). This is an improvement over what I experienced earlier. Unfortunately, there is still a glitch. During boot, I saw the prompt asking me to provide a passphrase for /home. However, the boot sequence didn't pause at this point. systemd continued to execute (later) steps in the boot sequence, and didn't give me the opportunity to enter a passphrase. In other words, the boot sequence ran right over the passphrase prompt. On the bright side, I was able to get on the console after boot, and mount `/home' via systemctl stop cryptsetup@cr_md1.service systemctl start cryptsetup@cr_md1.service If it is possible to get the boot sequence to pause for a luks passphrase, then I think we'll be in very good shape. In the interim, I'll continue to use systemd-37-3.153.1 from the fcrozat repository. -- 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=743717 https://bugzilla.novell.com/show_bug.cgi?id=743717#c18 --- Comment #18 from Steve Revilak 2012-02-28 12:47:56 UTC --- Now I see what is happening. I was being given the opportunity to provide a passphrase for /home, but the timeout was very short. I'd have to notice the passphrase prompt, type in my passphrase while systemd continued to emit output, and get it done before kdm started. To get around this, I've added a `timeout' option to /etc/crypttab, as follows. $ cat /etc/crypttab cr_md1 /dev/md1 none tries=3,timeout=60 This gives me plenty of time to provide a passphrase, and solves the issue that I initially reported. In the process of testing, I tried booting with systemd.log_level=debug systemd.log_target=kmsg. With these options systemd didn't activate /dev/md1; without these options, /dev/md1 was activated. I'll attach this dmesg output as dmesg-debug-md1-not-activated.txt. I plan to boot without the extra log options, so I don't foresee this being an ongoing issue for me. I'm attaching the dmesg output in case it has diagnostic value for you. -- 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=743717 https://bugzilla.novell.com/show_bug.cgi?id=743717#c20 --- Comment #20 from Frederic Crozat 2012-02-28 13:31:11 UTC --- I don't think these options had anything to do with /dev/md1 being mounted or not.

From the log, it looks like /dev/md1 was already used by something : [ 19.575981] boot.md[460]: Starting MD RAID mdadm: /dev/md1 is already in use. [ 19.576269] boot.md[460]: ..failed

but I don't know why or by what. -- 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=743717 https://bugzilla.novell.com/show_bug.cgi?id=743717#c22 Frederic Crozat changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #22 from Frederic Crozat 2012-12-03 14:12:18 UTC --- so, let's close -- 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.