Just joined the forum and noticed in that thread an issue with Vista & linux in a dual disk configuration. Now when I worked through this, I left the Vista disk alone, and switched cables (because the BIOS couldn’t boot from 2nd disk probably due to selection issues (using model and serial number which were identical until about the 20th digit).
Then of course I hit the problems reported, but using the docs came up with :
###Don't change this comment - YaST2 identifier: Original name: windows 2###
title Vista
rootnoverify (hd1,2)
map (hd0) (hd1)
map (hd1) (hd0)
chainloader (hd1,2)+1
The map directives fix up the BIOS disk numbers to be what vista expects.
Had trouble free operation for over a year, and using GRUB is a hell of a lot easier than trying to add items into Vista boot loader.
Thanks for the contribution. Just fyi, the bios does not use the “dev-by-id” (serial nbr + partition nbr); that is now used in grub’s installation disk alignment file (device.map) and on the kernel line of grub’s menu.lst for the kernel to know which disk/partition to mount as root, because it is a persistent unique identifier (i.e., does not change as device-name - sda, sdb, etc. - can if disks are changed/moved, which is relatively common now given SATA portability). There other available persistent identifiers that can be used are volume-label (used by Fedora) and UUID (used by Ubuntu).
Having said that, you are quite correct that the map command instructs grub to call the Windows (this applies to all versions since NT) partition boot sector in such a way that it thinks it is the first disk in the bios boot configuration.
No of course, the BIOS uses disk numbers like 0x80 and 0x81.
The point is, to have the Vista boot loader get started as if it was on the Master Boot drive, with it’s partition marked active. Then entry is rather similar to how it used to be done with LILO, which worked with Win9x to, not just NT.
Going off track from Vista booting and commenting on the non-persistent, persistent Devices, I generally only mount via LABEL= or UUID= lines, except for LVM devices like /dev/System/Work.
They work perfectly well in openSuSE if you choose the expert partitioning options on install (or convert afterwards), though I did seem to have difficulty in 11.1-RC1, at the boot loader install stage using a label for Root LVM filesystem.
Quite a few of my old boxes, have occasional (permanent) issues with libata/pata_* drivers, so going back to the ide/ata code, can be useful and changes /dev/sdb to /dev/hda for example.
Very well said . . . I’ve begun moving to using label, too.
By the way, what method do you use to force the kernel to not use the libata/scsi emulation? Are you using an old kernel, compiling your own, or . . . ? I have some old machines, too, and so far I haven’t had a problem with the new libata (knock on wood).
The workround for 11.1 involves a netinstall or DVD install (passing brokenmodules=pata_pdc202xx_old boot option to linuxrc). The install is simplest due to the way the mkinitrd is made, using modules based on running system via udev.
You can then copy in kernel, initrd and related files generated, into the live system. Once you are pata_ free, then you can install a kernel more to your likeing, like the -default one rather than the (bigsmp) -pae huge SMP server kernel.
Booting from Live CD, or Live CD installations are insufficient, brokenmodules= is not handled.
The other method, is to compile kernel with cloneconfig, then choose your version string, disable pata_ module, and run the mkinitrd, ignoring the “FATAL:” error message when it can’t find the module.
Fortunately for me, the Promise cards I have, while older, still work with the pdc202xx_new module. But still, thanks for that info, will definitely come in handy - I suspect I may run into that with an old box (ALi chipset) I’ve been planning to re-commission.
The mkinitrd really bothers me, if build a system for initial tests and then want to move root say into a Logical Volume in a RAID 10 array, away from one on a local disk controller, how exactly do you build the initrd’s correctly now?
The old script was clear enough to hack if you needed to, the INITRD_MODULES method meant you could alter in place, to get the right hardware drivers.
You may get get bitten, my card works fine with pata_pdc202xx_old from Q4 2000 with disks from about 2000.
If I drive Seagate disks I have from Q3 2003, then it falls back to PIO mode, with first access likely failing, with pata_pdc202xx_old.
The IDE/ATA module pdc202xx_old for some reason doesn’t trigger the errors.
So if you move disks around, and then get problems you might try booting install disk with brokenmodules=pata_pdc202xx_old and see if you get good UDMA transfer speed booting that way. Rather than checking cables etc for nicks.
Thx, great note. Hadn’t occurred to me that the disks might be a factor. I have ~5 yr old WD’s hung off a card running 2.6.22 in a server, still performing perfectly; maybe I got lucky. The other card only has opticals attached; no problem them either. I’ll keep that in mind though when next moving disks (I have Seagates as well).
