The installer cannot tell what boot order the BIOS uses. So you have to set boot order in the installer. But it is looking as if that part is buggy with the new installer.
I don’t current have a computer with two hard drives. Well, actually, I do, but it is a UEFI system.
I think I need to set up a virtual machine with two virtual drives, in order to test this.
I’ll see if I can find time for that today.
Actually as long as installer is using syslinux (and for 42.3 it definitely does) it should be able to tell it using EDD services. Whether it makes use of this information is another matter.
I have reproduced the problem with Leap 15.
This is on a KVM virtual machine with two disks. I installed Leap 42.3 on the first disk, booting from root partition.
I then went to install 15.0 on the second disk. I want it to boot from the MBR of the first disk. So I set the disk order for “/dev/sda” to be first, and set it to boot from the MBR. The summary page showed it booting from “/dev/sdb”. And that’s wrong if “/dev/sda” is first. If I tell the BIOS to boot from the second drive (from “/dev/sdb”) then the BIOS temporarily changes the disk order for this boot to put “/dev/sdb” first (at least, that’s my experience). The booting should have been set to boot from “/dev/sda”.
I aborted that second install. But I did save logs and a screenshot of the summary screen. I plan to report a bug on this.
I’ve booted to Leap 15 now by using my existing GRUB on 42.2, copying the Tumbleweed entry and adjusting the partition ID’s. To make things easy I abandoned separate /boot.
In Leap 15 for testing I run grub2-mkconfig and it sees Leap 15, Windows, OpenSuse 42.2 fine but while it sees Tumbleweed is present it doesn’t get any kernel entries so doesn’t make menu properly. I have this is another thread but wondering if because kernels in Tumbleweed are higher than what 42.2 or 15 know it doesn’t see them?
Thanks for all the help folks.
Please start new thread about different problem.
It should not care about the kernel versions, as long as it can tell that they are kernels.
From the bug it seems a decision by the booting team to limit Yast to install GRUB only to the disk that holds the boot partition (or boot directory).
Shame as this breaks something that worked fine.
So it seems I need to enter /dev/sdb into Yast - Bootloader (or preferably via /dev/disk/by-id/<disk_id>) but they won’t provide “help” in the application on valid values.
Yes, that’s about right.
I guess this works for most cases. And they figure that for special cases the person doing the install has to know what they are doing.