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 > anymore. > > 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 > yet. > > 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 > kernel.) >
I think this article sums up the probs I've been seeing: http://www.linuxquestions.org/questions/linux-hardware-18/solution-for-promise-fasttrack-pdc20378-pata-or-raid-with-2.6.17-kernel-478926/ 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?? M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
