[opensuse-factory] EFI bootloader broken during update of Tumbleweed
I've been happily running tumbleweed since the beginning of the year on
x64 with EFI and grub2, but something seems to have killed the
bootloader during a binge on catching up to recent updates. Amongst
these I noticed yast & grub2 updates.
I'd appreciate some help in focussing where to look next, as I seem to
be going around the houses a bit. My current workaround is to boot using
the install DVD, as the UEFI BIOS complains (Asrock H67M-GE/HT P1.40)
that no boot medium is found with just the SSD attached to the SATA bus.
If it were '93 I'd almost think I'd forgotten to reinstall lilo :(
To eliminate confusion I've even tried unplugging all other disks
(the BIOS had a nasty habit of probing and finding an old-style MBR
on the fifth disk before). I've also tried to 'Launch EFI Shell from
filesystem device (Shellx64.efi)' directly from the BIOS - also copying
/boot/efi/EFI/boot/bootx64.efi to Shellx64.efi. I've no idea if that
would have ever worked before, as I've noticed the BIOS has a few
foibles.
The machine should boot from an SSD, partitioned using GPT and with the
default partitioning scheme from yast2 on clean install, namely sda has
partitions 1-3 as vfat, swap & btrfs.
chunk:~ # gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 234441648 sectors, 111.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 9ACB1FA5-67CC-474D-A68B-20A8AFB6553F
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 234441614
Partitions will be aligned on 2048-sector boundaries
Total free space is 2925 sectors (1.4 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 321535 156.0 MiB EF00 primary
2 321536 4530175 2.0 GiB 8300 primary
3 4530176 234440703 109.6 GiB 8300 primary
chunk:~ # mount|grep boot
/dev/sda1 on /boot/efi type vfat
(rw,relatime,fmask=0002,dmask=0002,allow_utime=0020,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
/dev/sda3 on /boot/grub2/x86_64-efi type btrfs (rw,relatime,ssd,space_cache,subvolid=260,subvol=/boot/grub2/x86_64-efi)
/dev/sda3 on /boot/grub2/i386-pc type btrfs (rw,relatime,ssd,space_cache,subvolid=259,subvol=/boot/grub2/i386-pc)
chunk:~ # df -h |grep boot
/dev/sda1 156M 4.6M 152M 3% /boot/efi
/dev/sda3 110G 66G 44G 61% /boot/grub2/x86_64-efi
/dev/sda3 110G 66G 44G 61% /boot/grub2/i386-pc
chunk:/boot/efi/EFI # ls -lR
.:
total 8
drwxrwxr-x 2 root root 4096 Apr 5 13:11 boot
drwxrwxr-x 2 root root 4096 Jan 5 15:58 opensuse
./boot:
total 1204
-rwxrwxr-x 1 root root 1155520 Apr 6 14:54 bootx64.efi
-rwxrwxr-x 1 root root 71672 Apr 6 14:54 fallback.efi
./opensuse:
total 3404
-rwxrwxr-x 1 root root 1159776 Apr 6 14:54 MokManager.efi
-rwxrwxr-x 1 root root 58 Apr 6 14:54 boot.csv
-rwxrwxr-x 1 root root 155 Apr 6 14:54 grub.cfg
-rwxrwxr-x 1 root root 976224 Apr 6 14:54 grub.efi
-rwxrwxr-x 1 root root 175104 Apr 6 12:38 grubx64.efi
-rwxrwxr-x 1 root root 1155520 Apr 6 14:54 shim.efi
I have fsk'd /dev/sda1 from Rescue mode from the DVD too, which prompted
me to 'Remove dirty bit'. It also moaned "CP437:Invalid arg", but
that seemed benign.
/boot/efi/EFI/boot/bootx64.efi and /boot/efi/EFI/opensuse/shim.efi are
the same size and md5sum, not sure if that is intentional?
Working through the logs of changes made during the (big) 'zypper up',
I notice this error in /var/log/pbl.log
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
>>>>>>>>>>>>>>>>
2016-04-05 09:38:29 <1> update-bootloader-9139 run_command.254:
'/usr/lib/bootloader/grub2-efi/config' = 0, output:
<<<<<<<<<<<<<<<<
That corresponds to grub2-x86_64-efi update in zypper.log:
2016-04-05 09:38:29 <1> chunk(31045) [Progress++] ProgressData.cc(report):88 {#712|Installing: grub2-x86_64-efi-2.02~beta3-2.1.x86_64}END
The previous bootloader write (at 09:37:28) corresponded to installing
kernel-default-4.5.0-2.1.x86_64, without error.
I have since tried re-writing the bootloader from yast, and also
forcefully re-installing grub2 & grub2-x86_64-efi before doing it
again. Also subsequent kernel updates (kernel 4.5.0-3 today) pass
happily:
>>>>>>>>>>>>>>>>
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
>>>>>>>>>>>>>>>>
But the net effect is the same. It seems as though the step between EFI
and grub2 is missing. Could anyone suggest where to look next? I don't
think I have a good enough handle on the EFI/GPT loader to know which
utility to file a bug against - assuming its not just finger trouble!
Thanks,
Daniel
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Apr 8, 2016 at 10:46 AM, Andrei Borzenkov
08.04.2016 19:23, Daniel Morris пишет:
But the net effect is the same.
Unfortunately you forgot to tell what happens when you boot.
Just to elaborate on this, we need to know what does happen. Not what doesn't happen.
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.
Yes, be detailed with the expected event or two that happen right before the unexpected event. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/08/2016 11:23 AM, Daniel Morris wrote:
/boot/efi/EFI/boot/bootx64.efi and /boot/efi/EFI/opensuse/shim.efi are the same size and md5sum, not sure if that is intentional?
Yes, those should be the same. Well, that's not quite right. For many users, the first of those will be a Windows boot file. It's a fallback for booting. You should be using the "shim.efi" in a normal boot. I'm going to guess that you are using "btrfs", and your root filesystem is full or near full, causing some package installs to fail. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Apr 08, 2016 at 09:59:50PM -0500, Neil Rickert wrote:
On 04/08/2016 11:23 AM, Daniel Morris wrote:
/boot/efi/EFI/boot/bootx64.efi and /boot/efi/EFI/opensuse/shim.efi are the same size and md5sum, not sure if that is intentional?
Yes, those should be the same. Well, that's not quite right. For many users, the first of those will be a Windows boot file. It's a fallback for booting. You should be using the "shim.efi" in a normal boot.
I'm going to guess that you are using "btrfs", and your root filesystem is full or near full, causing some package installs to fail.
Thanks for the suggestion, but I'd already checked and there's plenty of space: chunk:~ # btrfs filesystem show / Label: none uuid: 45a42e23-537a-48a0-ad86-1a5df18c3b52 Total devices 1 FS bytes used 62.74GiB devid 1 size 109.63GiB used 74.03GiB path /dev/sda3 chunk:~ # btrfs filesystem df / Data, single: total=72.00GiB, used=61.74GiB System, single: total=32.00MiB, used=16.00KiB Metadata, single: total=2.00GiB, used=1021.33MiB GlobalReserve, single: total=352.00MiB, used=0.00B chunk:~ # btrfs filesystem usage / Overall: Device size: 109.63GiB Device allocated: 74.03GiB Device unallocated: 35.60GiB Device missing: 0.00B Used: 62.74GiB Free (estimated): 45.86GiB (min: 45.86GiB) Data ratio: 1.00 Metadata ratio: 1.00 Global reserve: 352.00MiB (used: 0.00B) Data,single: Size:72.00GiB, Used:61.74GiB /dev/sda3 72.00GiB Metadata,single: Size:2.00GiB, Used:1021.33MiB /dev/sda3 2.00GiB System,single: Size:32.00MiB, Used:16.00KiB /dev/sda3 32.00MiB Unallocated: /dev/sda3 35.60GiB Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Apr 08, 2016 at 09:59:50PM -0500, Neil Rickert wrote:
On 04/08/2016 11:23 AM, Daniel Morris wrote:
/boot/efi/EFI/boot/bootx64.efi and /boot/efi/EFI/opensuse/shim.efi are the same size and md5sum, not sure if that is intentional?
Yes, those should be the same. Well, that's not quite right. For many users, the first of those will be a Windows boot file. It's a fallback for booting. You should be using the "shim.efi" in a normal boot.
Oops, I forgot my first question :) Thanks for the clarification. Is there a means of checking the contents of those files? I don't know if the BIOS would use a different response string if shim.efi was corrupt (for example). What I have determined is that my legacy rsnapshot configuration explicitly skipped /boot, so I can't compare with a backup :( Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/11/2016 11:27 AM, Daniel Morris wrote:
Is there a means of checking the contents of those files? I don't know if the BIOS would use a different response string if shim.efi was corrupt (for example).
"shim.efi" should be identical to "/usr/lib64/efi/shim.efi" "grub.efi" should be identical to "/usr/lib64/efi/grub.efi" "grubx64.efi" should be identical to "/boot/grub2/x86_64-efi/core.efi" When I say "identical" -- the time stamp might be different but the md5sum should be the same. "grub.cfg" should be a small text file which you can read yourself. It should set $prefix and load the config file in "/boot/grub2". It uses UUID for this. The exact details will depend on your partitioning. But I think that's not your issue. The first message that you sent today (to the factory list) suggests that you still have the BIOS configured for legacy MBR booting. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Apr 11, 2016 at 12:47:40PM -0500, Neil Rickert wrote:
On 04/11/2016 11:27 AM, Daniel Morris wrote:
Is there a means of checking the contents of those files? I don't know if the BIOS would use a different response string if shim.efi was corrupt (for example).
"shim.efi" should be identical to "/usr/lib64/efi/shim.efi" "grub.efi" should be identical to "/usr/lib64/efi/grub.efi" "grubx64.efi" should be identical to "/boot/grub2/x86_64-efi/core.efi"
When I say "identical" -- the time stamp might be different but the md5sum should be the same.
"grub.cfg" should be a small text file which you can read yourself. It should set $prefix and load the config file in "/boot/grub2". It uses UUID for this. The exact details will depend on your partitioning.
Thanks, all the checksums match and grub.cfg corresponds to the UUID of /dev/sda3. Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
Andrei Borzenkov -
Chris Murphy -
Daniel Morris -
Neil Rickert