Bug 516143

Created attachment 356603 [details]
traceback from failed install

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

anaconda 11.5.0.59 exception report
Traceback (most recent call first):
  File "/usr/lib/anaconda/storage/devicetree.py", line 892, in isIgnored
    if name.startswith("loop") or name.startswith("ram"):
  File "/usr/lib/anaconda/storage/devicetree.py", line 1148, in addUdevDevice
    if self.isIgnored(info):
  File "/usr/lib/anaconda/storage/devicetree.py", line 1691, in populate
    self.addUdevDevice(dev)
  File "/usr/lib/anaconda/storage/__init__.py", line 302, in reset
    self.devicetree.populate()
  File "/usr/lib/anaconda/storage/__init__.py", line 102, in storageInitialize
    storage.reset()
  File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 128, in gotoNext
    self.moveStep()
  File "/usr/lib/anaconda/text.py", line 712, in run
    anaconda.dispatch.gotoNext()
  File "/usr/bin/anaconda", line 964, in <module>
    anaconda.intf.run(anaconda)
AttributeError: 'list' object has no attribute 'startswith'

This is caused by:

info: {'symlinks': ['block/253:0', 'disk/by-id/dm-name-ddf1_Disk', '2'], 'DM_TABLES_LOADED': 'Live', 'DM_NAME': ['ddf1_Disk', '2'], 'DM_MAJOR': '253', 'name': 'dm-0', 'ANACBIN': '/usr/sbin', 'DEVTYPE': 'disk', 'MAJOR': '253', 'DM_SUSPENDED': 'Active', 'sysfs_path': '/devices/virtual/block/dm-0', 'DM_READONLY': 'Writeable', 'DM_OPEN': '0', 'MINOR': '0', 'DM_MINOR': '0'}

Note that DM_NAME is a list.

Can you switch to tty2 and run:  udevadm info --export-db | less, then search for "dm-name-ddf1_Disk 2" and see what block of information udev provides?  I'm curious how udev is encoding spaces here, if at all.

I *think* I've captured what you're asking for in the jpg file I just attached. Let me know if I've not. I can give you access to the box if you'd like a direct connection to it.

-Gary

Created attachment 356734 [details]
jpg of udev output

As you can see from the DEVLINKS: and S: sections in the attached screenshot, there's no special escaping of spaces.  Since anaconda uses this output to construct its own view of the disks, there's really nothing anaconda can do right now.  We'd need to see the spaces escaped before we could tweak our udev-using code to preserve the spaces.

Okay, so what's the next step? This machine installs without incident using RHEL5, so something must have changed between 5 and 6.

Well, then fix you rules
/lib/udev/rules.d/70-anaconda.rules:SYMLINK+="disk/by-id/dm-name-$env{DM_NAME}"

(In reply to comment #9)
> Okay, so what's the next step? This machine installs without incident using
> RHEL5, so something must have changed between 5 and 6.  

Yes. The set of changes is indeed massive. The entire storage detection and configuration portion of anaconda was rewritten from scratch.


(In reply to comment #10)
> Well, then fix you rules
> /lib/udev/rules.d/70-anaconda.rules:SYMLINK+="disk/by-id/dm-name-$env{DM_NAME}"  

The same rule exists in 13-dm-disk.rules from device-mapper-1.02.40. I am in the process of removing it from anaconda's rules, along with most of the device-mapper-specific rules.

Is this problem fixed in the most recent RHEL-6 nightly tree?  (anaconda-13.21.3-1 or later)

It's still throwing an error using the 20100125.0 install tree with no tweaks or adjustments. I'm attaching a png of the errors.

Created attachment 386677 [details]
RHEL6 anaconda traceback from 20100125.0 tree

Your most recent failure was bug 558534, which is verified fixed in RHEL6.0-20100201.4.

Please retest with a newer tree.

Tried with RHEL6.0-20100209.1 tree. Now I'm having a different problem. I'll explain it and then you can tell me whether to open another ticket or not.

I started the install and reached the GUI installer screen where I was choosing the disk to install to. I was only shown one disk, but there are two in the system. Clicking the "select all disks" button gave me the message "2 devices selected out of 1 device total" (attached 2-device.png). When I clicked Next, anaconda generated a traceback (attached traceback.txt).

Created attachment 390113 [details]
Disk selection screen with only one disk shown (and two disks available?)

Created attachment 390114 [details]
Anaconda traceback from RHEL6.0-20100209.1 tree

Either dmsetup or udev is getting confused into thinking that /dev/2 is an acceptable name for these devices. The result is that the name attribute points to a list of names instead of a single string, unlike every other device anaconda has encountered since F11.

If you know how to activate this array from the command line during install, I would be interested to see the output of the following commands once the device is active (as /dev/dm-0):

  cat /sys/class/block/dm-0/dm/name
  dmsetup info -c  --nameprefixes --unquoted --rows --noheadings -o name,uuid,major,minor -j253 -m0

If you don't know how to activate the array, let me know -- I'll help you figure it out.

I honestly have no idea how to activate the array. AFAIK, it's just two disks. That's what I see in RHEL5, two hard drives. And fdisk -l shows two drives as well, in the RHEL6 installer.

Interestingly enough, RHEL6 doesn't have a /dev/sda. Just /dev/sdb and /dev/sdc on fdisk -l command.

I just confirmed in the SAS controller that these are not in any kind of controller-based array. It's one SAS disk and one SATA disk on a blade.

sda is a virtual floppy, which is why it doesn't appear in fdisk output.

sdb is a regular disk.

sdc is identified by blkid as being a ddf (bios)raid member. The array's name is "ddf1_Disk 2". The space is the source of our problems.

Is it expected that sdc be part of a one-member raid array, or is blkid at fault for mis-identifying it?

Can you run 'parted -l' on tty2 in the installer and attach the output here?


Hans, this exotic hardware stuff is more your cup of tea, so I'm reassigning it to you.

I'm attaching the output you've requested. It's a .png as this is a blade and all activity is occurring through iLOM.

Created attachment 390562 [details]
parted -l output from installer

Hi Gary,

So the problem is there is a space in the dmname for the device, which
is confusing pyudev.py, this has been fixed in the master branch by the following 2 commits:

http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=f6360c2798c8b3d5d0380ca9a8ae743c5e80f640
http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=6217d83bb4958e31142e16b95387f8f0f8bb3761

I've made an updates.img for the RHEL-6 nightlies with these fixes in there:
http://people.fedoraproject.org/~jwrdegoede/updates-rh516143.img

Gary, can you please try to install a recent nightly with this updates.img,

Thanks,

Hans

Hans,

I'm pretty sure I did this right, but I don't think the updates.img is working. I used the boot time option "anaconda updates=http://web.server.ip.addr/updates.img" and saw it retrieve the updates.img file from my server as part of the install. However, when I clicked through to the disk screen, I only saw the USB attached floppy drive and one of the two HDs. I'm still able to generate the "n+1 out of n possible disks selected" notification.

-Gary

Gary,

I've just tried to reproduce this by creating a BIOS RAID set with a space in its name in my BIOS RAID test machine, which luckily allowed me to do that.

I can reproduce the original crash you are seeing caused by the space in the name, but not the "n+1 out of n possible disks selected" thingie, so I think the
2 are unrelated.

Can you please proceed with the install (with my updates.img) as far as possible and then attach the logfiles under /tmp to this bug ?

Thanks,

Hans

Hans,

I was able to perform a complete install, using the only disk (ignore the floppy I have attached) I could see on the disk selection screen. I did get an error after selecting it, but I was able to continue after initialization. I'm attaching a screenshot of the error (inst-error.png) as well as all the logfiles from /tmp that I captured when the system was at the reboot screen.

Created attachment 394979 [details]
Error that appears after selecting install disk

Created attachment 394980 [details]
Logfiles from successful install on one disk

Hi,

(In reply to comment #29)
> Hans,
> 
> I was able to perform a complete install, using the only disk (ignore the
> floppy I have attached) I could see on the disk selection screen. I did get an
> error after selecting it, but I was able to continue after initialization.

That is not really an error, but a normal message when installing onto a fresh disk.

So with the backtrace fixed (the cause of the backtrace is tracked in bug 560262), that only leaves the "n+1 out of n possible disks selected" thingie.

I'm changing the summary to reflect this. Chris as this is a filter UI issue I'm assigning this to you.

Regards,

Hans

anaconda-13.35-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/anaconda-13.35-1.fc13

anaconda-13.35-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

The system's in use by someone now, but I'll get it as soon as I can. Am I correct in thinking that all I need to do is start an install, and that I don't have to make any actual changes to the system to see if the N+1 problem has been fixed?

Hi Gary,
just do an install like you did before (same disk selection, partitioning layout, etc.) and if there is no traceback such as in comment #1 then it's fixed.

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.