Bugzilla – Bug 932033
pmbr_boot disk flag should be off for UEFI boot
Last modified: 2015-06-03 14:06:29 UTC
I'm trying to install openSUSE 13.2 on an Acer TravelMate B115-M-41RQ with UEFI and SecureBoot enabled, and with a completely blank hard drive (no partitions at all). I used all the default options from the installer. The installer finishes successfully, but when the computer restarts, it says there are no bootable devices. (Not even GRUB comes up.) I can force my computer's boot device chooser to come up by pressing F12, but the hard drive on which I installed openSUSE isn't listed as a bootable device. I can boot into the openSUSE rescue system from the installation medium on USB. Here parted confirms there are four partitions as created by the installer (a bootable FAT partition, followed by a swap partition, then a BTRFS partition, and then an XFS partition). If I mount the boot partition I can see the EFI files in EFI/boot and EFI/opensuse. However, efibootmgr -v doesn't list any of these. I tried to add an entry as follows: efibootmgr -c -d /dev/sda -p -1 -l \\EFI\\opensuse\\grubx64.efi This seemed to work in that efibootmgr -v displayed the entry. However, when I restarted the computer I was still told that there were no bootable devices. When I rebooted the rescue system, the entry I added to efibootmgr was gone. Possibly this is a manifestation of a kernel bug which has also been reported for Ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1167622
It is probably not that kernel bug, which I remember in early pre-release versions of opensuse 13.1. That bug has long since been fixed. Here's something you can try. With a rescue boot, mount the EFI partition. Look for the directory \EFI\opensuse on that partition. Copy the content of that "opensuse" directory to "\EFI\Boot\" (you may need to create the "Boot" directory). Then change directories to that Boot directory. If there is a "shim.efi" there, then rename that as "bootx64.efi". Otherwise rename "grubx64.efi" to "bootx64.efi". Then see if the disk is recognized as bootable (when you use F12 during boot).
Thanks for the suggestion, Neil. I tried that but I'm afraid it didn't work. The computer still claims there are no bootable devices. I went to the BIOS menu and noticed that there's a command "Select an UEFI file as trusted for executing". If I run it allows me to select a file from the installation media (on a USB drive) but it doesn't show anything on the computer's internal hard drive. Here's the output of fdisk -l and parted showing the partitions on the internal drive (/dev/sda) and the external USB drive (/dev/sdb): # fdisk -l Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 21292F87-09BD-4B93-81B6-52C66A7657D6 Device Start End Sectors Size Type /dev/sda1 2048 321535 319488 156M EFI System /dev/sda2 321536 4530175 4208640 2G Microsoft basic data /dev/sda3 4530176 88422399 83892224 40G Microsoft basic data /dev/sda4 88422400 976773119 888350720 423.6G Microsoft basic data Disk /dev/loop0: 35 MiB, 36634624 bytes, 71552 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/loop1: 9 MiB, 9437184 bytes, 18432 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/loop2: 47.9 MiB, 50200576 bytes, 98048 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/loop3: 13.7 MiB, 14352384 bytes, 28032 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/loop4: 4.1 MiB, 4325376 bytes, 8448 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/sdb: 15 GiB, 16055795712 bytes, 31358976 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x10ce3e4f Device Boot Start End Sectors Size Id Type /dev/sdb1 3584 11647 8064 4M ef EFI (FAT-12/16/32) /dev/sdb2 * 11648 9138175 9126528 4.4G 17 Hidden HPFS/NTFS # parted /dev/sda GNU Parted 3.1 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: ATA WDC WD5000LPVX-2 (scsi) Disk /dev/sda: 500GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: pmbr_boot Number Start End Size File system Name Flags 1 1049kB 165MB 164MB fat32 primary boot 2 165MB 2319MB 2155MB linux-swap(v1) primary 3 2319MB 45.3GB 43.0GB btrfs primary 4 45.3GB 500GB 455GB xfs primary (parted) quit # parted /dev/sdb GNU Parted 3.1 Using /dev/sdb Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: Kingston DataTraveler 410 (scsi) Disk /dev/sdb: 16.1GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1835kB 5964kB 4129kB primary type=ef 2 5964kB 4679MB 4673MB primary boot, hidden, type=17 (parted) quit
Greetings. (In reply to Tristan Miller from comment #2) > # parted /dev/sda > GNU Parted 3.1 > Using /dev/sda > Welcome to GNU Parted! Type 'help' to view a list of commands. > > > (parted) print > Model: ATA WDC WD5000LPVX-2 (scsi) > Disk /dev/sda: 500GB > Sector size (logical/physical): 512B/4096B > Partition Table: gpt > Disk Flags: pmbr_boot It turns out this "pmbr_boot" disk flag was the problem. I have no idea whether the flag was already there when I got the machine, or whether it's something the openSUSE installer added, but in any case it shouldn't be there for a successful UEFI boot. To fix the issue I did the following from a rescue system: # parted /dev/sda (parted) disk_set pmbr_boot off (parted) quit After some more searching it seems this problem has also been reported for other GNU/Linux distributions, including Red Hat and Mageia: https://bugs.mageia.org/show_bug.cgi?id=12822 https://bugzilla.redhat.com/show_bug.cgi?id=844551 So I would suggest that when YaST partitions a disk for use on a UEFI system, it should make sure not to set the pmbr_boot disk flag; if pmbr_boot is already set, YaST should unset it, or at the very least warn the user about it and offer to unset it.
Thanks for the report. Please attach the YaST logs: https://en.opensuse.org/openSUSE:Report_a_YaST_bug
Sounds like bug 872054 to me, Josef?
Yes, it should be already fixed in TW. For 13.2 it do not make sense to release update as it need respin of DVD. Can you please try the latest TumbleWeed DVD? Thanks
I'm afraid I can't try the Tumbleweed DVD as I no longer have a USB drive big enough to copy the installation media onto. (The computer in question doesn't have a DVD drive.) Do you still want the old YaST logs? (I don't know if the ones currently in /var/log/YaST2 even have any record of the original installation. If I needed to switch to a text console immediately after the installation and copy the logs somewhere, I'm afraid it's too late.)
I think it is not needed, as 13.2 do not use pmbr disk flag which is implemented later. So Let me mark it as fixed and if you can try TW and it still do not work, then reopen it. Thanks