http://bugzilla.opensuse.org/show_bug.cgi?id=1017778 http://bugzilla.opensuse.org/show_bug.cgi?id=1017778#c1 --- Comment #1 from Richard Bos --- Created attachment 708205 --> http://bugzilla.opensuse.org/attachment.cgi?id=708205&action=edit Bootloader code options used -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1017778 http://bugzilla.opensuse.org/show_bug.cgi?id=1017778#c3 Jiri Srain changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|jsrain@suse.com |jreidinger@suse.com --- Comment #3 from Jiri Srain --- Well, YaST assumes that the disk you install to is the boot disk (and the order in which the Linux kernel gets the disks and gives them names may depend on the order of loading kernel modules if they are connected to different controllers). Therefore the behavior may be correct as - based on BIOS settings - /dev/sdb may really be the boot disk. However, for your scenario when /dev/sda is in the order of disks listed as first, I cannot really see whether/where it makes sense to write the generic code. As long as GRUB is installed into /dev/sdbx, I cannot see any way how generic code in MBR of /dev/sda could be of any use. Putting it to /dev/sdb would make sense if any other loader chainloaded it, but then it could chainload the boot sector with GRUB directly. Additionally, with c.a. 400 bytes I doubt that the code is ready to run on anything else than 1st disk (in the BIOS POV), which does not match the disk order in the screenshot. Perhaps we should prevent installing generic code to MBR if GRUB is not installed on the first (according to the order) disk? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1017778 http://bugzilla.opensuse.org/show_bug.cgi?id=1017778#c5 Jiri Srain changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jsrain@suse.com) | --- Comment #5 from Jiri Srain --- Well, it is not important where the order comes from. If the order always assumes that /dev/sdb is the first disk (which would make sense), OK. But as long as the UI shows it is 2nd, I cannot see how the full stack could boot (but I may miss something here). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1017778 http://bugzilla.opensuse.org/show_bug.cgi?id=1017778#c7 --- Comment #7 from Jiri Srain --- (In reply to Richard Bos from comment #6)

From #c3:

...

Perhaps we should prevent installing generic code to MBR if GRUB is not installed on the first (according to the order) disk?

If installing the MBR does not make sense, it shouldn't be done.

Well, with booting, there are too many unknowns, which cannot be detected. When booting the installation from CD/USB, the boot order is different than the one when you boot after installation. And the installer cannot know how you set your BIOS for next boot. As Josef pointed out, what I thought that makes no sense can make sense at the end - therefore we should be careful. MD arrays make quite a change. -- You are receiving this mail because: You are on the CC list for the bug.