Bug 619806

(In reply to comment #0)

> /dev/mapper/pdc_pdc_bdgehdg_part1

just a little typo, I actually meant

/dev/mapper/pdc_bdgehdg_part1

Hi Nikolai,

  It might be the case that MD has take over the fake-raid devices by default. 
You can check that by running "cat /proc/mdstat".

  Thanks.

Hi Nikolai,

  Would you try my latest submit in Base:System ? I just fixed an ancient issue
in SuSE specific patch, which is related to this bug.

  Thanks.

(In reply to comment #2)
> Hi Nikolai,
> 
>   It might be the case that MD has take over the fake-raid devices by default.

AFAIK these are totally unrelated.
MD is linux software raid, a consistent full-fledged native solution.
DM can provide some minimal support for those proprietary legacy fake-raids, created by various firmwares.
 
> You can check that by running "cat /proc/mdstat".

Ok, I'll do this as soon as I get to that box again. 
However, if md was active then some mdX partitions would appear in /proc/partitions. But they didn't. Also, the installer didn't say anything about md, but kept talking about dm (which is correct, AFAICS)

> 
>   Thanks.

(In reply to comment #3)
> Hi Nikolai,
> 
>   Would you try my latest submit in Base:System ? I just fixed an ancient issue
> in SuSE specific patch, which is related to this bug.

1) You were right partly about md replacing fake-raid: it is apparently possible with modern intel controllers to switch to md smoothly. However, such option is irrelevant to the subject (and unavailable on non-intel raids anyway).

2) The issue is not AMD-specific: I've just reproduced it on intel ich10 (configured for raid1 in the BIOS) Same error: "formatting device mapper volume /dev/mapper/isw_...._part2 - system error code was: -3030"

3) The issue still remains in factory repo as of 1 hour ago. (I suppose your commit in question is already there)


>   Thanks.

(In reply to comment #5)
> (In reply to comment #3)
> > Hi Nikolai,
> > 
> >   Would you try my latest submit in Base:System ? I just fixed an ancient issue
> > in SuSE specific patch, which is related to this bug.
> 
> 1) You were right partly about md replacing fake-raid: it is apparently
> possible with modern intel controllers to switch to md smoothly. However, such
> option is irrelevant to the subject (and unavailable on non-intel raids
> anyway).
> 
> 2) The issue is not AMD-specific: I've just reproduced it on intel ich10
> (configured for raid1 in the BIOS) Same error: "formatting device mapper volume
> /dev/mapper/isw_...._part2 - system error code was: -3030"
> 
> 3) The issue still remains in factory repo as of 1 hour ago. (I suppose your
> commit in question is already there)

I submitted it and it was accepted 8 hours ago. However, I cannot find it yet.
Would you check if the last changelog is:

===
* 一  7月 05 2010 xwhu@novell.com
- bnc#619566, fix error in "dmsetup export" patch,
===
It works in my intel environment.

Thanks.

(In reply to comment #6)
[...] 
> I submitted it and it was accepted 8 hours ago. However, I cannot find it yet.
> Would you check if the last changelog is:
> 
> ===
> * 一  7月 05 2010 xwhu@novell.com
> - bnc#619566, fix error in "dmsetup export" patch,
> ===

Which package exactly was updated? I'm not very familiar with factory repos, I just used the online http://download.opensuse.org/factory/repo/oss/

Also, I've just noticed a similar problem mentioned in the (recently resolved) bug 598193, comment #30:
"No dm partitions had been created ..."
"installation failed with 3030 error ..."

No idea if these are really related though.

> It works in my intel environment.
> 
> Thanks.

Ok. I've just tried net install from factory again. The only difference I noticed is a long delay (several minutes maybe) before the "Preparing discs..." progress bar appears (That is, just after I confirm to proceed with formatting etc...) The error message is still the same.

Now, I switched to the terminal and typed  "dmraid -ay" (as a random guess)
After that all existing partitions wonderfully appeared.

/proc/partitions:
253 0 488383488 dm-0
253 1  10241406 dm-1
253 2   1051648 dm-2
253 3   6289408 dm-3
253 4  31455232 dm-4

/dev/mapper/:
control isw_xxx_Volume0 isw_xxx_Volume0p1 isw_xxx_Volume0p2 isw_xxx_Volume0p3 isw_xxx_Volume0p4

Note that the naming of partitions under /dev/mapper/ is not exactly the same as the installer expects ("isw_xxx_Volume0p4" vs. "isw_xxx_Volume0_part4").

So my guess is:
1) "dmraid -ay" (or equivalent) is missing in the installer somewhere.
2) The installer uses wrong naming for dm-raid partitions (*_partX instead of *pX)

YaST does a "dmraid -ay -p". The "-p" is used since udev creates the
device nodes for the partitions (at least upto RC2). And YaST uses the
correct naming for dm-raid. "dmraid -ay -p" uses the wrong.

(In reply to comment #9)
> YaST does a "dmraid -ay -p". The "-p" is used since udev creates the
> device nodes for the partitions (at least upto RC2). 

Ah, "-p" explains that. Anyway. I just tried RC2 once again carefully. At this time, before confirming formatting disks, I switched to the terminal and did the following.

- verified that NO partitions were available (under /proc/partitions and /dev/mapper/...)

- did "dmraid -ay".

- verified that all partitions appeared both under /proc/partitions and /dev/mapper/...

- manually created symlinks from /dev/mapper/isw_xxx_Volume0pX to /dev/mapper/isw_xxx_Volume0_partX to make installer happy

- returned to installer and confirmed formatting.

After that, installation went on fine and completed successfully. Upon reboot, however, the kernel complained that /dev/mapper/isw_xxx_Volume0_part4 does not exist. This wasn't already surprising though.

So, whichever naming for partions is "correct" and whoever (udev, dm) is responsible for creating them, this is broken in RC2 (and probably factory too). It still does not work.

> And YaST uses the
> correct naming for dm-raid. "dmraid -ay -p" uses the wrong.

After a bit more reading: it seems this is in fact a duplicate of Bug 598193, no?

(In reply to comment #11)
> After a bit more reading: it seems this is in fact a duplicate of Bug 598193,
> no?

Bug 598193 originally is about the udev rule to create device files for device-mapper devices.
This one, IMHO, is about the /etc/udev/rules.d/70-kpartx.rules not running correctly.

The underling reason of these issues are very different.

(In reply to comment #12)
[...]
> This one, IMHO, is about the /etc/udev/rules.d/70-kpartx.rules not running
> correctly.

Ok, do you need some more information/testing from me? 

Currently, I have a shiny new box by hand, ready for experiments. I'll do my best to help fixing this before the final release. (As otherwise I'll probably have to refrain from switching to 11.3 altogether)

(In reply to comment #13)
> (In reply to comment #12)
> [...]
> > This one, IMHO, is about the /etc/udev/rules.d/70-kpartx.rules not running
> > correctly.
> 
> Ok, do you need some more information/testing from me? 
> 
> Currently, I have a shiny new box by hand, ready for experiments. I'll do my
> best to help fixing this before the final release. (As otherwise I'll probably
> have to refrain from switching to 11.3 altogether)

Your help's really appreciated.

Could you update both udev and device-mapper from 
http://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/
and retest ?

Thanks.

(In reply to comment #14)

> Could you update both udev and device-mapper from 
> http://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/
> and retest ?

Ok. I did the following:

- Net install from factory, using regular (non-dm) hard drive.

- Verified that the problem with dmraid partitions remains. Namely, opened Yast partitioner and tried to create additional swap on dmraid partition - failure (error 3030).

- Updated packages udev, device-mapper, dmraid, multipath-tools, kpartx from Base:/System/openSUSE_Factory/

- Reboot (just in case).

- The problem disappeared. That is, Yast partitioner added new swap on dmraid partition and it was successfully formatted. Other (unused) dmraid paritions are also visible under /proc/partitions and /dev/mapper/isw_xxx_partX now. Good.

Now, how can I test that a fresh installation into dmraid partition(s) will also succeed now?

> 
> Thanks.

(In reply to comment #15)
> Now, how can I test that a fresh installation into dmraid partition(s) will
> also succeed now?

Thanks for the feedback.

With the latest release, I think this has been fixed for fresh installation.