Bug 1084815

Created attachment 763322 [details]
Yast logs.

Created attachment 763323 [details]
Screenshot of L42.3 with default boot loader location

Created attachment 763324 [details]
Screenshot of L42.3, Installation settings view, after doing correct adjustments.

Created attachment 763325 [details]
Screenshot of L42.3, warning prior to install, ignored.

Created attachment 763326 [details]
Screenshot of L15.0 with default installation settings (incorrect)

Created attachment 763327 [details]
Screenshot of L15.0 with default boot loader location

Notice the "Boot from partition" line, without saying which. The first time installed I assumed it would be the root partition, obviously. It wasn't, it was sda4.

Created attachment 763328 [details]
Screenshot of L15.0 with cleared boot loader location

It is not shown in the photos because YaST refused to take more.
I changed the settings to "Custom Boot Partition" and below I wrote /dev/sda9, which is the root partition. Then I changed the tab to see the kernel settings, the options, and then back to "boot code options". The photo shows what I saw then: all options cleared, and the custom boot partition field deleted.

Installation was from openSUSE-Leap-15.0-DVD-x86_64-Build153.1-Media.iso wit network. XFCE selection.

macro_inst_initial.ycp from the y2logs tarball confirms this selection
(slightly reformatted for better readability):

{
  // 2018-03-11 13:14:53

  UI::ChangeWidget( `id ("Bootloader::LoaderTypeWidget"), `Value, "grub2" );
    // YComboBox "Boot Loader"
  
  UI::ChangeWidget( `id (`boot), `Value, false );
    // YCheckBox "Boot from Partition"
  
  UI::ChangeWidget( `id (`mbr), `Value, false );
    // YCheckBox "Boot from Master Boot Record"
  
  UI::ChangeWidget( `id (`custom), `Value, true );
    // YCheckBox "Custom Boot Partition"
  
  UI::ChangeWidget( `id (`custom_list), `Value, "/dev/sda9" );
    // YInputField ""
  
  UI::ChangeWidget( `id ("Bootloader::ActivateWidget"), `Value, false );
    // YCheckBox "Set active Flag in Partition Table for Boot Partit..."
  
  UI::ChangeWidget( `id ("Bootloader::GenericMBRWidget"), `Value, false );
    // YCheckBox "Write generic Boot Code to MBR"
  
  UI::ChangeWidget( `id ("Bootloader::TrustedBootWidget"), `Value, false );
    // YCheckBox "Enable Trusted Boot Support"
  

 return;
}


One thing I don't see at all there, though, is a checkbox for the extended partition. But this might also be interesting (from y2log-1.gz):

2018-03-11 13:31:56 <1> linux-9vao(3465) [Ruby] bootloader/stage1.rb:180 stage1 to merge <Bootloader::Stage1 31459980 activate: false generic_mbr: false devices: ["/dev/sda9"]>

2018-03-11 13:31:56 <1> linux-9vao(3465) [Ruby] y2storage/devicegraph.rb:321 Device <Partition /dev/sda9 7176 MiB (7.01 GiB), 935852032 - 950548479> found by its libstorage-ng name /dev/sda9

2018-03-11 13:31:56 <1> linux-9vao(3465) [Ruby] modules/BootStorage.rb:234 Using extended partition instead: <Partition /dev/sda4 308632747.5 KiB 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(294.34 GiB), 333284490 - 950549984>

2018-03-11 13:31:56 <1> linux-9vao(3465) [Ruby] modules/BootStorage.rb:167 stage1 partitions for <Partition /dev/sda9 7176 MiB (7.01 GiB), 935852032 - 950548479> are [<Partition /dev/sda4 308632747.5 KiB (294.34 GiB), 333284490 - 950549984>]

Josef, please have a look.

I don't know if grub can handle logical partitions on that level; but if it doesn't, we should clearly warn the user about it when he requests grub to be installed on a logical partition.

I found some interesting articles on the web that more or less say that some BIOSes may not be able to handle a boot loader in a logical partition; this might be an explanation for this behaviour. But in this case, we should warn the user about it.

yes, BIOS does not understand extended partition, so installing to logical is only for very advanced users which ensure its chainloading there. For this purpose user can use boot from custom location and specify it there. But I see that it is done in this case and it still rewrite it, which is wrong. I will prepare fix for it.

Thanks. Some clarifications:

Please notice that YaST in Leap 42.3 does contemplate this case, and does the correct choices for the case of the current install being the only or main one:

[X] Boot from Root partition
[ ] Boot from master boot record
[X] Boot from extended partition
[ ] Custom boot partition

In the present case, however, Leap 15.0 does not:

[X] Boot from partition         <=== (which partition?)
[ ] Boot from master boot record
[ ] Custom boot partition       <=== ignored


Also notice that it is not BIOS booting the logical partition sda9, it is GRUB from sda4 from the Leap 42.3 install.

Booting follows this chain:

Bios --> MBR --> sda4 --> grub from 42.3 --> sda9 --> grub from 15.0
                extnd     production                    beta

It is a triple boot machine, and this Beta is not the default system.

yes, that ignored is wrong ( in fact it is not ignored, but incorectly translate logical to extend, this I will try to fix ). Answer to which partition is - partition from which bootloader can boot system for sure ( so this is not logical one ).

Tracking in YaST scrum board.

fix is under review https://github.com/yast/yast-bootloader/pull/489

fix merged, will be in next build of leap 15.

Thanks for report.

I confirm that Build187 doesn't have this problem.