Bug 468850

Created attachment 321693 [details]
Attached traceback automatically from anaconda.

Problem seems to be too many drives in the drive list:

12:11:11 DEBUG   : self.driveList(): ['sda', 'ram0', 'ram1', 'ram2', 'ram3', 'ram4', 'ram5', 'ram6', 'ram7', 'ram8', 'ram9', 'loop0', 'loop1', 'loop2', 'loop3', 'loop4', 'loop5', 'loop6', 'loop7', 'ram10', 'ram11', 'ram12', 'ram13', 'ram14', 'ram15']

Instead of:

13:04:08 DEBUG   : self.driveList(): ['sda']

Anaconda from October 28th rawhide asked if I wanted to initialize ram[0-15] and loop[0-5] devices.  I clicked No to all prompts and it seems to be able to proceed.

This is because those devices have started showing up in hal where they didn't before.  It seems to me they shouldn't be showing up as disks in hal, but I guess if we have to, we can filter them out :/

Richard, David?

Matthias mentioned this to me just now. I can't reproduce on a 2.6.27.4-51.fc10.i686 kernel, but I've got the lshal from him. It contains tons of stuff like this:

udi = '/org/freedesktop/Hal/devices/computer_storage_bdi_disk_6'
  block.device = '/dev/loop7'  (string)
  block.is_volume = false  (bool)
  block.major = 7  (0x7)  (int)
  block.minor = 7  (0x7)  (int)
  block.storage_device = '/org/freedesktop/Hal/devices/computer_storage_bdi_disk_6'  (string)
  info.capabilities = {'storage', 'block'} (string list)
  info.category = 'storage'  (string)
  info.parent = '/org/freedesktop/Hal/devices/computer_bdi_7_7'  (string)
  info.udi = '/org/freedesktop/Hal/devices/computer_storage_bdi_disk_6'  (string)
  linux.hotplug_type = 3  (0x3)  (int)
  linux.sysfs_path = '/sys/devices/virtual/block/loop7'  (string)
  storage.automount_enabled_hint = true  (bool)
  storage.bus = 'bdi'  (string)
  storage.drive_type = 'disk'  (string)
  storage.hotpluggable = false  (bool)
  storage.media_check_enabled = false  (bool)
  storage.model = ''  (string)
  storage.no_partitions_hint = false  (bool)
  storage.originating_device = '/org/freedesktop/Hal/devices/computer'  (string)
  storage.partitioning_scheme = 'none'  (string)
  storage.removable = false  (bool)
  storage.removable.media_available = true  (bool)
  storage.removable.media_size = 0  (0x0)  (uint64)
  storage.requires_eject = false  (bool)
  storage.size = 0  (0x0)  (uint64)
  storage.vendor = ''  (string)

The kernel is telling us / hal is probing this, and then we get a "block" device that doesn't exist. I don't know enough about BDI to tell you what the problem is. I'll have a try.

Can you try http://koji.fedoraproject.org/koji/taskinfo?taskID=909916 please.

Er, it's tricky to inject that into an anaconda image, but as I understand the problem:

* Current Rawhide systems have HAL entries for /dev/{loop,ram}X.
  - This is true on my current Rawhide machines.
* This is confusing Anaconda into thinking they're valid storage devices.
* This HAL update is intended to fix that by not listing /dev/{loop,ram}X.

If I've understood the problem and intended solution correctly, then yes - that hal build works.

It looks like it should from a quick check of downloading and running on my system normally.  Can you request the tag for dist-f10 and then we can be certain with tomorrow's rawhide?

https://fedorahosted.org/rel-eng/ticket/891  requested for tagging.

It's been tagged, and will need re-testing with tomorrow's rawhide.

*** Bug 468957 has been marked as a duplicate of this bug. ***

*** Bug 469122 has been marked as a duplicate of this bug. ***

*** Bug 469149 has been marked as a duplicate of this bug. ***

Works for me.