Bug#489778: Bug 489778: More ... it is clearly pointing to an i2o issue
Here is more information
The most important info is right here, quoted from #2 below:
[quote]
There are 2 drivers in the kernel for the Adaptec RAID card: dpt_i2o and
i2o_block. If dpti2o is used, the card is seen as "/dev/sda" (ie, a scsi
device). If i2o_block is used, it is seen as "/dev/i2o/hda" (ie an i2o
device). For some reason, the install CD loads the i2o_block module, and
thus installs the OS to "/dev/i2o/hda". However, when the system boots the
installed OS, since it, by default, loads "most" drivers, it loads both
drivers, beginning in alphabetical order with "dpt_i2o". So, since dpt_i2o
is loaded, i2o_block cannot be loaded afterwards (since the device is
already controlled by dpt_i2o), and thus the installed OS looks for
"/dev/i2o/hda" but cannot find it, because the system only knows
"/dev/sda".
Suggested fix:
1. Either the install CD should be told to use the dpt_i2o driver, or;
2. The installed OS should *not* load the dpt_i2o driver.
[/quote]
===================================================================
>From an ETCH user who worked around the problem:
http://lists2.ssc.com/pipermail/linux-list/2007-August/029123.html
[quote]
(This started out as a request for assistance and is now more of a
report of solution.)
Overview:
New Debian Etch installation cannot mount root file system
after reboot. Solved that by referring to fs by UUID
instead of device name. How to do similar for swap partition?
Discovered that I2O RAID creates devices /dev/i2o/*.
Details:
I'm installing Debian Etch i386 using the netinst CD, performing
the following:
Create a single RAID-5 array in the Adaptec 2100S SCSI controller
BIOS using all the discs in the system (all SCSI, no ATA).
Boot from the installation CD.
Follow all the steps up to partitioning (nothing unusual
configured).
Create four primary partitions on sda:
sda1: ext3 root
sda2: unused
sda3: LVM physical volume
sda4: swap
Create one VG using the entire PV.
Create one LV each for /home, /tmp, /usr, /usr/local, /var, and
/var/log, create an ext3 file system on each, and configure them
to mount in the appropriate locations. I symlink /opt to /usr/opt.
Follow more installer steps with no unusual configuration.
At the tasksel step, select only "standard system".
Install GRUB and finish.
While booting into the new system, after lots of boot messages, I
see the following:
> block-osm: registered device at major 80
> i20/hda i2o/hda1 i2o/hda2 i2o/hda3 i2o/hda4
[note hda here instead of sda; why?]
> block-osm: device added (TID: 20d): i2o/hda
> Done.
> Begin: Mounting root file system... ...
> Begin: Running /scripts/local/top ...
> device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialized: dm-devwel at
redhat.com
> Done.
> Begin: Waiting for root file system... ...
[hangs here for about five minutes]
> Done
> Check root=bootarg cat /proc/cmdline
> or missing modules, devices: cat /proc/modules ls /dev
> ALERT! /dev/sda1 does not exist. Dropping to a shell!
/proc/cmdline contains "root=/dev/sda1 ro".
/proc/modules shows the following modules along with some numbers
that I haven't transcribed:
dm_mirror
dm_snapshot
dm_mod dm_mirror,dm_snapshot
ide_generic
i2o_block
scsi_mod
ide_cd
cdrom ide_cd
e100
mii
i2o_core i2o_block
uhci_hcd
usbcore uhci_hcd
piix
generic
ide_core ide_generic,ide_cd,piix,generic
thermal
processor thermal
fan
I searched the Web for the "waiting for root file system" message
and found some clues dealing with initramfs-tools and udev. Using
the installation CD's rescue mode, I've upgraded initramfs-tools
from version 0.85g to 0.85h, and then replaced it with yaird. I
upgraded the kernel from version 2.6.18-4-686 to 2.6.18-5-686. No
improvements. I switched back from yaird to initramfs-tools.
Then I read something about referring to the root file system in
GRUB configuration and fstab using UUID instead of /dev/whatever.
I used e2fsdump to find the UUID for the file system on /dev/sda1,
changed /boot/grub/menu.conf and /etc/fstab to use it, rebooted,
and it booted all the way, but the swap partition was not
activated.
Now when I show mounted file systems, the root system is listed as
/dev/i2o/hda1.
I edited fstab to refer to the swap partition as /dev/i2o/hda4,
and now that works.
How can I avoid this mess when installing in the future?
Any pointers to dealing with I2O SCSI RAID controllers (which
apparently refers to more than just Adaptec's) in Debian,
particularly during installation? I found the raidutils package,
but it comes with zero documentation other than the built-in
command line reference. I found this FAQ, which is somewhat
helpful:
<http://i2o.shadowconnect.com/faq.php>
--
Phil Mocek
[/quote]
==================================================================
>From an Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/52956
Problem:
Installing Dapper Server on a system with an Adaptec RAID 2010S card
installs correctly, but when the system reboots to the installed OS, the
kernel cannot find the RAID card, and thus, fails to find the hard drive.
Cause:
There are 2 drivers in the kernel for the Adaptec RAID card: dpt_i2o and
i2o_block. If dpti2o is used, the card is seen as "/dev/sda" (ie, a scsi
device). If i2o_block is used, it is seen as "/dev/i2o/hda" (ie an i2o
device). For some reason, the install CD loads the i2o_block module, and
thus installs the OS to "/dev/i2o/hda". However, when the system boots the
installed OS, since it, by default, loads "most" drivers, it loads both
drivers, beginning in alphabetical order with "dpt_i2o". So, since dpt_i2o
is loaded, i2o_block cannot be loaded afterwards (since the device is
already controlled by dpt_i2o), and thus the installed OS looks for
"/dev/i2o/hda" but cannot find it, because the system only knows
"/dev/sda".
Steps to reproduce:
1. Install dapper server to a system with hardware RAID and an Adaptec
2010S raid card.
2. Install should complete normally, but upon reboot you will get errors
about how the device is already claimed by another driver and the boot
will fail and drop you into the initramfs shell. From there, an "lsmod"
will show that the dpt_i2o module is loaded and not i2o_block.
Suggested fix:
1. Either the install CD should be told to use the dpt_i2o driver, or;
2. The installed OS should *not* load the dpt_i2o driver.
[/quote]
--
Steve Walker
Middle Fork Geographic Information Services
360.671.2505
walker@mfgis.com
http://mfgis.com
Reply to: