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?
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?