Bug 1084017 - YaST in Leap 15 fails to set boot flags correctly
YaST in Leap 15 fails to set boot flags correctly
Status: CONFIRMED
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: YaST2
Leap 15.0
x86-64 Other
: P3 - Medium : Normal (vote)
: ---
Assigned To: YaST Team
Jiri Srain
https://trello.com/c/K3qhjB6l
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-03-05 21:19 UTC by Larry Finger
Modified: 2022-09-21 15:54 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Compressed YaST2 logs (14.96 KB, application/x-xz)
2018-03-05 21:19 UTC, Larry Finger
Details
Saved YaST2 logs from installation (950.80 KB, application/x-xz)
2018-03-09 01:40 UTC, Larry Finger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Larry Finger 2018-03-05 21:19:47 UTC
Created attachment 762755 [details]
Compressed YaST2 logs

My system has a GPT partitioning scheme and does not use EFI. I also put the boot block at the start of the active partition, and have generic boot code in the MBR. The active partition is indicated with the legacy_boot flag.

A partial df for the system is:

Filesystem                 1K-blocks      Used Available Use% Mounted on
/dev/sda3                   60213124   9954072  47170668  18% /
/dev/sda6                   53826316  32795236  20576144  62% /var/tmp
/dev/sda7                   51255784  20631016  28050216  43% /TW
/dev/sda4                   60344404  22760752  36522788  39% /Leap42.3
/dev/sda5                  711705020 393141448 282387980  59% /home
tmpfs                         809360        20    809340   1% /run/user/1000

Looking at the partitions with parted:
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: ATA Samsung SSD 850 (scsi)
Disk /dev/sda: 1024GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: pmbr_boot

Number  Start   End     Size    File system     Name  Flags
 1      1049kB  9437kB  8389kB                        bios_grub
 2      9437kB  16.8GB  16.8GB  linux-swap(v1)        swap
 3      16.8GB  79.7GB  62.9GB  ext4
 4      79.7GB  143GB   62.9GB  ext4                  msftdata
 5      143GB   883GB   741GB   ext4                  msftdata
 6      883GB   939GB   56.1GB  ext4                  msftdata
 8      939GB   971GB   31.5GB  ext4
 7      971GB   1024GB  53.5GB  ext4                  legacy_boot, msftdata

(parted) quit

In this case, partition number 7 will be booted. Running YaST => System => Boot Loader changes nothing. If I want the automatic boot to choose Leap 15.0, I need to manually toggle the legacy_boot flag on partitions 7 and 3.

Attached is a compressed copy of the /var/log/YaST2/ directory.
Comment 1 Steffen Winterfeldt 2018-03-06 16:07:07 UTC
Hm, it says:

bootloader/mbr_update.rb:20 Stage1: <Bootloader::Stage1 24137560 activate: false generic_mbr: true devices: ["/dev/sda3"]>

I wonder if this 'activate: false' is the correct thing.

Josef?
Comment 2 Josef Reidinger 2018-03-06 16:11:08 UTC
(In reply to Steffen Winterfeldt from comment #1)
> Hm, it says:
> 
> bootloader/mbr_update.rb:20 Stage1: <Bootloader::Stage1 24137560 activate:
> false generic_mbr: true devices: ["/dev/sda3"]>
> 
> I wonder if this 'activate: false' is the correct thing.
> 
> Josef?

yes, it looks like root of issue as legacy boot is at sda7, but it should be on 3. I have to check logs why it is not proposed to activate it.
Comment 3 Josef Reidinger 2018-03-07 07:36:06 UTC
OK, I check logs and this is logs only from running system. I will need logs from that installation. Can you upload complete logs? You can get it with command `save_y2logs` that creates tarball for you and it should include also installation logs ( unless it is already rotated away ).
Comment 4 Larry Finger 2018-03-07 16:19:28 UTC
If the installation logs were not in the file I posted, then they must have been rotated away.

One thing to note. In addition to failure to set the boot_legacy flag on installation, YaST2 => System => Boot Loader was failing to change those flags. That has now been fixed, and the problem on installation may also be fixed.

When I get some time, I will reinstall the latest snapshot of Leap 15 and test if the boot flags are set properly. If not, I will then have the logs.
Comment 5 Larry Finger 2018-03-09 01:40:26 UTC
Created attachment 763161 [details]
Saved YaST2 logs from installation

I reinstalled from scratch using Build 151.1. As before, I had partition 7 with the legacy_boot flag set. After finishing the installation, that partition still had the flag set. If I selected the new Leap 15 installation for booting, I was then able to use the YaST2 => System => Boot Loader page to manipulate that flag.
Comment 6 Steffen Winterfeldt 2018-03-09 13:53:06 UTC
Josef, there are new logs.
Comment 7 Josef Reidinger 2018-04-26 12:52:43 UTC
Thanks for logs. Now it is clear for me what happened.

Original proposal is boot from MBR and do not activate, because disk already have legacy_boot flag ( grub2 does not use it and for firmware any partition already marked is fine ). Then customer switched to boot from boot and we just change device for stage1,, but not setting for generic_mbr neither activate.
That is reason why bootloader write warning:

2018-03-08 14:27:16 <1> install(3612) [Ruby] installation/proposal_runner.rb:514 proposal returns warning with level error and msg The installer will not modify the MBR of the disk. Unless it already contains boot code, the BIOS won't be able to boot from this disk.

So question is if we should modify behavior and when boot from partition is pressed, if we should automatic mark generic_mbr to true and also activate?

Jiri - what is your opinion on it?
Comment 8 Jiri Srain 2018-04-27 06:37:51 UTC
I'm a bit hesitant to change the values automatically - but on the other hand for users not knowing the details, this can lead to situations like this.

I would consider: When changing the Stage1 location from MBR to partition, ask user whether to put the generic code to MBR and activate the partition - unless those check-boxes are already checked.

This should give users enough hints while avoiding the surprise of rewritten MBR.
Comment 9 Josef Reidinger 2018-04-27 06:45:09 UTC
Well, disadvantage is that when we ask user in popup it basically kills idea of one click change of proposal. In such case I think that even changing it automatically is better and if user want more control he can always use full bootloader.
Comment 10 Jiri Srain 2018-04-27 06:56:22 UTC
OK, then go ahead as you suggest.
Comment 11 Steffen Winterfeldt 2018-04-27 08:12:13 UTC
Tracking in YaST scrum board.