Both my Suse disk and the windows 7 disk are therefore booting EUFI.
I have not selected secure boot in Suse. The secure boot option in BIOS appears to be either (1) Windows mode EUFI or (2) other OS. The ‘other OS’ option appears to switch off secure boot in the BIOS (EUFI).
So, secure mode is off, both in the o/s and in BIOS (EUFI). My settings, therefore, must be correct.
Does anyone know what steps are taking place up to the point the BIOS (EUFI) screen appears? And how does it differ between a Windows 7 disk and a Suse 12.3 disk? There must be some sort of communication between a disk and BIOS. Can someone enlighten me?
I saw it.
Still, when I once installed windows 7 in UEFI mode I got a 3rd small partition, called ‘system reserved’ (or sth. similar) with a size of 130 MB.
That 3rd partition is missing on the page/screenshot you linked from the web.
If you want to make that sure, plug the windows 7 disk, but boot from a recent Linux live CD,
open a terminal, say ‘su -’ to become root, then say ‘parted -l’, copy the output to a file, and post it here.
Please do it, as well to confirm the setup with respect to partitions.
Hopefully.
The hard disk just can not communicate on that level.
It’s the BIOS / UEFI firmware that does the job.
And apparently the BIOS doesn’t handle your openSUSE disk in the same way as your windows disk.
Here is the info, without reference to start and end points:
-A-
==== begin data - via Suse Live boot reading passive Windows 7 HD =====
Model ATA ST2000M001 (SCSI)
Disk /dev/sda: 2000 GB
Sector size (logical / physical) 512B/4096B
Partition table: gpt
Number ----File system ------------------ Name -----------------Flag
1 ---------Fat 32 ----------------EFI System Partition -----------boot
2 --------------------------Microsoft reserved partition ----------msftr
3 ---------NTFS ----------------Basic data partition
==== end data =======
Here is the data for Suse live reading the passive Suse 12.3 HD where the Suse 12.3 HD was swapped for the Windows 7 HD
-B-
===== begin data via Suse Live boot reading passive Suse 12.3 HD============
Number ---- File system ----------- Name ------------- Flag
1 ------------- fat 16 -----------Primary---------------boot
2 --------- Linux-Swap (v1)------Primary--------------
3 -------------ext 4 ------------Primary--------------
4 -------------ext 4 ------------Primary--------------
===== end data ===========
I then reinstalled Suse 12.3 (actually, instead of fresh install, I chose ‘update’ which did the trick to make it bootable), booted to the HD and ran parted -l as root, and the data was the same as -B-, above. For consistency, I booted from the live Suse DVD and ran parted -l from root and it confirmed the dame data.
So, I am at a loss. Something inside BIOS (flash memory???) must be changed whenever the Windows 7 drive is installed in place of the Suse drive, and that ‘something’ must then be changed back whenever I reinstall Suse.
Funny. My hair was dark brown and quite full before I started this process. It is now white and on the ground.
At any rate, I just contacted Asus who responded within 3 hours (amazing!). They say (1) reinstall Suse and do not select UEFI boot. And (2) plug the HD carriage into the Marvel SATA port.
I will try that. But, my question is: If you remember, I tried to do that in the earlier installation - I went to the Boot options of installation where the default was GRUB2-EFI. I tried to change that to GRUB2, but a message appeared to the effect it was not compatible with the hardware. Seems it would not accept a non-EFI option. Any thoughts? I’ll try again later this afternoon. This is my flex day and I have soooo many other things I need to do!
Anyway, Mike, thank you very much for your kind help, suggestions, and patience!
That’s correct. grub2-efi works only on EFI platform, grub2 works only on BIOS platform. You must boot installation DVD in legacy BIOS mode, in which case grub2 will be selected automatically.
I think I may have solved it. I reinstalled Suse 12.3 and chose Grub2, and ignored the warning that it was not compatible with the hardware. Don’t know what the ultimate result will be. The only negative result I’ve seen is that the screen refresh during boot is visibly slow.
Choosing the Marvel ports simply added an extra boot step so I’ve swapped back to the normal ports.
