http://bugzilla.opensuse.org/show_bug.cgi?id=989871 http://bugzilla.opensuse.org/show_bug.cgi?id=989871#c1 --- Comment #1 from Neil Rickert --- I have since installed Alpha 3 on a different computer. Again, I used an encrypted LVM, mounting the home volume to "/xhome". This time, everything worked. The system did not go into emergency mode. I'm not sure what's the difference. However, on the first computer (where I did have a problem) there are actually two encrypted LVMs (only one used by Alpha3). Possibly that is what confuses things. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=989871 http://bugzilla.opensuse.org/show_bug.cgi?id=989871#c5 --- Comment #5 from Neil Rickert --- Created attachment 685640 --> http://bugzilla.opensuse.org/attachment.cgi?id=685640&action=edit Typescript "transcript file" with most of the requested information. There no unusual network device. I generated the requested output, except "/etc/lvm/lvm.conf". That file is as originally installed, except the change to "use_lvmetad = 0". After generating the transcript file, I edited "lvm.conf" and set "use_lvmetad = 1" (as in the originally installed version). My plan was to reboot, and rerun those commands from emergency mode. Strangely, the system booted properly this time. It did not go into emergency mode. The I appended to the "typescript" and reran "lsblk", as the order for the LVM components was now changed. I have since rebooted a second time, and again it did not go into emergency mode. I do not know what changed. The only significant change that I have made was to install "fvwm2" and "fvwm-themes". -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=989871 http://bugzilla.opensuse.org/show_bug.cgi?id=989871#c8 --- Comment #8 from Neil Rickert --- Created attachment 685935 --> http://bugzilla.opensuse.org/attachment.cgi?id=685935&action=edit typescript (transcript file) from emergency mode, 7/28/2016 It just went into emergency mode again on a recent boot. I hope the transcript file shows what you wanted. I also listed "/dev/mapper" which show that the root2 and swap volumes have been mapped, but the home volume has not been mapped. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=989871 http://bugzilla.opensuse.org/show_bug.cgi?id=989871#c13 --- Comment #13 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. -- You are receiving this mail because: You are on the CC list for the bug.