I have been experiencing the exact same issue. In order to complete the installation, I physically remove and disable the additional "SCSI" drives, and only then can I install Ubuntu. Then comes the job of putting everything back in, and thankfully, the first boot then completes without any issues, all drives are mounted and visible, and life is good from then on. It's only the installation and specification of the drives (and mounts) which causes grief.
My configuration: (for a MythTV/RAID/Ubuntu box - Using Mythbuntu)
ASUS P4B533-E / 2Gb / P4 2.8GHz
- Onboard Standard PATA (3 Drives + DVD R/W 2nd/Slave)
- Onboard Promise FastTrack 133 RAID PATA (4 Drives - Used in s/w RAID5)
- PCI Promise Ultra TX/100 PATA (4 Drives - Used in s/w RAID5)
Boot in BIOS is set to Onboard PATA first. Drives are in order: 160Gb (Boot), 300Gb (Storage), 40Gb (Windoz XP), DVD R/W
Trying to install Ubuntu on the 160Gb drive I experience the GRUB issues:
1). With all drives in the machine, the boot drive is recognized as /dev/sdi, and not /dev/sda (as might be expected). No success ever getting GRUB to work through the installer. Specifying explicitly the drive to install on will not work.
2). Removing the drives, but leaving the BIOS (both Onboard and TX/100 enabled) also leads to failure, even though drive is "correctly" detected as /dev/sda. Alone the presence of the controllers / BIOS causes the GRUB failure.
3). Only when removing all drives, physically removing the TX/100, and disabling the onboard RAID BIOS will GRUB be able to successfully install. This is akin to changing the entire machine in order to get things to install - although Ubuntu has no problems afterwards using the drives/controllers/hardware/etc.
After this, one other 'odd' thing ... the only way I'm able to successfully (or properly) mount drives (/etc/fstab) is to always use the GUID methodology. This works reliably. Specifying /dev/sdaX does not work, and leads to the incorrect drive being mapped to the mount point each and every time. The drives swap ordering if specified in /etc/fstab. Very frustrating and odd.
Annoying that the full install can complete, and then it fails writing the GRUB boot ... *sigh*
I have been experiencing the exact same issue. In order to complete the installation, I physically remove and disable the additional "SCSI" drives, and only then can I install Ubuntu. Then comes the job of putting everything back in, and thankfully, the first boot then completes without any issues, all drives are mounted and visible, and life is good from then on. It's only the installation and specification of the drives (and mounts) which causes grief.
My configuration: (for a MythTV/RAID/Ubuntu box - Using Mythbuntu)
ASUS P4B533-E / 2Gb / P4 2.8GHz
- Onboard Standard PATA (3 Drives + DVD R/W 2nd/Slave)
- Onboard Promise FastTrack 133 RAID PATA (4 Drives - Used in s/w RAID5)
- PCI Promise Ultra TX/100 PATA (4 Drives - Used in s/w RAID5)
Boot in BIOS is set to Onboard PATA first. Drives are in order: 160Gb (Boot), 300Gb (Storage), 40Gb (Windoz XP), DVD R/W
Trying to install Ubuntu on the 160Gb drive I experience the GRUB issues:
1). With all drives in the machine, the boot drive is recognized as /dev/sdi, and not /dev/sda (as might be expected). No success ever getting GRUB to work through the installer. Specifying explicitly the drive to install on will not work. controllers/ hardware/ etc.
2). Removing the drives, but leaving the BIOS (both Onboard and TX/100 enabled) also leads to failure, even though drive is "correctly" detected as /dev/sda. Alone the presence of the controllers / BIOS causes the GRUB failure.
3). Only when removing all drives, physically removing the TX/100, and disabling the onboard RAID BIOS will GRUB be able to successfully install. This is akin to changing the entire machine in order to get things to install - although Ubuntu has no problems afterwards using the drives/
After this, one other 'odd' thing ... the only way I'm able to successfully (or properly) mount drives (/etc/fstab) is to always use the GUID methodology. This works reliably. Specifying /dev/sdaX does not work, and leads to the incorrect drive being mapped to the mount point each and every time. The drives swap ordering if specified in /etc/fstab. Very frustrating and odd.
Annoying that the full install can complete, and then it fails writing the GRUB boot ... *sigh*