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

newer
[opensuse-factory] New package for...

older
Re: [opensuse-factory] EFI...

Andrei Borzenkov

9 Apr 2016 9 Apr '16

03:51

09.04.2016 00:16, Daniel Morris пишет:

...

On Fri, Apr 08, 2016 at 07:46:39PM +0300, Andrei Borzenkov wrote:

...
08.04.2016 19:23, Daniel Morris пишет:

...
But the net effect is the same.

Unfortunately you forgot to tell what happens when you boot.

...
It seems as though the step between EFI and grub2 is missing. Could anyone suggest where to look next?

Please show "efibootmgr -v" output and describe what happens when system boots.

chunk:~ # efibootmgr -v efibootmgr: EFI variables are not supported on this system.

You are booted in legacy BIOS mode.

...

The BIOS complains that it can't find a bootable medium, asks for one to be inserted. The SSD is the first detected drive from the BIOS and the highest priority, with the DVD drive next.

Which hints again that your firmware attempts legacy BIOS boot.

...

I'm currently having to boot the system via the Tumbleweed DVD (selecting /dev/sda3 and picking one of the kernels found etc), but it worked fine for three months and I've not made any changes to the BIOS config.

May be. The fact is that based on your description firmware tries legacy BIOS boot and not EFI. This is outside of control of either bootloader or operating system. If you think this is wrong you need to verify your "BIOS" settings. That is something we cannot do from here, sorry. Or please make sure to actually boot in EFI mode and provide "efibootmgr -v" output again so we can verify firmware bootmanager setup. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Show replies by date

Chris Murphy

9 Apr 9 Apr

19:15

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

On Fri, Apr 8, 2016 at 9:51 PM, Andrei Borzenkov wrote:

...

09.04.2016 00:16, Daniel Morris пишет:

...
On Fri, Apr 08, 2016 at 07:46:39PM +0300, Andrei Borzenkov wrote:

...
08.04.2016 19:23, Daniel Morris пишет:

...
But the net effect is the same.

Unfortunately you forgot to tell what happens when you boot.

...
It seems as though the step between EFI and grub2 is missing. Could anyone suggest where to look next?

Please show "efibootmgr -v" output and describe what happens when system boots.

chunk:~ # efibootmgr -v efibootmgr: EFI variables are not supported on this system.

You are booted in legacy BIOS mode.

What could be confusing things, is maybe he's booting from install or rescue media differently than the installed system? If the installed system's boot is broken, then he has to have some way to get around that and we don't know what that is. And we still don't know what *does* happen when the installed system fails to boot, just telling us it's broken is not helpful. There are some crazy firmwares out there that will default to CSM-BIOS mode boot from optical media. So the first thing is Daniel needs to tell us exactly how the boot fails from the *installed* system. And then he needs to make sure he's using a proper installation media for his rescue boot, made in the officially documented way. And then see what he gets for efibootmgr -v. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Daniel Morris

11 Apr 11 Apr

15:26

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

On Sat, Apr 09, 2016 at 01:15:58PM -0600, Chris Murphy wrote:

...

On Fri, Apr 8, 2016 at 9:51 PM, Andrei Borzenkov wrote:

...
09.04.2016 00:16, Daniel Morris пишет:

...
On Fri, Apr 08, 2016 at 07:46:39PM +0300, Andrei Borzenkov wrote:

...
08.04.2016 19:23, Daniel Morris пишет:

...
But the net effect is the same.

Unfortunately you forgot to tell what happens when you boot.

...
It seems as though the step between EFI and grub2 is missing. Could anyone suggest where to look next?

Please show "efibootmgr -v" output and describe what happens when system boots.

chunk:~ # efibootmgr -v efibootmgr: EFI variables are not supported on this system.

You are booted in legacy BIOS mode.

What could be confusing things, is maybe he's booting from install or rescue media differently than the installed system? If the installed system's boot is broken, then he has to have some way to get around that and we don't know what that is. And we still don't know what *does* happen when the installed system fails to boot, just telling us it's broken is not helpful.

I wondered if the output of 'efibootmgr' might be misleading after booting from the tumbleweed DVD. But that also seems far too "far along" to explain why I can't get from BIOS to loading a kernel image.

...

There are some crazy firmwares out there that will default to CSM-BIOS mode boot from optical media. So the first thing is Daniel needs to tell us exactly how the boot fails from the *installed* system. And then he needs to make sure he's using a proper installation media for his rescue boot, made in the officially documented way. And then see what he gets for efibootmgr -v.

The system doesn't get to any stage of booting. The BIOS stops with a message along the lines of "No boot media found, insert a bootable image and press any key to continue" (sorry I don't have physical access to the machine for a couple of days, so I'm going from memory). Before going further, just to clarify, this is my main machine and has booted scores of times since making a clean install of tumbleweed on January 5th (to a fresh SSD). No other OS has been installed. I made no changes to the BIOS settings, the logs show it was using grub2-efi, I just simply applied many updates with zypper and powered off, oblivious to the fact that one of the bootloader writes failed. That's not to say the BIOS isn't doing its own thing, it did wierd things when I made the clean install, such as autoprobing every attached SATA drive and finding old MBR's on the fifth & sixth disks! I'm confident that I've ruled that out this time by disconnecting every SATA data cable except for the primary SSD! And then re-attaching the DVD drive cable to workaround by booting the image off the SSD. I couldn't think of a way to reduce the system further. I don't remember how I burned the DVD, probably from k3b, certainly using openSUSE-Tumbleweed-DVD-x86_64-Snapshot20160101-Media.iso, and I always check the md5sum. The machine is 64bit Intel. 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. Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andrei Borzenkov

16:49

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

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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Chris Murphy

19:12

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

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. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Daniel Morris

20:47

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

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  

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:
<<<<<<<<<<<<<<<<
+ /usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-4.5.0-3-default  
Found initrd image: /boot/initrd-4.5.0-3-default
Found linux image: /boot/vmlinuz-4.5.0-2-default  
Found initrd image: /boot/initrd-4.5.0-2-default
Found openSUSE 13.1 (x86_64) on /dev/mapper/system-root  
done
>>>>>>>>>>>>>>>>

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

Daniel Morris

21:11

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

On Mon, Apr 11, 2016 at 09:47:52PM +0100, Daniel Morris wrote:

...

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

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"

Just in case the output for each partition might help: chunk:/tmp # blkid /dev/sda* /dev/sda: PTUUID="9acb1fa5-67cc-474d-a68b-20a8afb6553f" PTTYPE="gpt" /dev/sda1: SEC_TYPE="msdos" UUID="712B-9AFA" TYPE="vfat" PARTLABEL="primary" PARTUUID="7e019023-b05a-4eab-988c-95fd54bcfbad" /dev/sda2: UUID="c14e8ae5-64f8-4369-8075-c3059d16820f" TYPE="swap" PARTLABEL="primary" PARTUUID="e5b29b30-ab2f-4320-9b0f-bd9a62e77ee6" /dev/sda3: UUID="45a42e23-537a-48a0-ad86-1a5df18c3b52" UUID_SUB="3c73a4b8-36fb-43a3-a43a-3d5ae4b511e4" TYPE="btrfs" PARTLABEL="primary" PARTUUID="7ca50748-b525-4ef0-a9a5-a638db70408e" Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Chris Murphy

12 Apr 12 Apr

03:51

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

On Mon, Apr 11, 2016 at 3:11 PM, Daniel Morris wrote:

...

chunk:/tmp # blkid /dev/sda* /dev/sda: PTUUID="9acb1fa5-67cc-474d-a68b-20a8afb6553f" PTTYPE="gpt" /dev/sda1: SEC_TYPE="msdos" UUID="712B-9AFA" TYPE="vfat" PARTLABEL="primary" PARTUUID="7e019023-b05a-4eab-988c-95fd54bcfbad" /dev/sda2: UUID="c14e8ae5-64f8-4369-8075-c3059d16820f" TYPE="swap" PARTLABEL="primary" PARTUUID="e5b29b30-ab2f-4320-9b0f-bd9a62e77ee6" /dev/sda3: UUID="45a42e23-537a-48a0-ad86-1a5df18c3b52" UUID_SUB="3c73a4b8-36fb-43a3-a43a-3d5ae4b511e4" TYPE="btrfs" PARTLABEL="primary" PARTUUID="7ca50748-b525-4ef0-a9a5-a638db70408e"

What do you get for both? parted /dev/sda u s p tree -L 3 /boot/efi -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Daniel Morris

07:17

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

On Mon, Apr 11, 2016 at 09:51:40PM -0600, Chris Murphy wrote:

...

On Mon, Apr 11, 2016 at 3:11 PM, Daniel Morris wrote:

...
chunk:/tmp # blkid /dev/sda* /dev/sda: PTUUID="9acb1fa5-67cc-474d-a68b-20a8afb6553f" PTTYPE="gpt" /dev/sda1: SEC_TYPE="msdos" UUID="712B-9AFA" TYPE="vfat" PARTLABEL="primary" PARTUUID="7e019023-b05a-4eab-988c-95fd54bcfbad" /dev/sda2: UUID="c14e8ae5-64f8-4369-8075-c3059d16820f" TYPE="swap" PARTLABEL="primary" PARTUUID="e5b29b30-ab2f-4320-9b0f-bd9a62e77ee6" /dev/sda3: UUID="45a42e23-537a-48a0-ad86-1a5df18c3b52" UUID_SUB="3c73a4b8-36fb-43a3-a43a-3d5ae4b511e4" TYPE="btrfs" PARTLABEL="primary" PARTUUID="7ca50748-b525-4ef0-a9a5-a638db70408e"

What do you get for both?

parted /dev/sda u s p

tree -L 3 /boot/efi

chunk:~ # parted /dev/sda u s p Model: ATA Samsung SSD 840 (scsi) Disk /dev/sda: 234441648s Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 2048s 321535s 319488s fat16 primary boot, esp 2 321536s 4530175s 4208640s linux-swap(v1) primary 3 4530176s 234440703s 229910528s btrfs primary chunk:~ # tree -L 3 /boot/efi /boot/efi └── EFI ├── boot │ ├── bootx64.efi │ └── fallback.efi └── opensuse ├── MokManager.efi ├── boot.csv ├── grub.cfg ├── grub.efi ├── grubx64.efi └── shim.efi 3 directories, 8 files Per Neil Rickert's help, the files under /boot/efi appear to match what they should in terms of checksums & contents of grub.cfg. Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andrei Borzenkov

03:28

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

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.

...

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

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

Daniel Morris

15:50

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

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

...

...
...
...
...
...
>>>>>>>>>>

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

Andrei Borzenkov

17:37

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

12.04.2016 18:50, Daniel Morris пишет:

...

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.

Does /sys/firmware.efi exist? What is content of this directory? Do you have /sys/firmware/efi/vars or /sys/firmware/efi/efivars? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Daniel Morris

17:47

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

I had a good look around the "ASROCK UEFI SETUP UTILITY" and I cannot find any option at all to set a legacy or EFI mode. What was interesting was booting with the TW USB key in and then looking at the Boot priorities, in addition to "ACHI: P0: Samsung SSD 840 EVO 1" "AHCI: P4: ATAPI iHAS324 B" I then got an additional: "UEFI: USB" Spookily, having set it to have precedence I then rebooted and also got a fourth option of: "USB: USB 2.0". Anyway, selecting UEFI: USB seemed right, and I was then able to choose Boot Linux System from the TW menu. And, drum roll: chunk:~ # efibootmgr BootCurrent: 0003 Timeout: 2 seconds BootOrder: 0003,0001,0002,0004 Boot0001* Hard Drive Boot0002* CD/DVD Drive Boot0003* UEFI: USB Boot0004 Removable Drive So the good news is I'm currently booted in EFI mode, but it leaves the nagging doubt over what control do I have over the system? I'm at the point of shrugging my shoulders and moaning about daylight saving (well, why not? most other people) - but first the original breakage needs to be fixed. Please can you suggest how best now to proceed to re-write the bootloader and have it stick? Thanks, Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michael Chang

13 Apr 13 Apr

04:27

New subject: [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

Andrei Borzenkov

21 Apr 21 Apr

12:44

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

On Wed, Apr 13, 2016 at 7:27 AM, Michael Chang wrote:

...

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.

Looks like EFI variable store had been wiped out. "rm -rf /sys/firmware/efi/efivars"? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Chris Murphy

11 Apr 11 Apr

18:56

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

On Mon, Apr 11, 2016 at 9:26 AM, Daniel Morris wrote:

...

Before going further, just to clarify, this is my main machine and has booted scores of times since making a clean install of tumbleweed on January 5th (to a fresh SSD). No other OS has been installed. I made no changes to the BIOS settings, the logs show it was using grub2-efi, I just simply applied many updates with zypper and powered off, oblivious to the fact that one of the bootloader writes failed.

OK but your DVD is very clearly booting in CSM-BIOS mode, because efibootmgr command isn't working. If you used this same DVD to install Tumbleweed, chances are it did a CSM-BIOS mode installation, rather than a UEFI one. And that might also explain why the bootloader installation failed, is that it's trying to write legacy bootloader binaries which might fail because of the lack of a BIOS Boot partition, which is required when the firmware is BIOS and the disk is GPT partitioned. So you need to figure out how to boot from this DVD in UEFI mode. Or you need to make USB flash media, which almost certainly will boot in UEFI mode by default.

...

I don't remember how I burned the DVD, probably from k3b, certainly using openSUSE-Tumbleweed-DVD-x86_64-Snapshot20160101-Media.iso, and I always check the md5sum. The machine is 64bit Intel.

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.

They are. The system is booting in CSM-BIOS mode, which is what grub2-i386-pc is for. If it were booting in UEFI mode, it would install grub2-x86_64-efi. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

2933

Age (days ago)

2945

Last active (days ago)

List overview

Download

15 comments

4 participants

participants (4)

Andrei Borzenkov
Chris Murphy
Daniel Morris
Michael Chang

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

tags

participants (4)