Re: how to use promise fastTrak 378 with IDE disks?
On Sat, 2008-03-22 at 16:08 +0100, Florian Kulzer wrote:
> On Sat, Mar 22, 2008 at 10:29:50 +0000, michael wrote:
> > On 21 Mar 2008, at 19:48, Florian Kulzer wrote:
> >> On Fri, Mar 21, 2008 at 19:08:20 +0000, michael wrote:
> >>> On 21 Mar 2008, at 17:36, Florian Kulzer wrote:
> >> [...]
> >>>>>>>> On Thu, Mar 20, 2008 at 20:33:50 +0000, michael wrote:
> >>>>>>>>> I've a Asus A8V mobo which has a Promise FastTrak 378
> >>>>>>>>> controller,
> >>>>>>>>> nominally for RAID but I can set it to 'IDE mode' in the
> >>>>>>>>> BIOS.
> >> [...]
> >>>> Did you try to boot your system with the controller set to normal
> >>>> operation (i.e. not IDE-mode) in the BIOS?
> >> [...]
> >>> it fell over at the Grub loading stage
> >> I think that might mean that the system recognized the FastTrak-
> >> attached
> >> drive(s) and tried to boot from it/them. It is, however, not clear to
> >> me
> >> whether it would see two separate drives under these conditions or one
> >> drive with hardware RAID working.
> >> If you want to investigate this further then you probably have to
> >> switch
> >> your entire setup to using partition labels or UUIDs, to be imune to
> >> the
> >> effects of /dev/hd? reshuffling (or try a liveCD as I suggested
> >> earlier).
> > I'll try (later this w/end) the LiveCD - the idea being that it may have
> > more (modern?) drivers and thus deal with it?
> Yes, and that it will always boot from the CD, irrespective of how many
> drives are recognized for given BIOS setting. It seems to me that the
> drive(s) attached to the promise controller were recognized in your last
> experiment, but this unfortunately meant that Grub saw a different order
> of drives, therefore it did not know where to find your root partition
> To illustrate this more concretely, let's say that your root partition
> is on the first partition of the first hard disk. This normally means
> that GRUB was installed on the master boot record of this drive and that
> GRUB is configured to look for the /boot/grub directory on "(hd0,0)" to
> bring up the system. (GRUB counts from zero, so "0,0" is "first drive,
> first partition".) Everything worked fine, until you changed the BIOS
> setting and the FastTrak-attached drives were suddenly recognized. The
> Promise controller has a lower PCI address than the VIA controller; this
> gives you a new "(hd0)" and the disk with your root partition is now
> "(hd1)" or even "(hd2)". The BIOS will normally still find the old MBR,
> simply because it can try all attached drives until it comes across one
> that can boot at all, but GRUB gets lost looking for /boot/grub on the
> new "(hd0,0)", especially if the new drive has not even been partitioned
> This means that you will have to reconfigure GRUB in the long run, but
> right now a liveCD is probably the quickest means to see what exactly is
> going on and what is possible at all. (You can also enter the correct
> new root designation directly at the GRUB prompt, but the liveCD has
> indeed the added benefit of showing you if things improve with a newer
I think this article sums up the probs I've been seeing:
Indeed if I book from GPARTed 0.3.4-8 liveCD it states "sata_promise
PATA port found" and shows me the disks (albeit as sda, sdb)... so maybe
that uses a patched sata_promise module?
I also see that Ubuntu are (if I read it right) going to include PATA
support for sata_promise:
http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-source-2.6.20/linux-source-2.6.20_2.6.20-15.27/changelog (search for sata_promise eg at section: "linux-source-2.6.20 (2.6.20-8.14) feisty; urgency=low")
So perhaps Debian will ship a kernel with PATA support in sata_promise??