FL6 hangs after install on STL2 board using Adaptec 2100S in RAID-1

Perhaps we're forgetting to copy the relevant module for this I2O controller into the initramfs?

Rejecting useless second task - don't worry, bug is still open

I can confirm this behaviour on a Fujitsu-Siemens Primergy Dual Xeon System with I2O: Adaptec (formerly DPT) SmartRAID V Controller (rev 02)

It boots 2.6.15-19-386 - single processor

We had no luck with
2.6.15-19-686 screenshot: http://anti.staff.spin.de/DSC00173.JPG
2.6.15-19-server (same)
2.6.15-20 (same)

Breezy oopses when booting the install CD

Since various sources suggested there may be a conflict between 2 kinds of i2o-modules in the kernel in SMP environments, I modified the initrd to include a "blacklist dpt_i2o" in /etc/modprobe.d/blacklist.

Now the kernel boots and seems to work ok, using only the i2o_core module.

What I did boils down to:

# zcat /boot/initrd.img-2.6.15-20-686 | cpio -idvm
# echo "blacklist dpt_i2o" >> etc/modprobe.d/blacklist
# find . | cpio --quiet -o -H newc | gzip -9 > /boot/initrd.img-2.6.15-20-686

(in an empty directory, first backing up the initrd, ...)

Andi, it happens with the 386 kernel - the one that gets installed by default by FL6. Initially, only one processor is showing.
For now, I removed the I2O controller - because it seems that even SUSE 10 has issues (actually, the only distribution that handles it correctly seems to be Mandriva 2006).
I will wait until there is a formal bugfix, then I could try again.

If you were able to install it, the kernel on CD did boot, right? And the one on the live CD? That's -386. The one installed by default (at least on my ubuntu-server/FL6) is -686.

On a side note, I just read in https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/24050 Ben Collins said this or some very similar bug was fixed in 2.6.15-9 - maybe this slipped in again, somehow?

Of course you are right to wait for a real fix of this bug - I just wanted to show the workaround to shed some light on the bug, and maybe point someone in the right direction.

I subscribed Ben Collins to this bug, I think he may want to decide if this is a duplicate / regression of 24050. :-)

What drive is hda? Are there any other drives in the system other than the i2o one?

Note that Tollef, when doing a test install on a similar system recently, noted on IRC that "hey, i2o stuff just shows up as plain SCSI now, cool, no more weird paths". And the screenshot above seems to back that assertion up.

If this is a case of module load order affecting what the device is named, that's pretty harsh, especially if we're shipping to sets of driver that "do the right thing" on this hardware, but do it differently.

I'm having the same problem installing FL6 for a Dell Dimension XPS T600 with 2 x 18 Gb SCSI disks using Adaptec 2100S I2O SCSI controller in RAID-1.

There are no other drives on the system other than the i2o one.

After reboot, final screen looks the same as the one above posted by Andi Hechtbauer.

* Adam Conrad

| Note that Tollef, when doing a test install on a similar system
| recently, noted on IRC that "hey, i2o stuff just shows up as plain
| SCSI now, cool, no more weird paths". And the screenshot above
| seems to back that assertion up.

Note that this was with the dpt_i2o driver which seems to use sd_mod
to publish its block devices. i2o_block still gives me /dev/i2o/hda
(etc).

--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
                                                                      `. `'
                                                                        `-

Ben Collins asked:

> What drive is hda? Are there any other drives in the system
> other than the i2o one?

/dev/i2o/hda is the only drive in the system (well, there is hdc, a cd-rom), it is configured as raid 1 iirc (can't look at it right now)

I'm getting the exact same screen as Andi originally posted.

I'll give his workaround a try when i get home this evening

It gets worse. I disconnected all HDDs from the 2100s, I removed the card from the server, I connected them to the onboard SCSI adapter - Ubuntu 5.10 installs fine & works.

I then re-inserted the 2100s (without any HDD connected to it) - Boom - crash at startup.

It cannot digest it at all, even without any HDD connected to it.

The screenshot in http://anti.staff.spin.de/DSC00173.JPG seems to show the i2o device being correctly detected, but the expected /dev/i2o/hda2 device not being created.

Andi Hechtbauer, if you look around in the busybox shell there, is there anything under /dev/i2o at all?

Actually Matt, the screenshot seems to show sda1 being detected -- which fits with Adam's belief that i2o drives now appear under the scsi subsystem (which is the general pattern the kernel is moving towards anyway).

Try doing this at that shell:

  mkdir /dev/i2o
  ln -s /dev/sda2 /dev/i2o/hda2
  exit

and see if that boots as you expected

Matt, I don't have the system at my hands atm - can't look, sorry; perhaps the OP or someone having the same problem may want to try what you and Scott are suggesting.

Talking with Tollef again, he says this is a difference between dpt_i2o and i2o_block, the former creates SCSI devices and the latter /dev/i2o ones.

The quick solution to this is to blacklist dpt_i2o apparently, and let i2o_block take care of that interface.

I have a similar machine which doesn't have any IDE hard drives, only an IDE CD-ROM drive and 3 SCSI drives connected to a Adaptec AHA-2940U2/U2W in hardware RAID5 configuration.

I think I'm experiencing the same problem.

Ubuntu 5.10 installer crashes on that machine (see Bug #46420).

Dapper daily install CD (alternative install) from yesterday (2006-05-29) installs fine on this machine, but when I boot into the freshly installed system, I get the error:

"Uncompressing Linux... Ok, booting the kernel.
[4294706.598000] iop0: device already claimed
[4294706.652000] iop0: DMA / IO allocation for I2O controller failed
ALERT! /dev/i2o/hda3 does not exist. Dropping to a shell!"

The grub command line for the kernel is:

kernel /vmlinuz-2.6.15-23-386 root=/dev/i2o/hda3 ro quiet splash

Grepping in /proc/modules reveals that the loaded i2o modules are dpt_i2o and i2o_core:

i2o_core 41112 0 - Live 0xe086d000
dpt_i2o 33308 0 - Live 0xe08e9000
scsi_mod 139496 4 sd_mod,dpt_i2o,aic7xxx,scsi_transport_spi2, Live 0xe08bb000

I've tried the workaround suggested by James Remnant and it works, the system continues booting:

mkdir /dev/i2o
ln -s /dev/sda /dev/i2o/hda
ln -s /dev/sda1 /dev/i2o/hda1
ln -s /dev/sda2 /dev/i2o/hda2
ln -s /dev/sda3 /dev/i2o/hda3
ln -s /dev/sda5 /dev/i2o/hda5
exit
 * Reading files needed to boot... [ ok ]
 * Preparing restricted drivers... [ ok ]
 * Starting basic networking... [ ok ]
 * Starting kernel event manager... [ ok ]
 * Loading hardware drivers... [ ok ]
...

So the problem is indeed with inconsistency in device naming between drivers (/dev/sda by dpt_i2o and /dev/i2o/hda by the other one).

I did what Andi Hechtbauer suggested and blacklisted the dpt_i2o module in my custom initrd. Now Ubuntu boots fine on this machine.

So here comes a question: is it OK to simply blacklist dpt_i2o for everyone, everywhere?
Is there some hardware that isn't supported by i2o_block, for which dpt_i2o would be required?

Or maybe it would be better to do the opposite, and head in the same direction that kernel developers are (eliminating strange device names like /dev/i2o/hdX), and choose the SCSI naming of devices (/dev/sdX)? Would it be accomplished by blacklisting i2o_block module both in installer and working initrd and system?
Is there some hardware that isn't supported by dpt_i2o, for which i2o_block would be still required?

I think the second option would be more correct and future-proof (but it's just my HO).

The status of this bug is "Needs Info" - what more information can we provide as testers?

Oops, it's 2 hours left till release...

It's too late to fix this bug, we're all doomed...

We can't blacklist i2o_block since it's the "general" module which is needed for a bunch of adapters. Where dpt_i2o works, it's preferable to i2o_block (since it gives you more features). I'm wondering if we should do a small hack in d-i to make it blacklist the module not used by the installer to prevent this problem.

> I'm wondering if we should do a small hack in d-i to make it blacklist the module
> not used by the installer to prevent this problem.

You mean blacklist the module in installed system, if it hasn't been used by the installer deliberately (provided that the installer has found an alternative module for given device)?

this bug is still existing..
i tried to install the last ubuntu 6.06 LTS server

initrd.img-2.6.15-26-server

moreover, the hint suggested.. |cpio...
can't be used cpio is not a command of the reduced shell (busybox) in which we arrive after the reboot.

what should we do to unload the unneeded module and go on booting ?

In order to work around this problem you need to go through these steps:

1) At the busybox type:

mkdir /dev/i2o
ln -s /dev/sda /dev/i2o/hda
ln -s /dev/sda1 /dev/i2o/hda1
ln -s /dev/sda2 /dev/i2o/hda2
ln -s /dev/sda3 /dev/i2o/hda3
(go on until you linked all your devices)
exit

2) Now your server should continue the boot process; as soon as you get the prompt fix the problem blacklisting the module in the initrd image: for example:

mkdir initrd
cd initrd
zcat /boot/initrd.img-2.6.15-28-server | cpio -ivdm
echo "blacklist dpt_i2o" >> etc/modprobe.d/blacklist
find . | cpio --quiet -o -H newc | gzip -9 > /boot/initrd.img-2.6.15-28-server

One quick note to the kernel team:
Do you think that this problem could be fixed in a future upgrade? It is a bit annoying...