Comment # 13 on bug 989871 from Neil Rickert

>I am a little confused.

Sorry about that.  I guess I did not give enough detail.

I use the particular computer for testing.  I have several linux versions
installed, including both Tumbleweed and 42.2.

My tests all had secure-boot enabled.

The boot path then should be:

firmware --> shim.efi --> grub.efi which loads "grub.cfg".
Here, "shim.efi", "grub.efi" and "grub.cfg" are all in
"/boot/efi/EFI/opensuse".

Each install takes over booting.  So I keep backups of those three files so
that I can restore them as needed.

When those three files come from the new 42.2 install, then everything is fine.
When those three files come from Tumbleweed (snapshot 20160828), I can boot
into Tumbleweed, but I run into lvmetad issues if I try to boot into 42.2

For the Tumbleweed grub menu entry, I use the following to boot 42.2:
 --- cut here ---
### Entry to boot 42.2 on sdb4
menuentry "configfile for linux on /dev/sdb4 (42.2)"  {
        set bootdir='hd1,gpt4'
        search --fs-uuid --set=bootdir 723d6d1e-6b1f-410c-bd53-87e944c288e0
        configfile (${bootdir})/boot/grub2/grub.cfg
}
 --- cut here ---
The UUID is for "/dev/sdb4" which is "/boot" for 42.2.  And there is a symlink
so that "/boot/grub2/grub.cfg" works relative to "/boot".  So I am really using
the 42.2 boot menu via a "configfile" command.  It does work, in that the
kernel is loaded.  But the home volume in my encrypted LVM is not made
accessible and boot ends in emergency mode.

No, I don't understand it either.  All LVM operations should be initiated by
the "initrd", and that happens after grub is no longer doing anything.  So I
agree that it does not make sense.

Nevertheless, using the three boot path files for 42.2 was 100% effective when
booting.  And using those files from Tumbleweed failed every time (at least 4
attempts) yesterday.

But now a new event.  I tried again this morning, and it booted successfully
using the basic boot files from Tumbleweed.  So this is quite strange.