[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#440161: wrong /etc/fstab when installing on RAID using Adaptec 2100S



Jérémy Bobbio schrieb am 05.09.2007 22:50 Uhr:
Just boot on the mini.iso [1] after burning it.  It will download all
the necessary components of the debian-installer through the network and
proceed the installation as you would expect.

[1] http://people.debian.org/~joeyh/d-i/images/20070905-09:01/netboot/mini.iso
Interesting.

Using

http://people.debian.org/~joeyh/d-i/images/20070906-09:01/netboot/mini.iso with "expert" install, everything works fine. I created /dev/sda1 using ext3 for /, choosed "stable" to be installed and did not install any additional software (like "desktop system" or "standard system").
Rebooting without errors.

But:
modules loaded are
i2o_core
dpt_i2o
scsi_mod
sd_mod


Not i2o_core and i2o_block like before.

Then i tried a etch netinstall iso dated from 07-02-15, same install parameters.
Reboot and

modules loaded
i2o_core
i2o_block
and /dev/sda1 is "getting renamed to" /dev/i2o/hda1 (this is displayed when i2o_block is being loaded).
Boot sequence stopps saying "Waiting for root filesystem..."

So it looks like there are differencies in deciding what modules are being loaded for i2o-hardware.

Etch uses i2o_core/i2o_block, current d-i build uses dpt_i2o.

Dont really know which is bette, but i2o_core/i2o_block seems newer, faster and smaller than dpt_i2o, and supports 64bit what dpt_i2o doesn't do.
It's hardware-independant while dpt_i2o is only usable for Adaptec controllers.

Did this help?

IMHO it would be better to support i2o-subsystem (i2o_core, i2o_block and so on) instead of dpt_i2o if an Adaptec controller is found on the system.




Reply to: