Bugzilla – Bug 1084017
YaST in Leap 15 fails to set boot flags correctly
Last modified: 2022-09-21 15:54:11 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
Welcome to GNU Parted! Type 'help' to view a list of commands.
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
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.
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.
(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.
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.
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 ).
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.
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.
Josef, there are new logs.
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?
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.
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.
OK, then go ahead as you suggest.
Tracking in YaST scrum board.