[Bug 333753] New: Installation and upgrade fail on nvidia RAID0+1
https://bugzilla.novell.com/show_bug.cgi?id=333753 Summary: Installation and upgrade fail on nvidia RAID0+1 Product: openSUSE 10.3 Version: Final Platform: x86-64 OS/Version: openSUSE 10.3 Status: NEW Severity: Critical Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: oen@dsl.pipex.com QAContact: jsrain@novell.com Found By: --- When installing or upgrading 10.3 on an nvraid RAID0+1 system the mkinitrd script fails. The following messages appear: ------------ An error occurred during initrd creation. Kernel image: /boot/vmlinuz-2.6.22.5-31-default Initrd image: /boot/initrd-2.6.22.5-31-default Root device: /dev/mapper/nvidia_acdaaaad_part8 (mounted on / as ext3) Device dm-26 not handled. (please note: the number can vary) Script /lib/mkinitrd/setup/72-block.sh failed. Bootloader::Library::SetLoaderType: Initialization for unknown bootloader. Bootloader::Core::ListFiles: Running generic function, it should never be called. Bootloader::Core::ParseLines: Running generic function, it should never be called. ------------ The installation has then to be broken off. When rebooting, GRUB ends up in an Error 15. The old bootloader is still there. The system reverts to a command line version of GRUB from where Windows XP x64 can be booted. Log files are not available, as the 10.3 system is not accesssible at all. In case there is a possibility to boot into 10.3 someone please tell me how; I'll be happy to supply logfiles then. The error can not be caused by faulty installation media as it occurs using the DVD, the KDE CD, and the internet install. All of them fail in exactly the same way - but work fine on another system running on nvidia RAID1. The error is also specifically 10.3 because 10.2 can be re-installed without any problem on the RAID0+1 system. Finally, it turns out I'm not the only one to encounter this problem. David Sauve reports the same error here: http://www.mail-archive.com/opensuse@opensuse.org/msg47438.html David and I have been in contact and established that the systems on which 10.3 fails to install are both running nvraid RAID0+1. The systems are not completely identical: the RAID0+1 arrays are different in size, and my system is dual-boot where DS's system is not. In case any more information is needed, please let me know; good luck :-) -- 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 Cyril Hrubis <chrubis@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.provo.novell.com |hare@novell.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=333753#c1 Hannes Reinecke <hare@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Hannes Reinecke <hare@novell.com> 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#c2 Occo Eric Nolf <oen@dsl.pipex.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|DUPLICATE | --- Comment #2 from Occo Eric Nolf <oen@dsl.pipex.com> 2007-10-18 11:11:56 MST --- Sorry, but I'm not happy with what is going on here. First, this bug was marked as a duplicate of #334461, even though the latter was opened 3 days later. Apart from that, it turns out that the bugs are completely different in nature: #333753 is about the impossibility to install or upgrade to 10.3 on a system running on RAID0+1, whereas #334461 is about problems updating an existing 10.3 system which is not running on RAID0+1. The patch provided for #334461 is useless for #333753. I may be wrong, but to resolve bug #333753 it appears to be necessary to eliminate an error in the original mkinitrd script. 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#c3 Hannes Reinecke <hare@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO Info Provider| |oen@dsl.pipex.com --- Comment #3 from Hannes Reinecke <hare@novell.com> 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#c4 Occo Eric Nolf <oen@dsl.pipex.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED Info Provider|oen@dsl.pipex.com | --- Comment #4 from Occo Eric Nolf <oen@dsl.pipex.com> 2007-10-19 08:08:29 MST --- Hi Hannes, No, that's not what I'm saying. Any attempt to install 10.3 on my RAID0+1 system, and any attempt to upgrade to 10.3, results in a system that appears not to be accessible at all. The installation or upgrade stops at the point where the initrd should be written. There is no other option available than to break off the process; the result is a system without initrd and with the 'old' boodloader which doesn't know about the partially installed 10.3 system. To apply any patch it would be necessary to access the partially installed 10.3 system via the rescue system. This may be possible, but I'm not an expert in that particular area. However, even if that would work it would still mean that the mkinitrd script in the 10.3 installation program remains 'buggy'. If you think the patch for #334461 would solve the problem I described in my first post here, I'm willing to give it a try - provided you can tell me how to apply the patch via the rescue system. Any 10.3 installation or upgrade overwrites my existing 10.2 system which has to be re-installed if 10.3 won't run. I'm not looking forward to that, so please don't ask me to try unless you're fairly sure the patch will do the job :-)) 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#c5 --- Comment #5 from Hannes Reinecke <hare@novell.com> 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#c6 --- Comment #6 from Occo Eric Nolf <oen@dsl.pipex.com> 2007-10-20 08:22:51 MST --- Right, here is what happened ... - performed a fresh internet install, formatting existing partitions for /, /boot, and swap, and specifying mount points for the existing partition for /home and for 3 partitions used by XP - installation failed like before, due to failure to write initrd - using vim, edited file /lib/mkinitrd/scripts/setup-storage.sh changing local retval=$(cat /proc/partitions | egrep "^[ ]*$major[ ]*$minor") to local retval=$(cat /proc/partitions | egrep "^[ ]*$major[ ]*$minor ") - ran mkinitrd, resulting in familiar messages: Bootloader::Library::SetLoaderType: Initialization for unknown bootloader Bootloader::Core::ListFiles: Running generic function, it should never be called Bootloader::Core::ParseLines: Running generic function, it should never be called - didn't manage to resume the installation, re-booted system - didn't get anywhere using GRUB, got the installed system to boot using an installation DVD - got error messages all over the place: all partitions, except /, invalid because of missing superblocks - got kdm started in 10.3 and had a look at the partitioner: it didn't show any of the existing partitions except / - re-installed 10.2 using an installation DVD, the partitioner had no problem loading the correct partition table and all existing partitions! ---------------- Unless I did something wrong, the patch for #334461 is not the solution for this bug. There seems to be a fundamental problem with RAID0+1 in version 10.3 ... the fact that the partitioners of 10.2 and 10.3 come up with completely different partition tables seems to confirm this. 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#c7 Hannes Reinecke <hare@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|hare@novell.com |mkoenig@novell.com Status|REOPENED |NEW --- Comment #7 from Hannes Reinecke <hare@novell.com> 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#c8 Matthias Koenig <mkoenig@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |oen@dsl.pipex.com --- Comment #8 from Matthias Koenig <mkoenig@novell.com> 2007-10-22 03:56:50 MST --- Please boot into the 10.3 rescue system and provide the output of dmraid -r and dmraid -s -- 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 <oen@dsl.pipex.com> 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#c10 --- Comment #10 from Matthias Koenig <mkoenig@novell.com> 2007-10-23 04:20:50 MST --- You don't have to do an install of 10.3. You just have to select the rescue system (when booting from the installation medium) which gives you a shell and evaluate the commands (evtl. you will want to mount an additional storage device to write the output of the commands to). This can be done in a short amount of time and there is nearly no risk involved, since dmraid just reads the on-disk metadata description and sets up a device mapper device. The options of the commands to be evaluated in comment #8 just query the metadata. We will need this information to understand if this is really a dmraid problem. -- 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 <oen@dsl.pipex.com> 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#c12 --- Comment #12 from David Sauve <dnsauve@gmail.com> 2007-10-23 17:34:52 MST --- I'm the other user, David (dnsauve), that had this same issue. I've been following the progress and thought it might help if I posted the results of my dmraid, so here you are: dmraid -r /dev/sda: nvidia, "nvidia_dbibcabd-0", stripe, ok, 488397166 sectors, data@ 0 /dev/sdb: nvidia, "nvidia_dbibcabd-0", stripe, ok, 488397166 sectors, data@ 0 /dev/sdc: nvidia, "nvidia_dbibcabd-1", stripe, ok, 488397166 sectors, data@ 0 /dev/sdd: nvidia, "nvidia_dbibcabd-1", stripe, ok, 488397166 sectors, data@ 0 dmraid -s *** Superset name: nvidia_dbibcabd size: 976794112 stride: 128 type: raid10 status: ok subsets: 2 devs: 4 spares: 0 Hope this information helps. It's the same results on my current 10.2 64bit system, and when I booted into the 10.3 64bit rescue system. -- 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 <oen@dsl.pipex.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|oen@dsl.pipex.com | --- Comment #13 from Occo Eric Nolf <oen@dsl.pipex.com> 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#c14 Matthias Koenig <mkoenig@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |oen@dsl.pipex.com --- Comment #14 from Matthias Koenig <mkoenig@novell.com> 2007-10-24 09:31:58 MST --- Ok, thanks. Now please try to enable the raid with dmraid: Again boot into the rescue system and evaluate dmraid -ay -p If this command succeeds there should be device-mapper devices corresponding to your RAID devices. Please provide the output of: dmsetup ls If the enabling of the raid fails for some reason, please run the first command with maximum verbosity again and provide the output: dmraid -ay -p -d -vvv -- 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 <oen@dsl.pipex.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|oen@dsl.pipex.com | --- Comment #15 from Occo Eric Nolf <oen@dsl.pipex.com> 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#c16 Jos Baudrez <jos.baudrez@telenet.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jos.baudrez@telenet.be AssignedTo|mkoenig@novell.com |jos.baudrez@telenet.be Status|NEW |ASSIGNED --- Comment #16 from Jos Baudrez <jos.baudrez@telenet.be> 2007-11-02 08:16:21 MST --- I'm also having problems with the SuSE 10.3 on my Gigaset mobo w/ nvidia raid control. Two hard-disks have been assigned to a striping raid-array. A dump of the first (MBR)-sector shows that sba has a valid partition table (ending with 55 AA hex), although fdisk sees an "invalid flag 0xffda of partition table 6", and does not recognize the boot status of sda6: /dev/sda1 * 1 18079 145219536 f W95 Ext'd (LBA) /dev/sda5 1 9 72229+ 83 Linux /dev/sda6 ? 179538 255774 612363621+ 3d Unknown The first sector of sdb does not contain a partition table (all zeroes), nor does is end with 55 AA. I suppose this has nothing to do with either SuSE or fdisk, but everything with the bios-built-in raid-configuration utility. Under SuSE 10.2 all went well and the raid array has been partitioned as proposed by the SuSE install program (well, more or less): /dev/mapper/nvidia_dbbcaejb_part5 on /boot type ext2 (rw,acl,user_xattr) /dev/mapper/nvidia_dbbcaejb_part7 on / type xfs (rw) /dev/mapper/nvidia_dbbcaejb_part8 on /home type xfs (rw) But SuSE 10.3 does not see this raid array and when examining things, I noticed the following differences (both investigations have been done, starting from the rescue-mode from the install-DVD only). dmraid -s under 10.2: *** Set name : nvidia_dbbcaejb size : 290447872 stride : 128 type : stripe status : ok subsets: 0 devs : 2 spares : 0 dmraid -s under 10.3: *** Set name : nvidia_difeadeg size : 145225984 stride : 128 type : mirror status : ok subsets: 0 devs : 2 spares : 0 dmsetup -ls under 10.2: dm version OF [16384] dm names OF [16384] nvidia_dbbcaejb_part8 (253, 4) nvidia_dbbcaejb_part7 (253, 3) nvidia_dbbcaejb_part6 (253, 2) nvidia_dbbcaejb (253, 0) nvidia_dbbcaejb_part5 (253, 1) dmsetup -ls under 10.3: dm version OF [16384] dm names OF [16384] nvidia_difeadeg (253, 0) And now for the difficult part: please, Santa, can you correct this bug - please? ;-) Jos. -- 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 <dnsauve@gmail.com> 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#c18 --- Comment #18 from Occo Eric Nolf <oen@dsl.pipex.com> 2007-11-13 10:09:55 MST --- Sorry, but I think this has become a farce by now. We're talking about a faulty installation script, making it impossible to install 10.3 on every system running on nVraid 0+1. I'm not sure how many users are hit by this, but it must be a lot more than the few posting to this thread. Yet, no reaction at all for weeks on end ... I don't think that's acceptable, the more so because all posters to this thread clearly tried to supply the developers with the information they might need. Let's face it: fakeraid is not exactly new; it has been around for years now. I know it's not ideal, but without investing in pretty expensive hardware solutions it's the only way to run dual-boot systems on raid. The 10.2 release, at last, provided installation scripts to install on fakeraid. But now, in the 10.3 release, a major step backwards is introduced: no way to install on fakeraid, and no apparent effort to change this situation. I've been running Windows and Linux on dual-boot systems for many years, due to the fact that some things are just not (yet) feasible in Linux. For instance, the lack of a macro facility as in M$ Office is not available in Linux, so unless one wants to go to great lengths to achieve the same result in Linux it makes more sense to keep a Windows installation available for specific tasks. Running 2 operating systems is not ideal, but can be done. However, the current problems with 10.3 force me to run THREE operating systems in my network: Windows, openSuse 10.3 on some machines, and 10.2 on the main system as 10.3 won't install on it. That's just too much - and downgrading the other machines to 10.2 is no option either, as that would mean returning to the 10.2 update problems which appear to have been solved in the 10.3 release. Sadly there is no alternative solution, as no other distribution seems to include decent installation scripts for fakeraid. What I never thought possible is now actually becoming reality: I'm on the brink of scrapping Linux, because by now keeping Linux systems running is taking far more time than I can afford to spend on it. 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#c19 Ulf Markwardt <ulf.markwardt@tu-dresden.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ulf.markwardt@tu-dresden.de --- Comment #19 from Ulf Markwardt <ulf.markwardt@tu-dresden.de> 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#c20 --- Comment #20 from Occo Eric Nolf <oen@dsl.pipex.com> 2007-11-23 08:02:12 MST --- Exactly 4 weeks ago I posted the requested output of dmraid commands. Since then, there has not even been an acknowledgement - let alone a solution. In fact, the only new information on this thread has been posts by other people reporting the same type of problems. Any operating system environment where critical bugs are treated in this way is not suitable for a production environment. Maybe it's fun for hobbyists, but at the moment I simply haven't got the time for it. As far as I'm concerned, feel free to ignore the dmraid problems and any other bugs you see fit to ignore. I'm no longer going to hang around till it pleases someone to do something about this particular bug. 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#c21 --- Comment #21 from Ulf Markwardt <ulf.markwardt@tu-dresden.de> 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 jsrain@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c22 Jiri Srain <jsrain@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|jos.baudrez@telenet.be |mkoenig@novell.com Status|ASSIGNED |NEW --- Comment #22 from Jiri Srain <jsrain@novell.com> 2007-12-18 04:26:58 MST --- Reassigning the bug back to Matthias (being reassigned to Jos was just an accident). -- 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 <mkoenig@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mkoenig@novell.com AssignedTo|mkoenig@novell.com |hare@novell.com --- Comment #23 from Matthias Koenig <mkoenig@novell.com> 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 hare@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c24 Hannes Reinecke <hare@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|hare@novell.com |aosthof@novell.com --- Comment #24 from Hannes Reinecke <hare@novell.com> 2008-01-24 03:38:25 MST --- Nothing to do with mkinitrd. These error have already been fixed. More an bootloader installation problem. -- 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 <jos.baudrez@telenet.be> 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 oen@dsl.pipex.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c26 --- Comment #26 from Occo Eric Nolf <oen@dsl.pipex.com> 2008-01-24 18:45:50 MST --- I'm afraid I share Jos' doubts if this bug really is eliminated. The bug description reported the problems I encountered when trying to install or upgrade 10.3 on my main system. The first error message quoted is: 'An error occurred during initrd creation.' That points to an error in the mkinitrd script - and it appears there were indeed bugs in the mkinitrd script. Hannes explained in comment #5 how to correct a bug which was reported under number 334461. Comment #6 contains my report: it did NOT fix this bug. In comment #7 Hannes raised the possibility there might be something wrong with dmraid. Since then, I (and other contributors) posted output of dmraid commands. The output of several dmraid commands in the 10.3 rescue system were NOT the same as the output of these same commands in 10.2. I just downloaded the latest version of the 10.3 KDE install CD and had another look at the output of dmraid commands in the rescue system. The output is exactly as described in comment #15 - and that means it is STILL different from the 10.2 dmraid commands. Considering all this, and taking into account Jos' observation in comment #25, I'm far from convinced that this bug has been resolved. To be quite honest: I'm fairly sure it is not. The only way for me to test my assumption would be to try a complete installation of 10.3 on my main system. That is not an option at the moment - this is a production system which can't be exposed to such a test. 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 User mkoenig@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c27 --- Comment #27 from Matthias Koenig <mkoenig@novell.com> 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#c28 --- Comment #28 from Occo Eric Nolf <oen@dsl.pipex.com> 2008-01-30 18:10:22 MST --- Against my better judgment, I tried another internet install of 10.3 64bit on my main system, running on nVraid0+1. For the result I may refer you to the bug description,submitted on 14 October 2007. After almost 40 years in computing and IT, I was fairly sure I'd seen it all. It appears I was wrong - the history of this particular bug beats just about everything I've seen. Great job! -- 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 <oen@dsl.pipex.com> 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 Alexander Osthof <aosthof@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- 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 <visnov@novell.com> 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 aj@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c30 --- Comment #30 from Andreas Jaeger <aj@novell.com> 2008-05-21 10:41:05 MST --- What is the status of this bug for openSUSE 11.0= -- 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 <oen123@gmail.com> 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 novell@nixwizard.net added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c32 Eric Gearhart <novell@nixwizard.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |novell@nixwizard.net --- Comment #32 from Eric Gearhart <novell@nixwizard.net> 2008-05-24 11:17:01 MDT --- Wow and after "almost 40 years in computing and IT" you're clearly not bitter at all! Simply because you can't get SUSE to install on a rather obscure hardware platform, you decide openSUSE's crap? Sorry for the flamebait but, wow, that's some great logic, 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=333753 User aosthof@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c33 Alexander Osthof <aosthof@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|aosthof@novell.com |jreidinger@novell.com Status|ASSIGNED |NEW --- Comment #33 from Alexander Osthof <aosthof@novell.com> 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 User jreidinger@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c34 Josef Reidinger <jreidinger@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |oen123@gmail.com --- Comment #34 from Josef Reidinger <jreidinger@novell.com> 2008-07-22 05:54:12 MDT --- OK, so this looks like finding what failed. If this still doesn't work, please provide yast2 logs (because perl-Bootloader store his logs into yast logs) and I decide what failed and who is responsible for it. ( http://en.opensuse.org/YaST/Bugs#Standard_logs ) Thanks -- 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 <jreidinger@novell.com> 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 jreidinger@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c35 Josef Reidinger <jreidinger@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED Info Provider|oen123@gmail.com | Resolution| |NORESPONSE --- Comment #35 from Josef Reidinger <jreidinger@novell.com> 2008-09-12 06:56:42 MDT --- without logs I cannot decide why perl-Bootloader cannot determine loader type. close for no response for more then a month -- 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 <oakyangnjucn@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oakyangnjucn@gmail.com --- Comment #36 from Yang Bo <oakyangnjucn@gmail.com> 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 jreidinger@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c37 Josef Reidinger <jreidinger@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|NORESPONSE | --- Comment #37 from Josef Reidinger <jreidinger@novell.com> 2009-01-06 07:29:17 MST --- OK, please attach yast logs http://en.opensuse.org/YaST/Bugs#Standard_logs -- 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 <oakyangnjucn@gmail.com> 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 jreidinger@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=333753#c39 Josef Reidinger <jreidinger@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jreidinger@novell.com AssignedTo|jreidinger@novell.com |kernel-maintainers@forge.provo.novell.com Status|REOPENED |NEW Component|Bootloader |Bootloader Product|openSUSE 10.3 |openSUSE 11.1 --- Comment #39 from Josef Reidinger <jreidinger@novell.com> 2009-01-06 07:37:49 MST --- OK, this sounds for me also as kernel problem, because it doesn't recognize previous raid. reassign -- 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 <oakyangnjucn@gmail.com> 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 Greg Kroah-Hartman <gregkh@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|kernel-maintainers@forge.pr |teheo@novell.com |ovo.novell.com | OS/Version|openSUSE 10.3 |openSUSE 11.1 -- 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 <teheo@novell.com> 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 Tejun Heo <teheo@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- 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 <teheo@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |oen123@gmail.com --- Comment #42 from Tejun Heo <teheo@novell.com> 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.
participants (1)
-
bugzilla_noreply＠novell.com