https://bugzilla.novell.com/show_bug.cgi?id=333753#c1 Hannes Reinecke changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Hannes Reinecke 2007-10-18 06:58:51 MST --- *** This bug has been marked as a duplicate of bug 334461 *** https://bugzilla.novell.com/show_bug.cgi?id=334461 -- 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=333753#c3 Hannes Reinecke changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO Info Provider| |oen@dsl.pipex.com --- Comment #3 from Hannes Reinecke 2007-10-19 00:38:37 MST --- So you're saying that you tested the patch from bug #334461 and it didn't work? -- 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=333753#c5 --- Comment #5 from Hannes Reinecke 2007-10-19 08:20:15 MST --- Okay, this is what you can do: - Install 10.3 up to the point where the error happens. - Switch to another console with <CTRL>-<ALT>-<F2> - Check where the installed system is mounted with 'mount' (should be at /mnt) - Switch to the installed system with: mount --bind /dev /mnt/dev cd /mnt chroot . mount /sys mount /proc - Edit the mkinitrd script in /lib/mkinitrd/scripts/setup-block.sh - re-run mkinitrd - switch from the installed system with: umount /sys umount /proc exit umount /mnt/dev - switch back to the installation screen and press 'continue' Now the system should be able to boot ... hopefully. -- 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=333753#c7 Hannes Reinecke changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|hare@novell.com |mkoenig@novell.com Status|REOPENED |NEW --- Comment #7 from Hannes Reinecke 2007-10-22 00:55:37 MST --- Hmm. Looks more like a dmraid problem then. -- 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=333753#c9 --- Comment #9 from Occo Eric Nolf 2007-10-22 07:18:11 MST ---

Hmm. Looks more like a dmraid problem then.

Under 10.2, dmraid has always been somewhat tricky. When using RAID0+1 one might expect the partitioner to specify 1 large drive - but that is not what happens. The partitioner (both during installation and on the installed 10.2 system) always starts with reporting that the partition tables of 2 of the 4 drives can not be read. This doesn't make sense - the drives themselves are not important at all, onlt the RAID0+1 is. The partition table shows not only the RAID0+1 array, but also the 2 underlying striped arrays plus details of the 2 drives reported earlier as having a partition table that can't be read (1 drive in each of the striped arrays). In principle, one could define partitions on these - and that should be impossible, as they are integral parts of the RAID0+1. I got the impression dmraid is hardly being maintained nowadays, but didn't pay too much attention as it DOES work under 10.2. Under 10.3 the situation is different ... it doesn't work.

Please boot into the 10.3 rescue system and provide the output of dmraid -r and dmraid -s

That's a bit of a problem as I've only 1 system running on RAID0+1 - and that, in fact, is my main system. When 10.3 didn't work I re-installed 10.2. Getting the information you request would entail a complete install of 10.3, booting into the rescue system, and then re-installing 10.2 to get my main system running again (I can't free any partitions to make room for a more permanent 10.3 install). This is rather time-consuming, as you can imagine - apart from the risks I take by experimenting on what is basically a production system. However ... if you really need this info let me know and I'll fit it in somehow. -- 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=333753#c11 --- Comment #11 from Occo Eric Nolf 2007-10-23 06:16:58 MST --- Thanks Matthias, I was too busy to even think of that possibility. I'll give it a try as soon as I can find some time, and publish the results here. -- 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=333753#c13 Occo Eric Nolf changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|oen@dsl.pipex.com | --- Comment #13 from Occo Eric Nolf 2007-10-24 06:40:57 MST --- I can confirm David's post: these commands produce identical results using 10.2 and using the rescue system of the 10.3 KDE CD (both in the 64bit variety). -- 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=333753#c15 Occo Eric Nolf changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|oen@dsl.pipex.com | --- Comment #15 from Occo Eric Nolf 2007-10-26 18:07:20 MST --- Before getting to the output produced by the different commands it may be useful to draw your attention to the following 2 facts: 1 - Although RAID0+1 runs OK under 10.2 there was a problem with the original installation. For some reason, the 10.2 installation program would fail when LVM was used in combination with RAID0+1. Even a setup where non-LVM partitions were defined for the boot and root partitions wouldn't succeed. 2 - The numbering of the partitions on the RAID0+1 in my system is not the same as the physical position of the partitions on disk. To be precise: the physical order is 1, 5, 6, 8, 9, 10, and 7. This is caused by the dual-boot setup of my system where partitions can be created both under Windows XP x64 and under Linux. David Sauve, the other poster to this thread, has a single-boot system and the partitions on his RAID0+1 are numbered in the correct physical order; as we both experience the same problems with installing 10.3 this may not be an important issue. On the installed 10.2 system, the command 'dmsetup -ls' produces this output: ---------- Start of output nvidia_acdaaaad-0_part6 (253, 19) nvidia_acdaaaad-0_part10 (253, 23) nvidia_acdaaaad_part10 (253, 16) nvidia_acdaaaad-1_part9 (253, 8) nvidia_acdaaaad-0_part5 (253, 18) nvidia_acdaaaad-1_part8 (253, 7) nvidia_acdaaaad_part1 (253, 10) nvidia_acdaaaad-1_part7 (253, 6) nvidia_acdaaaad (253, 2) nvidia_acdaaaad-1_part6 (253, 5) nvidia_acdaaaad-1_part5 (253, 4) nvidia_acdaaaad-0_part1 (253, 17) nvidia_acdaaaad-1_part10 (253, 9) nvidia_acdaaaad_part9 (253, 15) nvidia_acdaaaad_part8 (253, 14) nvidia_acdaaaad-1_part1 (253, 3) nvidia_acdaaaad_part7 (253, 13) nvidia_acdaaaad-1 (253, 1) nvidia_acdaaaad-0_part9 (253, 22) nvidia_acdaaaad_part6 (253, 12) nvidia_acdaaaad-0 (253, 0) nvidia_acdaaaad-0_part8 (253, 21) nvidia_acdaaaad_part5 (253, 11) nvidia_acdaaaad-0_part7 (253, 20) ---------- End of output On the 10.3 rescue system, after executing 'dmraid -ay -p', the command 'dmsetup ls' produces this output: ---------- Start of output nvidia_acdaaaad-0_part6 (253, 6) nvidia_acdaaaad-0_part10 (253, 10) nvidia_acdaaaad_part10 (253, 18) nvidia_acdaaaad-1_part9 (253, 25) nvidia_acdaaaad-0_part5 (253, 5) nvidia_acdaaaad_part2 (253, 12) nvidia_acdaaaad-1_part8 (253, 24) nvidia_acdaaaad_part1 (253, 11) nvidia_acdaaaad-1_part7 (253, 23) nvidia_acdaaaad (253, 2) nvidia_acdaaaad-1_part6 (253, 22) nvidia_acdaaaad-0_part2 (253, 4) nvidia_acdaaaad-1_part5 (253, 21) nvidia_acdaaaad-0_part1 (253, 3) nvidia_acdaaaad-1_part10 (253, 26) nvidia_acdaaaad_part9 (253, 17) nvidia_acdaaaad-1_part2 (253, 20) nvidia_acdaaaad_part8 (253, 16) nvidia_acdaaaad-1_part1 (253, 19) nvidia_acdaaaad_part7 (253, 15) nvidia_acdaaaad-1 (253, 1) nvidia_acdaaaad-0_part9 (253, 9) nvidia_acdaaaad_part6 (253, 14) nvidia_acdaaaad-0 (253, 0) nvidia_acdaaaad-0_part8 (253, 8) nvidia_acdaaaad_part5 (253, 13) nvidia_acdaaaad-0_part7 (253, 7) ---------- End of output There are differences: the 10.3 listing has 3 extra lines. As far as I can see this is because the 10.3 listing contains entries for partition #2 of the RAID0+1 and of both underlying RAID0 arrays. That seems strange, as partition #2 is the extended partition containing all other partitions except #1. On the 10.3 rescue system the command 'dmraid -ay -p -vvv' produces this output: ---------- Start of output WARN: locking /var/lock/dmraid/.lock NOTICE: /dev/sda: asr discovering NOTICE: /dev/sda: ddf1 discovering NOTICE: /dev/sda: hpt37x discovering NOTICE: /dev/sda: hpt45x discovering NOTICE: /dev/sda: isw discovering NOTICE: /dev/sda: jmicron discovering NOTICE: /dev/sda: lsi discovering NOTICE: /dev/sda: nvidia discovering NOTICE: /dev/sda: nvidia metadata discovered NOTICE: /dev/sda: pdc discovering NOTICE: /dev/sda: sil discovering NOTICE: /dev/sda: via discovering NOTICE: /dev/sdb: asr discovering NOTICE: /dev/sdb: ddf1 discovering NOTICE: /dev/sdb: hpt37x discovering NOTICE: /dev/sdb: hpt45x discovering NOTICE: /dev/sdb: isw discovering NOTICE: /dev/sdb: jmicron discovering NOTICE: /dev/sdb: lsi discovering NOTICE: /dev/sdb: nvidia discovering NOTICE: /dev/sdb: nvidia metadata discovered NOTICE: /dev/sdb: pdc discovering NOTICE: /dev/sdb: sil discovering NOTICE: /dev/sdb: via discovering NOTICE: /dev/sdc: asr discovering NOTICE: /dev/sdc: ddf1 discovering NOTICE: /dev/sdc: hpt37x discovering NOTICE: /dev/sdc: hpt45x discovering NOTICE: /dev/sdc: isw discovering NOTICE: /dev/sdc: jmicron discovering NOTICE: /dev/sdc: lsi discovering NOTICE: /dev/sdc: nvidia discovering NOTICE: /dev/sdc: nvidia metadata discovered NOTICE: /dev/sdc: pdc discovering NOTICE: /dev/sdc: sil discovering NOTICE: /dev/sdc: via discovering NOTICE: /dev/sdd: asr discovering NOTICE: /dev/sdd: ddf1 discovering NOTICE: /dev/sdd: hpt37x discovering NOTICE: /dev/sdd: hpt45x discovering NOTICE: /dev/sdd: isw discovering NOTICE: /dev/sdd: jmicron discovering NOTICE: /dev/sdd: lsi discovering NOTICE: /dev/sdd: nvidia discovering NOTICE: /dev/sdd: nvidia metadata discovered NOTICE: /dev/sdd: pdc discovering NOTICE: /dev/sdd: sil discovering NOTICE: /dev/sdd: via discovering NOTICE: added /dev/sda to RAID set "nvidia_acdaaaad" NOTICE: added /dev/sdb to RAID set "nvidia_acdaaaad" NOTICE: added /dev/sdc to RAID set "nvidia_acdaaaad" NOTICE: added /dev/sdd to RAID set "nvidia_acdaaaad" RAID set "nvidia_acdaaaad" already active INFO: Activating raid10 RAID set "nvidia_acdaaaad" WARN: unlocking /var/lock/dmraid/.lock ---------- End of output Any more information you may need, just let me know - I'll try to respond a little faster next time :) Eric -- 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=333753#c17 --- Comment #17 from David Sauve 2007-11-07 08:29:49 MST --- Is anything happening with this bug or has it been forgotten? I haven't seen any updates from Novell in two weeks? Is there something I can add that might help? I'd really like to get 10.3 installed at some point, but this thing is preventing 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=333753#c19 Ulf Markwardt changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ulf.markwardt@tu-dresden.de --- Comment #19 from Ulf Markwardt 2007-11-19 12:51:18 MST --- I run into the same problems with a Promise fake raid (mirror). Ulf -- 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=333753#c21 --- Comment #21 from Ulf Markwardt 2007-11-24 14:40:09 MST --- Eric, I got my system running 2 weeks ago! It was a question of just a few evenings :-) Here is basically, what I did: * I could install 10.3 on a small partition on a "normal disk". E.g. one of the two raid disks on normal controller. * Calling "dmraid -ay" did recongize the fake raid controller. I got devices under /dev/mapper. * fdisk /dev/mapper/pdc_dgeejifgbh (pdc is for Promise controller) and mkmfs a Linux partition. Mount it (/mnt) and copy the running system there : Manually tar cf - /DIR | (cd mnt; tar xfv -) where DIR=/bin /boot ... * Run mkinitrd - it will create error messages, but this doesn't matter much, it will create the right initrd, nevertheless. ( I gave it a unique name like initrd.dm) - move it to /mnt/boot/. * While booting switch into grub command line modus. Use "find /boot/initrd.dm" to identify the right hd-# (since the BIOS and grub tend to re-numerate the disks ...) * Set this partition as root (like "root (hd2,1)"). * Define "kernel /boot/vmlinuz root=/dev/mapper/pdc_dgeejifgbh_part1" according to your own settings * Set "initrd /boot/initrd.dm" and boot! If this runs OK - you can automate the boot sequence by changing the menu.lst (on your "normal" partition - where grub is installed). ------------------- To install grub to you fake raid... * at grub command line (during boot): set "root (hdX,Y)" see above. "setup (hdX)" will install the MBR on this disk. * Change the boot sequence in your BIOS * your grub configuration will fail, since the disk number is changed now. But you can proceed with the steps above to locate the right partition (probably hd0) and continue booting the raid. * To prevent mounting problems use device IDs in /etc/fstab like "/dev/disk/by-id/scsi-SATA_SAMSUNG_SP1213CS02AJ10X800616-part1" ------------------- After a few hours reading GRUB docs and examples, and toying around with the boot loader: GRUB is cool Hope this could help or at least motivate you :-) Ulf ------------------- PS: Eric, there was an OS which frequently crashed and on a blue screen suggested to contact the admin or the vendor, and Bill Gates was one of the most hated persons around here... And this OS was BOUGHT. The name of our game is OPENSuse. It comes for free. It is not free of support, but what you get is mare than from the vendor of that wanna-be-OS, back in the 90s. You can buy support, you can buy a nice stable SLES 10. Then you have other cont(r)act persons and your requests would be acknowledged in another way. But as it is, only "the community" will help you eventually. And this might take a little while. -- 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=333753 User mkoenig@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c23 Matthias Koenig changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mkoenig@novell.com AssignedTo|mkoenig@novell.com |hare@novell.com --- Comment #23 from Matthias Koenig 2008-01-23 05:00:26 MST --- Sorry, this bug got accidentally lost from my list. Comments #12, #15 and #21 seems to indicate that dmraid is basically working. It detects the metadata and creates the device-mapper devices. So, I am out of clue here. Trying Hannes again, as comment #21 mentions errors 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=333753 User jos.baudrez@telenet.be added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c25 --- Comment #25 from Jos Baudrez 2008-01-24 12:25:09 MST --- .. but how does this explain the problem I have with the un-ability to recognise a striped nvidia fake raid (as i demo-ed in comment 16) ? -- 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=333753 User mkoenig@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c27 --- Comment #27 from Matthias Koenig 2008-01-25 02:36:43 MST --- Referring to comment #25. Jos, yes you are right. But your problem appears to be a completely different one. In your case there seems to be something wrong with the metadata detection. Please open a separate bug for this one, we shouldn't mix things up here. Next to the information you already provided in comment #16, it would be useful to get the metadata in native format with dmraid -n (for both systems 10.2 and 10.3). -- 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=333753 User oen@dsl.pipex.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c29 --- Comment #29 from Occo Eric Nolf 2008-02-21 05:36:01 MST --- It appears that the openSuse developers are still in denial and stubbornly refuse to acknowledge that 10.3 can not be installed on (some) systems running nVraid0+1 - and possibly, on other nVraid setups. The words ostrich, head, and sand come to mind. There are several open bugs which might be regarded as clones of this bug. Examples are the bugs #356226 and #357725. I decided to remove everything smelling of openSuse from my systems. Therefore I'm no longer interested in a solution that isn't forthcoming anyway. By all means, feel free to end the farce by closing this thread. -- 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=333753 Stanislav Visnovsky changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |visnov@novell.com Component|Installation |Booting -- 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=333753 User oen123@gmail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c31 --- Comment #31 from Occo Eric Nolf 2008-05-21 13:30:29 MST --- Who cares??? Certainly not your colleagues at Novell. They managed to ignore this bug from the day it was submitted. In order to do so they even didn't hesitate to come with easily exposed lies. This is not just about a bug that was never eliminated ... it's about a sick mentality that needs changing. Assuming the same people are still responsible, I see no reason why there would be any difference with release 11. Abandoning everything to do with Novell and openSuse was a wise decision. -- 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=333753 User aosthof@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c33 Alexander Osthof changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|aosthof@novell.com |jreidinger@novell.com Status|ASSIGNED |NEW --- Comment #33 from Alexander Osthof 2008-07-14 07:31:18 MDT --- Reassigning to new maintainer of perl-Bootloader. -- 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=333753 Josef Reidinger changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium -- 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=333753 User oakyangnjucn@gmail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c36 Yang Bo changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oakyangnjucn@gmail.com --- Comment #36 from Yang Bo 2009-01-06 05:45:24 MST --- I have a system nforce 430 chipset with nvraid enabled. It seems that I have the same problem here. I have windows installed on the raid and it worked fine. FC9 and gentoo both worked with XP. When I tried to install OpenSUSE on it, it can't recongnize the origin raid set but built a new one instead. OpenSUSE 10.2 works fine, but 10.3 to 11.1 doesn't. The original raidset was called nvidia_cigihdee on gentoo ,fedora and OpenSUSE10.2, but some other things on later versions. What's more intresting is that whenever I boot OpenSUSE(10.3 or later) through CD, the system refuses to boot from the harddisk(It said that no OS was installed on the disk), reboot doesn't fix the problem, but poweroff the machine fixes this. Hope this would be fixed in 11.2 or 12 so I can use OpenSUSE again. I do love this distro. -- 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=333753 User oakyangnjucn@gmail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c38 --- Comment #38 from Yang Bo 2009-01-06 07:30:47 MST --- Created an attachment (id=263389) --> (https://bugzilla.novell.com/attachment.cgi?id=263389) opensuse11.0 32bit on nvidia fakeraid I've tried that the error was happed far before yast was called. I belive it's the problem of initrd, it misrecongnized the raidset. Every time after the system is boot(even with a netinstall cd) the raidset is corrupted and I have to power off the machine to get it back. I made a test, boot the kernel of opensuse11.1(64) with initrd of FC9(64), of course it failed, but the output said it can't find some modules but the raidset's name was correct. I'm just a newbie and all above is just some guess. -- 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=333753 User oakyangnjucn@gmail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c40 --- Comment #40 from Yang Bo 2009-01-06 08:30:37 MST --- add "libata.ignore_hpa=0" to boot options solves the problem. Thanks Jos Baudrez for giving me this tip. -- 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=333753 User teheo@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c41 --- Comment #41 from Tejun Heo 2009-01-21 17:42:32 MST --- There are two problems here. 1. Certain dm raid layouts put the metadata at the end of the disk and the "end" of the disk is determined with HPA turned on. On openSUSE, HPA is turned off by default to remain compatible with the original IDE behavior and I think several other distros do so too. Anyways, with HPA unlocked, the end of disk is no longer the place where the BIOS wants the OS to think it is so the array detection fails. This can be worked around by turning off HPA unlocking but more graceful solution would be teaching dm that the device has two sizes - the BIOS one and the native one and try the BIOS one first. 2. On reboot, probably the BIOS doesn't bother to re-enable or check HPA status and fails miserably with the HPA unlocked. This is BIOS's fault as BIOS shouldn't assume the system configuration to be in specific state on reboot but it might be workaroundable by making libata restore HPA setting on detach, but I don't know it's just messy. Earlier nv boards had a lot of hardware and BIOS problems, so it's not too surprising tho. Anyways, the dual size thing has been on my to do list for quite some time now. I think it's about time I get on to it. And, BTW, it's probably best to simply avoid those BIOS RAIDs. There simply is no advantage over md raid other than supporting direct booting from the array and it can easily be worked around by making a small boot partition on md raid1. -- 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=333753 User teheo@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c42 Tejun Heo changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |oen123@gmail.com --- Comment #42 from Tejun Heo 2009-01-31 20:06:03 MST --- Patches to deal with #1 pending upstream. http://lkml.org/lkml/2009/1/31/210 Yang Bo, can you please post the output of "lspci -nn"? As device reset clears the volatile SET_MAX done by libata, it shouldn't affect BIOS. I'm not quite sure about #2 at the moment. Also, does the board happen to have BIOS update? If so, can you please try it and see whether the rebooting problem goes away? -- 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.