I have a single RAID disk which, once upon a time, I was able to install another Linux distribution on. After Grub2 I have had less luck.
Anyway, I gave openSuse 12.2 a try.
I have a single device, /dev/md126 and I have installed Windows 7 in the first three primary partitions
Inside this I have an extended partition /dev/md126p3
Inside this I have a logical partition /dev/md126p8 (onto which I place /boot) and a Linux Volume Group for / and swap and so on and so forth.
YaST2 reads the RAID disk and detects all the apartitions correctly. If I do not manipulate the boot loader install options, it puts the boot loader on /dev/md126p3 (i.e. the extended partition). That didn’t work (i.e. the system started rebooting but hung instead of showing the Grub menu).
I tried a second tie, attempting to put the bootloader on /dev/md126p8 (two options in boot loader management, boot from boot partition and select custom location) , interrupted the shutdown and looked (in another VT) for a likely file to show me the status (e.g. some sort of install log file) to send to developers but didn’t find anything. I then allowed the reboot to continue.
At the next boot, the RAID array came up dirty and the reboot did not progress. Oh yeah, the extended partition was marked bootable, dunno if that’s correct.
So, at the moment, I’m rebuilding the array by starting a live system from a distribution which doesn’t fail at Intel fake RAID.
As always, no particular problem if the system is not intended to do this; I’ll find a workaround. But it’s another thing to claim to work and then not work.
The first install didn’t touch any boot related options, i.e. I used whatever is the default for openSuse 12.2 x86_64. I think grub2 (from remembering the screen shown with the configuration.
Do you know where I should look to get a log file that documents what the install did?
When it boots, the screen goes blank and there is an underscore cursor on the first line (I think).
Well, that’s an idea, except that “findgrub” does not appear to read the MD RAID device (which is there, after booting liveCD, it’s just that findgrub goes straight to the underlying devices).
having gotten that off my chest, heres the output from the working install (NOT the openSuse install).
Find Grub Version 4.0 - Written for openSUSE Forums
- reading MBR on disk /dev/sda ... --> Grub2 (1.99) found in sda MBR => sda8)/grub2 0x?? (Fedora)
- searching partition /dev/sda1 (NTFS) ...
- searching partition /dev/sda2 (NTFS) ...
- reading bootsector /dev/sda3 (Extended) ...
- reading MBR on disk /dev/sdb ... --> Grub2 (1.99) found in sdb MBR => sda8)/grub2 0x?? (Fedora)
- searching partition /dev/sdb1 (NTFS) ...
- searching partition /dev/sdb2 (NTFS) ...
- reading bootsector /dev/sdb3 (Extended) ...
- reading MBR on disk /dev/sdc ... --> Invalid boot signature: 0xee10
- reading MBR on disk /dev/sdd ... --> Invalid boot signature: 0xee10
- reading MBR on disk /dev/sde ...
- reading MBR on disk /dev/sdf ...
- searching partition /dev/sdf1 (NTFS) ...
- searching partition /dev/sdf2 (NTFS) ...
- reading bootsector /dev/sdf3 (Extended) ...
- reading bootsector /dev/sdf5 (LINUX) ...
- reading bootsector /dev/sdf6 (LINUX) ...
********************************************************************************
WARNING: /boot/grub/device.map not found.
Displayed BIOS device mapping may be incorrect!
********************************************************************************
Actually, on a second try, I got a “No Operating System” message when booting openSuse.
Anyway, I installed openSuse from DVD again, and got this out of findgrub
Find Grub Version 4.1 - Written for openSUSE Forums
- reading MBR on disk /dev/sda ... --> SUSE Generic MBR (Sig: 0x1ef0c)
- searching partition /dev/sda1 (NTFS) ...
- searching partition /dev/sda2 (NTFS) ...
- reading bootsector /dev/sda3 * (Extended) ...
- reading MBR on disk /dev/sdb ... --> SUSE Generic MBR (Sig: 0x1ef0c)
- searching partition /dev/sdb1 (NTFS) ...
- searching partition /dev/sdb2 (NTFS) ...
- reading bootsector /dev/sdb3 * (Extended) ...
- reading MBR on disk /dev/sdc ... --> Invalid boot signature: 0xee10
- reading MBR on disk /dev/sdd ... --> Invalid boot signature: 0xee10
- reading MBR on disk /dev/sde ...
- reading MBR on disk /dev/sdf ...
- searching partition /dev/sdf1 (NTFS) ...
- searching partition /dev/sdf2 (NTFS) ...
- reading bootsector /dev/sdf3 (Extended) ...
- reading bootsector /dev/sdf5 (LINUX) ...
- reading bootsector /dev/sdf6 (LINUX) ...
********************************************************************************
WARNING: /boot/grub/device.map not found.
Displayed BIOS device mapping may be incorrect!
********************************************************************************
I also got the disk partitioning after the succesful install, note /dev/md126p8 set as bootable (in the - I thought - unlikely case that this is not an MD RAID problem…)
Disk /dev/md126: 2000.4 GB, 2000404086784 bytes
2 heads, 4 sectors/track, 488379904 cylinders, total 3907039232 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 65536 bytes / 131072 bytes
Disk identifier: 0x000c01ef
Device Boot Start End Blocks Id System
/dev/md126p1 2048 206847 102400 7 HPFS/NTFS/exFAT
/dev/md126p2 206848 137002319 68397736 7 HPFS/NTFS/exFAT
/dev/md126p3 315625464 3907038848 1795706692+ 5 Extended
Partition 3 does not start on physical sector boundary.
/dev/md126p5 1204899840 1238454272 16777216+ b W95 FAT32
/dev/md126p6 1238458368 3907038848 1334290240+ 7 HPFS/NTFS/exFAT
/dev/md126p7 316655616 1204889599 444116992 8e Linux LVM
/dev/md126p8 * 315629568 316639231 504832 83 Linux
Partition table entries are not in disk order
Oops. That’s pretty bad and likely explains what happens.
Booting from extended partition is quite normal. In your case this is almost the only possibility anyway, as two other partitions are Windows.
So your extended partition should be /dev/md126p3 (or whatever md number it gets during installation). Did you try to explicitly specify it as partition to install bootloader on? It includes only physical devices in drop down list, but allows to explicitly type in device name.
Any chance to create small RAID1 on two disks for /boot and use it?
Well, OK, but it’s a software administered RAID and the kernel understands it perfectly as md126pN …
Booting from extended partition is quite normal. In your case this is almost the only possibility anyway, as two other partitions are Windows.
That’s what I thought.
So your extended partition should be /dev/md126p3 (or whatever md number it gets during installation). Did you try to explicitly specify it as partition to install bootloader on? It includes only physical devices in drop down list, but allows to explicitly type in device name.
Actually, I think the installer already picks /dev/md126p3, i.e. the extended partition (from looking at the status page after setting up storage options and before going ahead). But, is that the right answer? Given that /dev/md126p8 , i.e. the logical partition inside the extended partition, is where /boot lives?
I tried manually specifying the bootloader target, and chose /dev/md126p8, but did not get a lot of joy. Dunno if that partition was marked bootable (although the installer did change the bootable flag to /dev/md126p3 in an earlier run).
Any chance to create small RAID1 on two disks for /boot and use it?
That would be pretty hard (using four out of six SATA sockets for disks and one for DVD)…
Installer leaves logs in /var/log/YaST2; in this case what would be quite interesting is y2log_bootloader. There is also perl-BL-standalone-log as well as bunch of other files. If you could upload archive somewhere (e.g. paste.opensuse.org) I would try to get a look.
I think you should open bug report. I was not sure where it tries to install bootloader, but installer correctly understands that /dev/md126 is first BIOS drive, creates BIOS mapping and finally calls function that should install GRUB2. At this point either installer does not provide enough information to grub2 or grub2 fails to install where it is told. To decide some more intimate knowledge of YaST2 internals is required.