[opensuse] symbol "grub_tmp_measure" after update
Hi list, I have a computer that I upgraded 42.2->42.3 a month ago (without issues). It was powered off since then. Today I rebooted it (again, without issues). I ran a 'zypper up', and rebooted - and now it throws me at grub-rescue with the mentioned error symbol "grub_tmp_measure" not found. grub has been updated during this run. Some quick googling revealed TW was having similar issues about a year ago, still haven't found the main reason then - maybe someone remembers faster than I read? Does it have some kernel relation? That's the only real difference from a standard 42.3, I run a 4.11 kernel (still coming from the 42.2 install, I needed it due to some HW) Especially some quick recovery hints welcome :o -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Mar 30, 2018 at 2:24 PM, Peter Suetterlin <pit@astro.su.se> wrote:
Hi list,
I have a computer that I upgraded 42.2->42.3 a month ago (without issues). It was powered off since then. Today I rebooted it (again, without issues).
I ran a 'zypper up', and rebooted - and now it throws me at grub-rescue with the mentioned error symbol "grub_tmp_measure" not found. grub has been updated during this run.
This means grub2 core.img (the binary loaded by firmware) was not updated during install and does not match content of /boot/grub2. Usual cause us mismatch between bootloader location configured in openSUSE and BIOS boot device.
Some quick googling revealed TW was having similar issues about a year ago, still haven't found the main reason then - maybe someone remembers faster than I read?
Does it have some kernel relation? That's the only real difference from a standard 42.3, I run a 4.11 kernel (still coming from the 42.2 install, I needed it due to some HW)
Especially some quick recovery hints welcome :o
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
On Fri, Mar 30, 2018 at 2:24 PM, Peter Suetterlin <pit@astro.su.se> wrote:
Hi list,
I have a computer that I upgraded 42.2->42.3 a month ago (without issues). It was powered off since then. Today I rebooted it (again, without issues).
I ran a 'zypper up', and rebooted - and now it throws me at grub-rescue with the mentioned error symbol "grub_tmp_measure" not found. grub has been updated during this run.
This means grub2 core.img (the binary loaded by firmware) was not updated during install and does not match content of /boot/grub2. Usual cause us mismatch between bootloader location configured in openSUSE and BIOS boot device.
Hmm, not sure if it is using UEFI/secureboot. It's the only option. Should that missmatch have produced an error during update? There wasn't one. Just tried booting from 42.3 install stick, which failed!? WTF... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Peter Suetterlin wrote:
Just tried booting from 42.3 install stick, which failed!? WTF...
Head -> Wall maybe I should not try booting from the ARM bootstick, and use x86 instead :o -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Mar 30, 2018 at 2:58 PM, Peter Suetterlin <pit@astro.su.se> wrote:
Andrei Borzenkov wrote:
On Fri, Mar 30, 2018 at 2:24 PM, Peter Suetterlin <pit@astro.su.se> wrote:
Hi list,
I have a computer that I upgraded 42.2->42.3 a month ago (without issues). It was powered off since then. Today I rebooted it (again, without issues).
I ran a 'zypper up', and rebooted - and now it throws me at grub-rescue with the mentioned error symbol "grub_tmp_measure" not found. grub has been updated during this run.
This means grub2 core.img (the binary loaded by firmware) was not updated during install and does not match content of /boot/grub2. Usual cause us mismatch between bootloader location configured in openSUSE and BIOS boot device.
Hmm, not sure if it is using UEFI/secureboot. It's the only option.
Not sure I understand this sentence. Are you using EFI? In this case show output of "efibootmgr -v".
Should that missmatch have produced an error during update?
No. Update simply installs bootloader where configuration tells it; it has no way to know what BIOS actually tries to load. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
On Fri, Mar 30, 2018 at 2:58 PM, Peter Suetterlin <pit@astro.su.se> wrote:
Andrei Borzenkov wrote:
This means grub2 core.img (the binary loaded by firmware) was not updated during install and does not match content of /boot/grub2. Usual cause us mismatch between bootloader location configured in openSUSE and BIOS boot device.
Hmm, not sure if it is using UEFI/secureboot. It's the only option.
Not sure I understand this sentence. Are you using EFI? In this case show output of "efibootmgr -v".
Sorry, I was a bit confuse. There is only the Leap42.3 on, so I had not set up UEFI secureboot. It's in legacy mode. HOWEVER: After I finally used the proper boot stick I have access to the system again. And 0:rescue:~ # efibootmgr -v BootCurrent: 0018 Timeout: 1 seconds BootOrder: 0018,0019,001A,0010,0011,0012,0013,0014,0015,0016,0017 Boot0010 IBA XE Slot 0100 v2358 BBS(Network,,0x0)..BO Boot0011 IBA XE Slot 0101 v2358 BBS(Network,,0x0)..BO Boot0012 WDC WD60EFRX-68MYMN1 BBS(HD,,0x0)..BO Boot0013 WDC WD60EFRX-68MYMN1 BBS(HD,,0x0)..BO Boot0014 WDC WD60EFRX-68MYMN1 BBS(HD,,0x0)..BO Boot0015 WDC WD60EFRX-68MYMN1 BBS(HD,,0x0)..BO Boot0016 WDC WD60EFRX-68MYMN1 BBS(HD,,0x0)..BO Boot0017 WDC WD60EFRX-68MYMN1 BBS(HD,,0x0)..BO Boot0018* UEFI: InnostorInnostor 1.00, Partition 1 PciRoot(0x0)/Pci(0x14,0x0)/USB(4,0)/HD(1,MBR,0x1b681c50,0x107c,0x1e84)..BO Boot0019* InnostorInnostor 1.00 BBS(HD,,0x0)..BO Boot001A* Samsung SSD 950 PRO 512GB BBS(HD,,0x0)..BO Why is there an entry for it? Hmmm.... As I said, the storage CSM is setup for 'legacy only', though general security setting allows both. My partitioning is somewhat special though - maybe that is one reason? /dev/nvme0n1p1 2048 66074623 66072576 31.5G 5 Extended /dev/nvme0n1p2 * 66074624 149966847 83892224 40G 83 Linux /dev/nvme0n1p3 149966848 1000215215 850248368 405.4G 83 Linux /dev/nvme0n1p5 4096 6295551 6291456 3G 83 Linux /dev/nvme0n1p6 6297600 12589055 6291456 3G 83 Linux /dev/nvme0n1p7 12591104 66074623 53483520 25.5G 82 Linux swap / Solaris nvme0n1p1 used to be swap, but I needed two additional partitions for setting up logdevs for two huge XFS RAIDS... nvme0n1p2 is the actual system partition. Trying to figure out which settings are wrong now... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Mar 30, 2018 at 3:58 PM, Peter Suetterlin <pit@astro.su.se> wrote:
After I finally used the proper boot stick I have access to the system again. And 0:rescue:~ # efibootmgr -v BootCurrent: 0018 Timeout: 1 seconds BootOrder: 0018,0019,001A,0010,0011,0012,0013,0014,0015,0016,0017 Boot0010 IBA XE Slot 0100 v2358 BBS(Network,,0x0)..BO Boot0011 IBA XE Slot 0101 v2358 BBS(Network,,0x0)..BO Boot0012 WDC WD60EFRX-68MYMN1 BBS(HD,,0x0)..BO Boot0013 WDC WD60EFRX-68MYMN1 BBS(HD,,0x0)..BO Boot0014 WDC WD60EFRX-68MYMN1 BBS(HD,,0x0)..BO Boot0015 WDC WD60EFRX-68MYMN1 BBS(HD,,0x0)..BO Boot0016 WDC WD60EFRX-68MYMN1 BBS(HD,,0x0)..BO Boot0017 WDC WD60EFRX-68MYMN1 BBS(HD,,0x0)..BO Boot0018* UEFI: InnostorInnostor 1.00, Partition 1 PciRoot(0x0)/Pci(0x14,0x0)/USB(4,0)/HD(1,MBR,0x1b681c50,0x107c,0x1e84)..BO Boot0019* InnostorInnostor 1.00 BBS(HD,,0x0)..BO
This is probably your USB stick added automatically
Boot001A* Samsung SSD 950 PRO 512GB BBS(HD,,0x0)..BO
This is legacy boot which I assume is your default one according to BootOrder.
Why is there an entry for it? Hmmm....
As I said, the storage CSM is setup for 'legacy only', though general security setting allows both.
My partitioning is somewhat special though - maybe that is one reason?
/dev/nvme0n1p1 2048 66074623 66072576 31.5G 5 Extended /dev/nvme0n1p2 * 66074624 149966847 83892224 40G 83 Linux /dev/nvme0n1p3 149966848 1000215215 850248368 405.4G 83 Linux /dev/nvme0n1p5 4096 6295551 6291456 3G 83 Linux /dev/nvme0n1p6 6297600 12589055 6291456 3G 83 Linux /dev/nvme0n1p7 12591104 66074623 53483520 25.5G 82 Linux swap / Solaris
nvme0n1p1 used to be swap, but I needed two additional partitions for setting up logdevs for two huge XFS RAIDS...
nvme0n1p2 is the actual system partition.
Trying to figure out which settings are wrong now...
RESULTS.txt from https://github.com/arvidjaar/bootinfoscript could be helpful. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
On Fri, Mar 30, 2018 at 3:58 PM, Peter Suetterlin <pit@astro.su.se> wrote:
After I finally used the proper boot stick I have access to the system again. And 0:rescue:~ # efibootmgr -v
Boot0018* UEFI: InnostorInnostor 1.00, Partition 1 PciRoot(0x0)/Pci(0x14,0x0)/USB(4,0)/HD(1,MBR,0x1b681c50,0x107c,0x1e84)..BO Boot0019* InnostorInnostor 1.00 BBS(HD,,0x0)..BO
This is probably your USB stick added automatically
Correct.
Boot001A* Samsung SSD 950 PRO 512GB BBS(HD,,0x0)..BO
This is legacy boot which I assume is your default one according to BootOrder.
Ah, so internally it uses the efi-entries also for legacy. Didn't know that..
RESULTS.txt from https://github.com/arvidjaar/bootinfoscript could be helpful.
I had tried running yast2 bootloader first. That had very weird settings, telling to install to a disk that resolved to /dev/sda. That disk is part of a RAID set. Just hope it didn't mess up that one... I entered correct values and wanted to install bootmanager - and it failed, complaining device.map has too many entries. Oh hell. So I had a look at /etc/default/grub* and /boot/grub2/device* first, which luckily had *.old files around the contained the previous (correct) settings. The device.map contained all 22 'normal' disks of this system (16 SSD plus 6 HDD), but not the actual system disk, an NVMe one. So no wonder the install failed. So reducing device.map to a single entry (hd0) /dev/nvme0n1 and also /etc/default/grub_installdevice to the old values I could now re-run the yast2 bootloader and properly install it. I'll see if I can spot the moment when those files were changed, but I don't keep too many snapshots around. In any case MANY thanks for your assistance! -- Dr. Peter "Pit" Suetterlin http://www.astro.su.se/~pit Institute for Solar Physics Tel.: +34 922 405 590 (Spain) P.Suetterlin@royac.iac.es +46 8 5537 8559 (Sweden) Peter.Suetterlin@astro.su.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
Andrei Borzenkov -
Peter Suetterlin