Re: [opensuse-factory] EFI bootloader broken during update of Tumbleweed

On Tue, Apr 12, 2016 at 04:50:37PM +0100, Daniel Morris wrote:

On Tue, Apr 12, 2016 at 06:28:20AM +0300, Andrei Borzenkov wrote:

...

11.04.2016 23:47, Daniel Morris пишет:

...

On Mon, Apr 11, 2016 at 01:12:43PM -0600, Chris Murphy wrote:

...

On Mon, Apr 11, 2016 at 10:49 AM, Andrei Borzenkov wrote:

...

11.04.2016 18:26, Daniel Morris пишет:

...

One other oddity I noticed was grub2-i386-pc is installed and wants to remove all other grub2 packages if I try to remove it. I was expecting grub2-x86_64-efi and grub2-i386-pc would be mutually exclusive.

Why should they be? First, you can usually boot the same system both ways; and in any case you may want to create various bootable media using these binaries. As the most obvious example - grub2-mkrescue creates single image that contains all available grub binaries and so is bootable using either method.

Ahh yeah you're right, I see on a live installation both are present. In any case, only one of those gets used at bootloader installation time, depending on the installation environment. The installer doesn't write out both UEFI and BIOS bootloaders; in fact the installer does partitioning based on the boot environment: BIOS installs don't have EFI System partitions, where UEFI ones do.

So if Daniel could show us the output of 'blkid' that'd be even more conclusive about what kind of installation he has.

This seems to suggest I have both:

chunk:/tmp # lsblk -a /dev/sda /dev/sr0 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 111.8G 0 disk ├─sda1 8:1 0 156M 0 part /boot/efi ├─sda2 8:2 0 2G 0 part [SWAP] └─sda3 8:3 0 109.6G 0 part /boot/grub2/i386-pc sr0 11:0 1 4.3G 0 rom

Default openSUSE install creates subvolumes for both /boot/grub2/i386-pc and /boot/grub2/x86_64-efi, so you should always have both. Unfortunately lsblk is pretty lame in showing them; so df -h output would be more informative.

I had noticed it made lots of subvolumes :)

/dev/sda3 110G 64G 46G 59% / /dev/sda1 156M 4.6M 152M 3% /boot/efi /dev/sda3 110G 64G 46G 59% /usr/local /dev/sda3 110G 64G 46G 59% /.snapshots /dev/sda3 110G 64G 46G 59% /var/tmp /dev/sda3 110G 64G 46G 59% /var/lib/mysql /dev/sda3 110G 64G 46G 59% /boot/grub2/x86_64-efi /dev/sda3 110G 64G 46G 59% /var/opt /dev/sda3 110G 64G 46G 59% /srv /dev/sda3 110G 64G 46G 59% /var/lib/libvirt/images /dev/sda3 110G 64G 46G 59% /var/spool /dev/sda3 110G 64G 46G 59% /tmp /dev/sda3 110G 64G 46G 59% /var/lib/pgsql /dev/sda3 110G 64G 46G 59% /var/crash /dev/sda3 110G 64G 46G 59% /var/log /dev/sda3 110G 64G 46G 59% /var/lib/mariadb /dev/sda3 110G 64G 46G 59% /var/lib/named /dev/sda3 110G 64G 46G 59% /home /dev/sda3 110G 64G 46G 59% /opt /dev/sda3 110G 64G 46G 59% /var/lib/mailman /dev/sda3 110G 64G 46G 59% /boot/grub2/i386-pc

...

...

chunk:/tmp # blkid /dev/sda /dev/sr0 /dev/sda: PTUUID="9acb1fa5-67cc-474d-a68b-20a8afb6553f" PTTYPE="gpt" /dev/sr0: UUID="2016-01-02-22-02-19-00" LABEL="openSUSE-Tumbleweed-DVD-x86_6400" TYPE="iso9660" PTUUID="375b4ac0" PTTYPE="dos"

Whereas the last entry in the /var/log/pbl.log thought it was writing grub2-efi (as do all 173):

...

...

...

>>>>>>>>>>>>> 2016-04-08 13:28:42 <1> update-bootloader-0735 new.124: update-bootloader-0735 = /sbin/update-bootloader, version = 0.911, root = 0:37 2016-04-08 13:28:42 <1> update-bootloader-0735 main.237: /sbin/update-bootloader --refresh 2016-04-08 13:28:42 <1> update-bootloader-0735 main.239: bootloader = grub2-efi 2016-04-08 13:28:50 <1> update-bootloader-0735 run_command.254: '/usr/lib/bootloader/grub2-efi/config' = 0, output:

Well, grub2-efi here comes from manual configuration (whatever bootloader type had been selected in YaST) and does not reflect actual boot environment. Also "update-bootloader --refresh" does *only* grub2-mkconfig which is unaware of BIOS/EFI distinction (well, almost ...) and creates the same file everywhere, except when secure boot is enabled.

But the log you have shown previously demonstrated clearly that your system was booted in legacy BIOS mode.

...

efibootmgr: Could not delete boot variable: No such file or directory

This is the part I really don't follow, as I don't monkey around with the BIOS at all and to my knowledge the system has booted as EFI all along.

The very first entries in /var/log/pbl.log suggest UEFI was working with the DVD:

2015-11-24 09:16:20 <1> pbl-8744.1 Library::new.152: pbl-8744.1 = /sbin/update-bootloader (via main), version = 0.844, root = /dev/vda (chroot) 2015-11-24 09:16:20 <1> pbl-8744.1 main.233: /sbin/update-bootloader --reinit 2015-11-24 09:16:20 <1> pbl-8744.2 Library::new.152: pbl-8744.2 = /sbin/update-bootloader (via Bootloader::Tools), version = 0.844, root = /dev/vda (chroot) 2015-11-24 09:16:20 <3> pbl-8744.2 FileIO::ReadFileRaw.168: Error: Failed to open /etc/fstab: No such file or directory 2016-01-05 15:58:20 <1> update-bootloader-8014 new.96: update-bootloader-8014 = /sbin/update-bootloader, version = 0.901, root = 0:25 (chroot) 2016-01-05 15:58:20 <1> update-bootloader-8014 main.195: /sbin/update-bootloader --reinit 2016-01-05 15:58:20 <1> update-bootloader-8014 main.199: bootloader = grub2-efi 2016-01-05 15:58:22 <1> update-bootloader-8014 run_command.210: '/usr/lib/bootloader/grub2-efi/install' = 0, output: <<<<<<<<<<<<<<<< target = x86_64-efi + /usr/sbin/shim-install --config-file=/boot/grub2/grub.cfg Installing for x86_64-efi platform. Installation finished. No error reported. BootCurrent: 0004 Timeout: 2 seconds BootOrder: 0000,0001,0002,0003,0004 Boot0001* Hard Drive Boot0002* CD/DVD Drive Boot0003* Removable Drive Boot0004* UEFI: ATAPI iHAS324 B Boot0000* opensuse-secureboot

...

...

...

...

...

>>>>>>>>>>>

Searching a bit more through the 55k lines of /var/log/pbl.log I can find a couple of efibootmgr references/exceptions, Jan 13 "efibootmgr: Could not delete boot variable: No space left on device" and:-

2016-04-05 09:38:19 <1> update-bootloader-9139 new.124: update-bootloader-9139 = /sbin/update-bootloader, version = 0.908, root = 0:38 2016-04-05 09:38:19 <1> update-bootloader-9139 main.237: /sbin/update-bootloader --reinit 2016-04-05 09:38:19 <1> update-bootloader-9139 main.239: bootloader = grub2-efi 2016-04-05 09:38:21 <3> update-bootloader-9139 run_command.254: '/usr/lib/bootloader/grub2-efi/install' failed with exit code 15, output: <<<<<<<<<<<<<<<< target = x86_64-efi + /usr/sbin/shim-install --config-file=/boot/grub2/grub.cfg Installing for x86_64-efi platform. Installation finished. No error reported. efibootmgr: Could not delete boot variable: No such file or directory

...

...

...

...

...

>>>>>>>>>>>

Looks to me the NVRAM is tight in free space so that couldn't allocate more spaces for creating or deleting UEFI boot variables. It reminds me of the firmware implementation may not free up the deleted space of boot variable immediately. Instead it will flag and schedule it as "to be deleted" next time your system reboots, so called garbage collection during one of the firmware boot stages. So that if you don't reboot for a long time, it's likley the nvram will be drained out by accumulated efibootmgr updates, as deleted vars still count as "used". Even worse, the garbage collection may not be triggered each time system reboots, but depending on exceeding a predefined threshold value, which makes it way eariser to bump into efibootmgr error. But anyway this still may not explain or connected to your problem as to why the firmware became legacy boot mode (ie CSM ON) without any controlled changes. Thanks, Michael

That entry is near where I suspect things somehow became broken.

I'll have a chance to bring the machine down to the BIOS shortly. One striking thing that I noted last night as I prepped a pair of Tumbleweed USB keys (Rescue & Net install), was that when I booted my Dell XPS13 to test it gave me an explicit choice of legacy mode or UEFI.

Daniel

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org