Bugzilla – Bug 812316
openSUSE 12.3 will not install on dmraid RAID configurations
Last modified: 2013-10-02 08:34:14 UTC
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16.1 Bug 810840 reports problems with dmraid due to an upgrade from openSUSE 12.2 to 12.3. Don't know if there is any relation, but my problem is more elementary. OpenSUSE 12.3 will not install on dmraid RAID arrays. It will not accept pre-formatted partitions (produced with GParted) and it will not format dmraid partitions. This has been discussed by several people in the Install forum, thread started on 2013-03-13, but maybe not properly reported as bug. Let me formulate my case, as experienced on 2 PC's with dmraid volumes. Installation from scratch. RAID 0, 2 disks, dmraid (a.k.a. "fake" RAID), x86_64. On one PC, openSUSE is the only operating system to start with, on the other one openSUSE 12.2 should be replaced with openSUSE 12.3 and like 12.2, 12.3 should eventually co-exist with Windows XP. And then there are my 2 "production PC's", both also with 2 "dmraid" disk arrays, one RAID 1. So far, I dare not touch them with openSUSE 12.3. All PC's have "AMD" motherboards and the latest BIOS updates. So far, I have installed openSUSE 12.3 allright on 2 single disk PCs. Hopefully, openSUSE comes up with a solution soon, other than "wait for 12.4". By the way, what is F6 (Driver) at the very beginning of the installation? Can that give a solution? From my part I cannot do much with that functionality, because a driver should be compatible with the kernel version, but maybe you can do something with it. Kind regards, Andre Hasekamp. Reproducible: Always Steps to Reproduce: 1.Simply try to install openSUSE 12.3 on a "dmraid" RAID configuration. 2. 3. Actual Results: Formatting device mapper volume ... with ext4 System error code was -3030 Expected Results: Formatting of the RAID array
Andre, can you please attach the y2logs? (When you get the error message, switch to a tty, run "save_y2logs" and copy the resulting file somewhere, for example to an USB memory stick.)
Hello Christian, Once I get the -3030 error message during installation, there is really no choice left. When a do an abort, I am brought into terminal mode in a "Main Menu". When I then do "Expert | start shell", I get the message: Cannot set terminal process group (-1): inappropriate ioctl for device No job control in this shell Sorry, am I doing something dumb? Other choices in the "Main Menu" show a lot of information, but cannot be saved. The only thing I could try is make pictures from the screens and send them as jpg files, but I wonder if anything readable comes out. Kind regards, Andre Hasekamp.
Created attachment 532800 [details] y2logs from dmraid install attempt Hello Christian, Don't ask me how I did it, but somehow or another I managed to get the y2logs. Kind regards, Andre Hasekamp.
There is a file /etc/udev/rules.d/70-kpartx.rules that is part of the multipath-tools package. In 12.2 it contains (among many other things) ENV{DM_STATE}=="ACTIVE", ENV{DM_UUID}=="DMRAID-*|dmraid-*", \ RUN+="/sbin/kpartx -u -p _part /dev/$kernel" This runs kpartx to create partition devices for each partition in a dmraid array. In 12.3 it contains the slightly different ENV{DM_STATE}=="ACTIVE", ENV{DM_UUID}=="DMRAID-*|dmraid-*", \ RUN+="/sbin/kpartx -u -p -part /dev/$kernel" Note the difference: "-part" rather than "_part". This means the partition device files created under /dev have a different name than before. This confuses the installer (and possibly other things) resulting in the failed installation. If you can break in to the installation process somewhere and either modify that file, or create links in /dev ot similar, then you might be able to get the installation to succeed. Meanwhile, I'm reassigning to the maintainer of multipath-utils.
Hello Neil, Easier said than done, breaking in in the install procedure. It is very much a closed procedure (and should probably remain so, in order not to complicate things for openSUSE users). As mentioned earlier, the only entry I see is through F6, but that is a very limited entry and not suitable for this case (I think). Nevertheless, I'll have a look at the install DVD. If I find something, I'll report it here. Otherwise, I'll have to wait for a solution coming from openSUSE. Kind regards, Andre Hasekamp.
*** Bug 813889 has been marked as a duplicate of this bug. ***
I also run into issues during install of openSUSE 12.3, also during a new install. Isolating the problem of the instability during installation further I now think this is related to the software raid configuration I was using. See my original bug report https://bugzilla.novell.com/show_bug.cgi?id=813889 Yesterday I was installing 12.3 on a Supermicro X9DRi-LN4+/X9DR3-LN4 system with two E5-2620 processors, using a combination of raid1 and raid10 f2 devices with 6 disks. After the install process has initialized the devices and it is syncing the raid devices, the system hangs as soon as the first rpms are written to the devices. Installing without raid devices, e.g. with the root partition direct on one partition on a disk is successful. With the system running from one disk, I did some experimenting with raid devices. I created a raid0 device with partitions on 6 disks and did create some files on it. No problem, but note, there is no sync process running with a raid0 device. Next I created a raid10 device with o2 layout with partitions on 5 disks (Using Yast Partitioner). Next I did put a file system on it (ext4) and the system is still oke. Finally I mounted the device and gave an ls command in the root of the device and now the system dies. It looks like the system is stable if you leave the raid device untouched during syncing. However the problem can be triggered again by issuing echo check >/sys/devices/virtual/block/md2/md/sync_action and accessing the device again. Here are the corresponding messages of the last action: 2013-04-09T21:42:17.083947+02:00 dom0-tex kernel: [84050.083495] md: data-check of RAID array md2 2013-04-09T21:42:17.083971+02:00 dom0-tex kernel: [84050.083502] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. 2013-04-09T21:42:17.083975+02:00 dom0-tex kernel: [84050.083505] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check. 2013-04-09T21:42:17.083977+02:00 dom0-tex kernel: [84050.083520] md: using 128k window, over a total of 157296320k. 2013-04-09T21:43:50.949905+02:00 dom0-tex kernel: [84143.765967] EXT4-fs (md2): mounted filesystem with ordered data mode. Opts: (null) 2013-04-09T21:43:52.985988+02:00 dom0-tex kernel: [84145.797969] BUG: scheduling while atomic: ext4lazyinit/15069/0xffffffff 2013-04-09T21:43:52.986009+02:00 dom0-tex kernel: [84145.797973] Modules linked in: fuse btrfs zlib_deflate libcrc32c ufs qnx4 hfsplus hfs minix vfat msdos fat jfs reiserfs nls_utf8 xfs raid0 dm_mod st udf crc_itu_t xt_tcpudp xt_pkttype xt_physdev xt_LOG xt_limit af_packet bridge stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack 2013-04-09T21:43:52.986012+02:00 dom0-tex kernel: [84145.798015] sd 6:0:3:0: [sdd] command ffff880100ea6080 timed out 2013-04-09T21:43:52.986014+02:00 dom0-tex kernel: [84145.798019] ip6table_filter ip6_tables x_tables cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper iTCO_wdt cryptd lrw gpio_ich iTCO_vendor_support aes_x86_64 igb xts sr_mod gf128mul sb_edac ptp lpc_ich pcspkr edac_core ioatdma joydev pps_core i2c_i801 mfd_core dca cdrom microcode mei sg wmi container button raid1 raid10 autofs4 ttm drm_kms_helper drm isci i2c_algo_bit sysimgblt libsas sysfillrect syscopyarea scsi_transport_sas processor thermal_sys scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_dh_rdac scsi_dh 2013-04-09T21:43:52.986016+02:00 dom0-tex kernel: [84145.798065] Pid: 15069, comm: ext4lazyinit Not tainted 3.7.10-1.1-desktop #1 2013-04-09T21:43:52.986017+02:00 dom0-tex kernel: [84145.798066] Call Trace: 2013-04-09T21:43:52.986018+02:00 dom0-tex kernel: [84145.798093] sd 7:0:0:0: [sde] command ffff88040b653dc0 timed out 2013-04-09T21:43:52.986019+02:00 dom0-tex kernel: [84145.798106] [<ffffffff81004818>] dump_trace+0x88/0x300 2013-04-09T21:43:52.986021+02:00 dom0-tex kernel: [84145.798117] [<ffffffff8158b033>] dump_stack+0x69/0x6f 2013-04-09T21:43:52.986022+02:00 dom0-tex kernel: [84145.798126] [<ffffffff8158cf34>] __schedule_bug+0x48/0x54 2013-04-09T21:43:52.986023+02:00 dom0-tex kernel: [84145.798134] [<ffffffff81596814>] thread_return+0x450/0x45c 2013-04-09T21:43:52.986024+02:00 dom0-tex kernel: [84145.798141] sd 6:0:1:0: [sdb] command ffff8803fcb40080 timed out 2013-04-09T21:43:52.986025+02:00 dom0-tex kernel: [84145.798146] sd 6:0:2:0: [sdc] command ffff880102408780 timed out 2013-04-09T21:43:52.986026+02:00 dom0-tex kernel: [84145.798155] sd 7:0:1:0: [sdf] command ffff880412e83a80 timed out 2013-04-09T21:43:52.986027+02:00 dom0-tex kernel: [84145.798166] [<ffffffff81594e1a>] schedule_timeout+0x1fa/0x2f0 2013-04-09T21:43:52.986029+02:00 dom0-tex kernel: [84145.798175] [<ffffffff81595eef>] wait_for_common+0xcf/0x170 2013-04-09T21:43:52.986030+02:00 dom0-tex kernel: [84145.798184] [<ffffffff812a5a7d>] blkdev_issue_write_same+0x1bd/0x1d0 2013-04-09T21:43:52.986031+02:00 dom0-tex kernel: [84145.798193] [<ffffffff812a5c92>] blkdev_issue_zeroout+0x82/0xe0 2013-04-09T21:43:52.986032+02:00 dom0-tex kernel: [84145.798202] [<ffffffff811e9610>] ext4_init_inode_table+0x160/0x370 2013-04-09T21:43:52.986033+02:00 dom0-tex kernel: [84145.798212] [<ffffffff811fd762>] ext4_lazyinit_thread+0x142/0x2d0 2013-04-09T21:43:52.986034+02:00 dom0-tex kernel: [84145.798222] [<ffffffff810681c3>] kthread+0xb3/0xc0 2013-04-09T21:43:52.986035+02:00 dom0-tex kernel: [84145.798229] [<ffffffff8159eafc>] ret_from_fork+0x7c/0xb0 2013-04-09T21:44:23.258036+02:00 dom0-tex kernel: [84176.010572] sd 6:0:3:0: [sdd] command ffff8801014200c0 timed out 2013-04-09T21:44:23.258063+02:00 dom0-tex kernel: [84176.010580] sd 6:0:3:0: [sdd] command ffff88044610e1c0 timed out 2013-04-09T21:44:23.258066+02:00 dom0-tex kernel: [84176.010584] sd 6:0:1:0: [sdb] command ffff880102630ec0 timed out 2013-04-09T21:44:23.258068+02:00 dom0-tex kernel: [84176.010592] sd 7:0:1:0: [sdf] command ffff88010165a3c0 timed out 2013-04-09T21:44:23.258070+02:00 dom0-tex kernel: [84176.010596] sd 7:0:0:0: [sde] command ffff8803fcb40480 timed out 2013-04-09T21:44:23.258072+02:00 dom0-tex kernel: [84176.010600] sd 7:0:0:0: [sde] command ffff8803f7ae2480 timed out 2013-04-09T21:44:23.258073+02:00 dom0-tex kernel: [84176.010603] sd 7:0:0:0: [sde] command ffff8801006feb80 timed out 2013-04-09T21:44:23.258074+02:00 dom0-tex kernel: [84176.010647] sas: Enter sas_scsi_recover_host busy: 6 failed: 6 2013-04-09T21:44:23.258076+02:00 dom0-tex kernel: [84176.010660] sas: trying to find task 0xffff880412ec66c0 2013-04-09T21:44:23.258077+02:00 dom0-tex kernel: [84176.010664] sas: Enter sas_scsi_recover_host busy: 6 failed: 6 2013-04-09T21:44:23.258080+02:00 dom0-tex kernel: [84176.010668] sas: sas_scsi_find_task: aborting task 0xffff880412ec66c0 2013-04-09T21:44:23.258082+02:00 dom0-tex kernel: [84176.010670] sas: trying to find task 0xffff8804147cfac0 2013-04-09T21:44:23.258083+02:00 dom0-tex kernel: [84176.010671] sas: sas_scsi_find_task: aborting task 0xffff8804147cfac0 2013-04-09T21:44:23.258085+02:00 dom0-tex kernel: [84176.010679] isci 0000:03:00.0: isci_task_abort_task: dev = ffff880854c04238 (SSP), task = ffff8804147cfac0, old_request == ffff880854ce9000 2013-04-09T21:44:23.258087+02:00 dom0-tex kernel: [84176.010683] isci 0000:03:00.0: isci_task_abort_task: dev = ffff880855704478 (SSP), task = ffff880412ec66c0, old_request == ffff880855793000 2013-04-09T21:44:23.258089+02:00 dom0-tex kernel: [84176.011075] isci 0000:03:00.0: isci_task_abort_task: Done; dev = ffff880854c04238, task = ffff8804147cfac0 , old_request == ffff880854ce9000 2013-04-09T21:44:23.258090+02:00 dom0-tex kernel: [84176.011082] sas: sas_scsi_find_task: task 0xffff8804147cfac0 is aborted 2013-04-09T21:44:23.258092+02:00 dom0-tex kernel: [84176.011085] sas: sas_eh_handle_sas_errors: task 0xffff8804147cfac0 is aborted 2013-04-09T21:44:23.258095+02:00 dom0-tex kernel: [84176.011090] sas: trying to find task 0xffff880344f6c080 2013-04-09T21:44:23.258096+02:00 dom0-tex kernel: [84176.011092] sas: sas_scsi_find_task: aborting task 0xffff880344f6c080 2013-04-09T21:44:23.258098+02:00 dom0-tex kernel: [84176.011098] isci 0000:03:00.0: isci_task_abort_task: dev = ffff880854c042f8 (SSP), task = ffff880344f6c080, old_request == ffff880854c9e000
Nope, that looks like a completely different bug. This one is about DM raid. You seem to be using md raid, which is very different. I think your bug is fixed by upstream kernel commit c8dc9c654794a765ca61baed07f84ed8aaa7ca And if it isn't too much trouble, please always attach logs rather than pasting them in (unless they are very short). As you can see, bugzilla wraps long lines making logs like almost unreadable.
opensuse 13.1 M4 same error in the installer as in 12.3 install on bios raid-0 impossible you can define the array but when it has to format the raid-parts you get a -3030 error please fix this !!!!!!!!!!!!!!!!
have same problem with Raid 1. (motherboard raid function) will try to install 12.2 and updgrade to 12.3 as I read on other post. Factory version have same problem too. anything to achieve installation directly with factory version ?
This issue has also been reported with a different bug, so we should mark this as a duplicate. *** This bug has been marked as a duplicate of bug 810840 ***