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 wal...@mfgis.com http://mfgis.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
