November 2020 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1140585] New: cryfs - 0.10.0-1.3 - Illegal instruction on AMD Phenom II X4 965 Processor
by bugzilla_noreply＠novell.com 05 Aug '22

05 Aug '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1140585 Bug ID: 1140585 Summary: cryfs - 0.10.0-1.3 - Illegal instruction on AMD Phenom II X4 965 Processor Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: palica(a)liguros.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Trying to use cryfs on an AMD PC: palica@sucellus:~> cryfs .Private/ 9_Private Illegal instruction (core dumped) palica@sucellus:~> sudo cryfs .Private/ 9_Private -o allow_other Illegal instruction palica@sucellus:~> zypper info cryfs Loading repository data... Reading installed packages... Information for package cryfs: ------------------------------ Repository : Main Repository (OSS) (20190704) Name : cryfs Version : 0.10.0-1.3 Arch : x86_64 Vendor : openSUSE Installed Size : 5.5 MiB Installed : Yes Status : up-to-date Source package : cryfs-0.10.0-1.3.src Summary : CryFS encryption Description : CryFS provides a FUSE-based mount that encrypts file contents, file sizes, metadata and directory structure. It uses encrypted same-size blocks to store both the files themselves and the blocks' relations to one another. These blocks are stored as individual files in the base directory, which can then be synchronized to remote storage (using an external tool). palica@sucellus:~> dmesg|tail [ 667.314215] BTRFS info (device dm-0): qgroup scan completed (inconsistency flag cleared) [ 891.504820] traps: cryfs[17825] trap invalid opcode ip:5596343a66df sp:7ffff48b2638 error:0 in cryfs[559634356000+20f000] [ 911.655522] traps: cryfs[18281] trap invalid opcode ip:5568d347c6df sp:7ffec8878018 error:0 in cryfs[5568d342c000+20f000] palica@sucellus:~> lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 48 bits physical, 48 bits virtual CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: AuthenticAMD CPU family: 16 Model: 4 Model name: AMD Phenom(tm) II X4 965 Processor Stepping: 3 CPU MHz: 800.000 CPU max MHz: 3400.0000 CPU min MHz: 800.0000 BogoMIPS: 6830.70 Virtualization: AMD-V L1d cache: 64K L1i cache: 64K L2 cache: 512K L3 cache: 6144K NUMA node0 CPU(s): 0-3 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt lbrv svm_lock nrip_save I am happy to provide any other info needed. Thanks for help. PS: was already not working with 20190606, I thought that upgrading to latest would solve the issue. IMHO missing some cpu instruction set maybe? -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1160019] New: "Metadata corruption detected at xfs_inode_buf_verify"
by bugzilla_noreply＠novell.com 31 Jul '22

31 Jul '22

http://bugzilla.suse.com/show_bug.cgi?id=1160019 Bug ID: 1160019 Summary: "Metadata corruption detected at xfs_inode_buf_verify" Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: martin.wilck(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- This happened on a fresh Leap15.1 installation on a laptop, SATA SSD, /home file system. Kernel 4.12.14-lp151.28.36-default. > Dec 28 19:02:47 pallas kernel: XFS (dm-0): Metadata corruption detected at xfs_inode_buf_verify+0x72/0xf0 [xfs], xfs_inode block 0x4b860 > Dec 28 19:02:47 pallas kernel: XFS (dm-0): Unmount and run xfs_repair > Dec 28 19:02:47 pallas kernel: XFS (dm-0): First 64 bytes of corrupted metadata buffer: > Dec 28 19:02:47 pallas kernel: ffff8801f164f000: 49 4e 41 ed 03 01 00 00 00 00 04 58 00 00 00 64 INA........X...d > Dec 28 19:02:47 pallas kernel: ffff8801f164f010: 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 ................ > Dec 28 19:02:47 pallas kernel: ffff8801f164f020: 5e 01 34 bd 25 b4 38 63 5d ff e7 a6 01 cc 26 9e ^.4.%.8c].....&. > Dec 28 19:02:47 pallas kernel: ffff8801f164f030: 5d ff e7 a6 01 cc 26 9e 00 00 00 00 00 00 00 34 ].....&........4 The same message is repeated a few times, eventually the FS is mounted r/o, and all kinds of weird failures result. AFAICS in the code in fs/xfs/libxfs/xfs_inode_buf.c, the 15.1 kernel tests nothing but the magic number (byte 0-1, 49 4e) and version (byte 4, 03), so the pattern dumped should be correct. But this is only the 1st inode in the buffer, so subsequent inodes might be bad. However I dumped a full 4k block att offset 0x4b860 and all inode headers seem to be ok so that far. The FS couldn't be umounted, so I rebooted into single-user mode, umounted /home, and ran xfs_repair, which showed nothing of interest: > Phase 1 - find and verify superblock... > - block cache size set to 374008 entries > Phase 2 - using internal log > - zero log...u > zero_log: head block 55736 tail block 55736 > - scan filesystem freespace and inode maps... > - found root inode chunk > Phase 3 - for each AG... > - scan and clear agi unlinked lists... > - process known inodes and perform inode discovery... > - agno = 0 > - agno = 1 > - agno = 2 > - agno = 3 > - process newly discovered inodes... > Phase 4 - check for duplicate blocks... > - setting up duplicate extent list... > - check for inodes claiming duplicate blocks... > - agno = 0 > - agno = 3 > - agno = 2 > - agno = 1 > Phase 5 - rebuild AG headers and trees... > - agno = 0 > - agno = 1 > - agno = 2 > - agno = 3 > - reset superblock... > Phase 6 - check inode connectivity... > - resetting contents of realtime bitmap and summary inodes > - traversing filesystem ... > - agno = 0 > - agno = 1 > - agno = 2 > - agno = 3 > - traversal finished ... > - moving disconnected inodes to lost+found ... > Phase 7 - verify and correct link counts... > > XFS_REPAIR Summary Sat Dec 28 21:02:45 2019 > > Phase Start End Duration > Phase 1: 12/28 21:02:44 12/28 21:02:45 1 second > Phase 2: 12/28 21:02:45 12/28 21:02:45 > Phase 3: 12/28 21:02:45 12/28 21:02:45 > Phase 4: 12/28 21:02:45 12/28 21:02:45 > Phase 5: 12/28 21:02:45 12/28 21:02:45 > Phase 6: 12/28 21:02:45 12/28 21:02:45 > Phase 7: 12/28 21:02:45 12/28 21:02:45 > > Total run time: 1 second > done A very similar was observed some days later after only a couple of minutes of uptime. > Jan 02 10:35:10 pallas.mittagstun.de kernel: XFS (dm-0): Metadata corruption detected at xfs_inode_buf_verify+0x72/0xf0 [xfs], xfs_inode block 0x746b180 > Jan 02 10:35:10 pallas.mittagstun.de kernel: XFS (dm-0): Unmount and run xfs_repair > Jan 02 10:35:10 pallas.mittagstun.de kernel: XFS (dm-0): First 64 bytes of corrupted metadata buffer: > Jan 02 10:35:11 pallas.mittagstun.de kernel: ffff8801dd24d000: 49 4e 81 a4 03 02 00 00 00 00 04 58 00 00 00 64 IN.........X...d > Jan 02 10:35:11 pallas.mittagstun.de kernel: ffff8801dd24d010: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 ................ > Jan 02 10:35:11 pallas.mittagstun.de kernel: ffff8801dd24d020: 5e 07 ba 06 1c 4b f6 68 5e 07 ba 04 18 7a e7 4b ^....K.h^....z.K > Jan 02 10:35:11 pallas.mittagstun.de kernel: ffff8801dd24d030: 5e 07 ba 04 18 7a e7 4b 00 00 00 00 00 00 09 e8 ^....z.K........ I wonder if this is an indication of corrupt hardware, and if yes, what (SSD? CPU? Memory? Other?). The SSD in the laptop is brand new; the respective statement by the vendor is corroborated by SMART data (power-on hours). I have run a simple "surface test" (write pattern & verify) on the affected logical volume with fio, and found no errors (only a single test pass thus far). Perhaps noteworthy, I saw also some BTRFS checksum errors in the logs (from root file system): > Dec 28 19:04:17 pallas kernel: BTRFS warning (device sda2): sda2 checksum verify failed on 158384128 wanted D1502CDD found 7F3B5CF3 level 0 > > Jan 02 10:18:00 pallas.mittagstun.de kernel: BTRFS warning (device sda2): csum failed root 267 ino 232862 off 16384 csum 0xed735e63 expected csum 0x7e1dece1 mirror 1 > > Jan 02 10:28:27 pallas.mittagstun.de kernel: BTRFS warning (device sda2): csum failed root 267 ino 248644 off 0 csum 0x347357c0 expected csum 0x2e8516b0 mirror 1 -- You are receiving this mail because: You are on the CC list for the bug.

2 16

[Bug 1141017] New: installer logs contain user password
by bugzilla_noreply＠novell.com 28 Jul '22

28 Jul '22

http://bugzilla.suse.com/show_bug.cgi?id=1141017 Bug ID: 1141017 Summary: installer logs contain user password Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: msuchanek(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- y2log-djV3TE/YaST2/yast-installation-logs/YaST2/y2log: 'text_userpassword' -- You are receiving this mail because: You are on the CC list for the bug.

2 13

[Bug 1123228] New: Yast2 installation too small fonts on installation menus on HiDPI displays
by bugzilla_noreply＠novell.com 28 Jul '22

28 Jul '22

http://bugzilla.suse.com/show_bug.cgi?id=1123228 Bug ID: 1123228 Summary: Yast2 installation too small fonts on installation menus on HiDPI displays Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: terje(a)nordland-teknikk.no QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- As previous for Leap 15.0, the 15.1 YasT installer fonts are too small (difficult readable) on HiDPI display (XPS 13) already from the first boot menu. -- You are receiving this mail because: You are on the CC list for the bug.

2 13

[Bug 1157912] New: awk: cmd. line:18: warning: regexp escape sequence `\"' is not a known regexp operator
by bugzilla_noreply＠novell.com 28 Jul '22

28 Jul '22

http://bugzilla.suse.com/show_bug.cgi?id=1157912 Bug ID: 1157912 Summary: awk: cmd. line:18: warning: regexp escape sequence `\"' is not a known regexp operator Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: jsrain(a)suse.com Reporter: ohering(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Tumbleweed 20191124, in my autoyast post install no grub.cfg is generated: + grub2-mkconfig -o /boot/grub2/grub.cfg Generating grub configuration file ... Found linux image: /boot/vmlinuz-5.3.12-1-default Found initrd image: /boot/initrd-5.3.12-1-default Found hypervisor: /boot/xen-4.13.0_02-1.gz Found linux image: /boot/vmlinuz-5.3.12-1-default Found initrd image: /boot/initrd-5.3.12-1-default awk: cmd. line:18: warning: regexp escape sequence `\"' is not a known regexp operator awk: cmd. line:18: warning: regexp escape sequence `\"' is not a known regexp operator cp: -r not specified; omitting directory '/boot/' bash -x $(type -P grub2-mkconfig) -o /boot/grub2/grub.cfg ... + echo '### BEGIN /etc/grub.d/20_linux_xen ###' + /etc/grub.d/20_linux_xen Found hypervisor: /boot/xen-4.13.0_02-1.gz Found linux image: /boot/vmlinuz-5.3.12-1-default Found initrd image: /boot/initrd-5.3.12-1-default awk: cmd. line:18: warning: regexp escape sequence `\"' is not a known regexp operator awk: cmd. line:18: warning: regexp escape sequence `\"' is not a known regexp operator cp: -r not specified; omitting directory '/boot/' -- You are receiving this mail because: You are on the CC list for the bug.

2 11

[Bug 1161435] New: 5.4.10-1-default doesn't boot on Panda
by bugzilla_noreply＠novell.com 28 Jul '22

28 Jul '22

http://bugzilla.suse.com/show_bug.cgi?id=1161435 Bug ID: 1161435 Summary: 5.4.10-1-default doesn't boot on Panda Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: armv7 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: schwab(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Loading Linux 5.4.10-1-default ... Loading initial ramdisk ... EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... data abort pc : [<bff6545a>] lr : [<bff65491>] reloc pc : [<8080045a>] lr : [<80800491>] sp : bdf43ed4 ip : 00000000 fp : 00000000 r10: bff65000 r9 : bdf44ed0 r8 : 20071040 r7 : bff656e0 r6 : bff65694 r5 : 000000ad r4 : 200856e0 r3 : 00000000 r2 : 00000050 r1 : bff65690 r0 : abb1aaad Flags: NzCv IRQs off FIQs off Mode SVC_32 Code: ea83428a d1f52010 f856bdf0 40685b04 (f854b2c5) UEFI image [0xbcf20000:0xbcf3bfff] '/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,GPT,216dc377-761b-4afe-a951-fe9dc892afb6,0x800000000000,0xbcf2943000000000)/\efi\boot\bootarm.efi' UEFI image [0xaca8a000:0xad2e7fff] Resetting CPU ... resetting ... U-Boot SPL 2019.01 (Mar 18 2019 - 11:17:54 +0000) OMAP4430-GP ES2.2 Trying to boot from MMC1 SPL: Please implement spl_start_uboot() for your board SPL: Direct Linux boot not active! U-Boot 2019.01 (Mar 18 2019 - 11:17:54 +0000) CPU : OMAP4430-GP ES2.2 Board: OMAP4 Panda I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment Net: No ethernet found. Hit any key to stop autoboot: 0 -- You are receiving this mail because: You are on the CC list for the bug.

2 5

[Bug 1157019] New: RPi3: no grub menu on serial console
by bugzilla_noreply＠novell.com 28 Jul '22

28 Jul '22

http://bugzilla.suse.com/show_bug.cgi?id=1157019 Bug ID: 1157019 Summary: RPi3: no grub menu on serial console Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: jsrain(a)suse.com Reporter: mbrugger(a)suse.com QA Contact: jsrain(a)suse.com CC: afaerber(a)suse.com, guillaume.gardet(a)arm.com, jlee(a)suse.com, yousaf.kaukab(a)suse.com Found By: --- Blocker: --- When booting RPi3 image without a monitor connected, the system does not show any output on the serial console when starting grub. As a result we can't change the kernel console parameter neither. Expected behaviour: A message like: "Please press 't' to show the boot menu on this console" should be shown on the serial console that will allow us to switch to serial console grub menu. Actual behaviour: No output from grub2 on the serial console. Kernel get's started without the posibility to interact with grub2 through the serial console. Tested with: openSUSE-Tumbleweed-JeOS.aarch64-15.1.0-RaspberryPi-Build9.29.raw.xz from Virtualization:Appliances:Images:openSUSE-Tumbleweed/kiwi-templates-JeOS -- You are receiving this mail because: You are on the CC list for the bug.

2 7

[Bug 1163599] New: generated grub.cfg points to non-existent kernel images
by bugzilla_noreply＠novell.com 28 Jul '22

28 Jul '22

http://bugzilla.suse.com/show_bug.cgi?id=1163599 Bug ID: 1163599 Summary: generated grub.cfg points to non-existent kernel images Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: jsrain(a)suse.com Reporter: mcepl(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Created attachment 830064 --> http://bugzilla.suse.com/attachment.cgi?id=830064&action=edit Output of supportconfig grub2-mkconfig generates invalid /boot/grub2/grub.cfg, because it expects both kernel image and ramdisk image to be in some kind of BTRFS snapshot, not directly in the /boot directory itself. See attached output of supportconfig and generated grub.cfg. -- You are receiving this mail because: You are on the CC list for the bug.

2 4

[Bug 1156441] New: grub2-install does not setup env_block for btrfs
by bugzilla_noreply＠novell.com 28 Jul '22

28 Jul '22

http://bugzilla.suse.com/show_bug.cgi?id=1156441 Bug ID: 1156441 Summary: grub2-install does not setup env_block for btrfs Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: mchang(a)suse.com Reporter: fvogt(a)suse.com QA Contact: jsrain(a)suse.com CC: arvidjaar(a)gmail.com Found By: --- Blocker: --- Some grub2 configs rely on being able to read and write certain environment variables (like health_checker_flag), but this only works if grub2-editenv was called previously. grub2-install should take care of setting up the env_block for systems which need it, if it doesn't exist yet. -- You are receiving this mail because: You are on the CC list for the bug.

2 22

[Bug 1148809] New: yast2 bootloader fails when lvmcache is in use
by bugzilla_noreply＠novell.com 28 Jul '22

28 Jul '22

http://bugzilla.suse.com/show_bug.cgi?id=1148809 Bug ID: 1148809 Summary: yast2 bootloader fails when lvmcache is in use Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: aspiers(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- [ Originally reported at: https://github.com/openSUSE/libstorage-ng/issues/664 ] I added an lvmcache cachepool to the LV for my root filesystem, and now YaST's bootloader module fails due to not being able to detect the root filesystem. How to reproduce: 1. Start with lvmcache disabled (i.e. normal LVM / filesystem, backed by mdraid) 2. Observe `yast2 bootloader` works fine 3. Activate the cache LV which I previously setup: lvconvert --type cache --cachepool system/cache-root system/root 4. Run `yast2 bootloader` again 5. Observe that an Error dialog pops up, filled with a) lots of (apparently harmless) warnings about an fd leak, and b) an error right at the end showing that it cannot find the disk by LVM UUID: Execution of command "[["/usr/bin/grub2-editenv", "list"]]" failed. Exit code: 1 Error output: File descriptor 7 (pipe:[4428632]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 8 (pipe:[4428632]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 9 (pipe:[4428633]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 10 (pipe:[4428633]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 7 (pipe:[4428632]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 8 (pipe:[4428632]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 9 (pipe:[4428633]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 10 (pipe:[4428633]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 7 (pipe:[4428632]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 8 (pipe:[4428632]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 9 (pipe:[4428633]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 10 (pipe:[4428633]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 7 (pipe:[4428632]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 8 (pipe:[4428632]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 9 (pipe:[4428633]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 10 (pipe:[4428633]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 7 (pipe:[4428632]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 8 (pipe:[4428632]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 9 (pipe:[4428633]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 10 (pipe:[4428633]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 7 (pipe:[4428632]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 8 (pipe:[4428632]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 9 (pipe:[4428633]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 10 (pipe:[4428633]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 7 (pipe:[4428632]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 8 (pipe:[4428632]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 9 (pipe:[4428633]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 10 (pipe:[4428633]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 7 (pipe:[4428632]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 8 (pipe:[4428632]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 9 (pipe:[4428633]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv File descriptor 10 (pipe:[4428633]) leaked on vgs invocation. Parent PID 18319: /usr/bin/grub2-editenv /usr/bin/grub2-editenv: error: disk `lvmid/m4f2UJ-widt-pyk9-QkKY-KyJQ-pbwq-V8zzwL/MsUIK0-r51d-MJck-aQwk-ZiAS-A2BI-XdT2vl' not found. 6. Click OK (the only available button) on this dialog 7. Now I see the same dialog I originally reported at the top of this issue. 8. Click `Continue` 9. Observe another dialog: Probing file system with UUID cad8b62c-88e5-4c19-ad24-06e75c0a8987 failed Unexpected situation found in the system. Click below to see more details (English only). Continue despite the error? Continue Abort Details 10. Clicking `Details` shows: device not found, name:/dev/mapper/system-root 11. Click `OK` then `Continue` to continue despite the error 12. Observe another error dialog: Internal error. Please report a bug report with logs. Run save_y2logs to get complete logs. Caller: /usr/share/YaST2/modules/BootStorage.rb:246:in `detect_disks' Details: Missing '/' mount point 13. Click `OK` and yast exits. Clearly there is some side effect of attaching the cache LV which somehow confuses the disk detection code. I see in the error above that it's looking for `lvmid/m4f2UJ-widt-pyk9-QkKY-KyJQ-pbwq-V8zzwL/MsUIK0-r51d-MJck-aQwk-ZiAS-A2BI-XdT2vl`, which seems to correspond OK to the uuids shown here: # dmsetup info system-root Name: system-root State: ACTIVE Read Ahead: 1024 Tables present: LIVE Open count: 1 Event number: 0 Major, minor: 254, 0 Number of targets: 1 UUID: LVM-m4f2UJwidtpyk9QkKYKyJQpbwqV8zzwLMsUIK0r51dMJckaQwkZiASA2BIXdT2vl # lvdisplay system/root --- Logical volume --- LV Path /dev/system/root LV Name root VG Name system LV UUID MsUIK0-r51d-MJck-aQwk-ZiAS-A2BI-XdT2vl LV Write Access read/write LV Creation host, time install, 2018-12-31 13:15:41 +0000 LV Cache pool name cache-root LV Cache origin name root_corig LV Status available # open 1 LV Size 500.00 GiB Cache used blocks 0.04% Cache metadata blocks 6.47% Cache dirty blocks 0.00% Cache read hits/misses 2 / 15 Cache wrt hits/misses 653 / 572 Cache demotions 0 Cache promotions 336 Current LE 128000 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 1024 Block device 254:0 -- You are receiving this mail because: You are on the CC list for the bug.

2 12