New Intel motherboard with UEFI support (I disabled UEFI, of course).
Two SSD drives on Marvell 6Gbit/s controller. One with pure Windows 8 the other with OpenSUSE. Both installed separately that is with other drive physically disconnected, both boot correctly when the drive is first in BIOS boot order.
It is not possible to boot Windows from GRUB menu. I tried all permutations, diagnosed the problem by entering commands one by one on GRUB console.
The root of the problem is that GRUB does not see the other drive at all - and reports error 25 when any operation on the other drive is attempted. This is easily proven by issuing the GEOMETRY command. GRUB only sees hd0.
Therefore, trying to chainload to MBR or directly to a Windows partition or any other options are futile.
File device.map is correct. I changed it manually (reconfiguring GRUB of course after that) and through Yast to make sure I am not missing anything. The file looks like this:
Linux detects both drives, of course, after booting. Windows too. The drive dev assignment /dev/sda /dev/sdb always corresponds to SATA port numbers. (Port 0 is sda, port 1 is sdb). Swapping drives on ports changes only sda sdb assignments and nothing else.
At this point I am happy with the workaround of forcing BIOS boot menu when I need to change OS, but I am wondering if anyone has any ideas why GRUB fails to see the other drive. I am also wondering if this is indication of trouble coming with Microsoft jumping on the UEFI bandwagon.
I get a feeling it is, because the reason I had to physically shuffle drives while installing OSes was that on the first attempt Windows 8 repartitioned all connected drives, not just the one I told it to install itself to. I made sure several times that no BIOS was configured for any kind of RAID options.
I am aware of other possible workarounds of, for example not using the /dev/diskby-id, but this would be asking for more trouble since I am going to put far more drives in the system.
The way I see it - either GRUB has a bug in implementing the /dev/diskby-id method (less likely) or mobo BIOS now only reports the first drive to the bootloaders as part of someone’s UEFI fantasy.
I can do this, of course, but I don’t see how it will do anyone any good since I diagnosed with GRUB console that GRUB only sees hd0 while Linux kernel sees both drives. Any operation on hd1 returns Error 25.
As I said, I tried all possible options of menu.lst commands. One of them, chaining to MBR on hd1:
title Windows 8
map (hd0) (hd1)
map (hd1) (hd0)
rootnoverify (hd1)
chainloader +1
I also tried it with chainloader --force option, root instead rootnoverify, etc,etc . But, of course, no set of commands will work if GRUB does not see hd1 at all - which I confirmed by GRUB console geometry command.
Kernel sees everything as it should, of course:
Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x8a....
Device Boot Start End Blocks Id System
/dev/sda1 2048 4208639 2103296 82 Linux swap / Solaris
/dev/sda2 * 4208640 46153727 20972544 83 Linux
/dev/sda3 46153728 234440703 94143488 83 Linux
Disk /dev/sdb: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x7d.....
Device Boot Start End Blocks Id System
/dev/sdb1 * 2048 718847 358400 7 HPFS/NTFS/exFAT
/dev/sdb2 718848 234438655 116859904 7 HPFS/NTFS/exFAT
I don’t know what you did to reconfigure Grub, but to reflect the changes in device.map, you should reinstall stage1.
This is irrelevant and often misleading. You should not use device names anywhere - and it looks like you don’t.
This of course is going to be fun as soon as ‘Secure Boot’ becomes mandatory.
What else do you expect from Microsoft? It has done things like that for a quarter of a century.
/dev/disk/by-uuid is a better method (not /dev/disk/by-id). And UUID is even better than using symlinks generated by udev, but I don’t think it’s the problem here.
The UEFI/BIOS makes it complicated. You can try to reenable UEFI and install a minimal Ubuntu with Grub2, just for the purpose of booting everyone else. UEFIBooting - Community Help Wiki.
Try to switch the SATA port of the second hd (from SATA2 to SATA3). Sounds simple but could help if it’s a mb design problem.
Any manual change to the device.map file requires that you update your GRUB installation. Use the following command:
grub --batch --device-map=/boot/grub/device.map < /etc/grub.conf
As device.map change not being properly reported to GRUB was my first thought, I read and reread the instructions, then let YaST do the same thing from scratch, and nothing changed. GRUB still does not see hd1.
Did I miss something? Do I have to force some of the files to be re-written to MBR?
I will probably try to boot from USB stick and see if it can see the SATA drives.
No. You did it in batch mode. I’ll do it in the grub shell, but it comes to the same (depends on what you read from /etc/grub.conf in your case).
If you have Linux on a separate disk, having Grub in the MBR (as well) wouldn’t certainly hurt anyone. Actually the trick - AFAIK because I’m not using Windows - would be to have Windows on the first SATA port, Linux on the second SATA port, switch boot order, so that the disk which has Linux has boot priority in the BIOS and install Grub in the MBR of that disk (so that it could benefit from stage 1.5). But it’s not guaranteed that Grub will see your second hard disk if the problem lies somewhere else.
faza wrote:
> I diagnosed with GRUB console that GRUB only sees hd0 while
> Linux kernel sees both drives. Any operation on hd1 returns Error 25.
>
> As I said, I tried all possible options of menu.lst commands. One of
> them, chaining to MBR on hd1:
>
> Code:
> --------------------
> title Windows 8
> map (hd0) (hd1)
> map (hd1) (hd0)
> rootnoverify (hd1)
> chainloader +1
> --------------------
>
>
> I also tried it with chainloader --force option, root instead
> rootnoverify, etc,etc . But, of course, no set of commands will work if
> GRUB does not see hd1 at all - which I confirmed by GRUB console
> geometry command.
>
> Kernel sees everything as it should, of course:
This sounds to me, as a non-expert, that perhaps the driver grub is
using to access the disks is not as capable as the one that the kernel
(and Windows) is using.
You haven’t told us what controller you’re using, or what motherboard,
or even what disks. You have said that it is ‘new Intel’, and as you
have perhaps read, there have been some problems with recent boards and
therefore quite a few fixes to drivers.
So I think I’d try a more up-to-date grub, either ubuntu or knoppix, and
see if that works. If so, you can use that to boot the system. It may
also be possible to fiddle with opensuse grub’s drivers, but I know
nothing about that possibility.