[Bug 1148809] New: yast2 bootloader fails when lvmcache is in use
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@suse.de Reporter: aspiers@suse.com QA Contact: jsrain@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.
http://bugzilla.suse.com/show_bug.cgi?id=1148809 http://bugzilla.suse.com/show_bug.cgi?id=1148809#c1 --- Comment #1 from Adam Spiers <aspiers@suse.com> --- Created attachment 816255 --> http://bugzilla.suse.com/attachment.cgi?id=816255&action=edit Output from save_y2logs The relevant run of yast2 bootloader can be seen starting at 2019-08-29 12:42:15 in the unpacked YaST2/y2log file. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1148809 http://bugzilla.suse.com/show_bug.cgi?id=1148809#c4 Josef Reidinger <jreidinger@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jreidinger@suse.com, | |mchang@suse.com Flags| |needinfo?(mchang@suse.com) --- Comment #4 from Josef Reidinger <jreidinger@suse.com> --- Michael - before we start with debugging deeper, do you have idea for that output of grub2-editenv? is lvmcache supported at all by grub2? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1148809 http://bugzilla.suse.com/show_bug.cgi?id=1148809#c5 --- Comment #5 from Michael Chang <mchang@suse.com> --- (In reply to Josef Reidinger from comment #4)
Michael - before we start with debugging deeper, do you have idea for that output of grub2-editenv? is lvmcache supported at all by grub2?
The lvm cachepool is not known by grub, thus should be ignored.
grub2-editenv: info: unknown LVM type cache-pool+METADATA_FORMAT. grub2-editenv: info: unknown LVM type cache-pool+METADATA_FORMAT.
My gut feeling is telling me it should be enough to ignore cachepool lv going forward, but something looks wrong in grub as it seems not that easy. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1148809 http://bugzilla.suse.com/show_bug.cgi?id=1148809#c6 Michael Chang <mchang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aspiers@suse.com Flags|needinfo?(mchang@suse.com) |needinfo?(aspiers@suse.com) --- Comment #6 from Michael Chang <mchang@suse.com> --- Hi Adam, The test package is building in obs project below. For some reason the building stayed in scheduled state for a long time, but it will be successful as it has been tested locally. https://build.opensuse.org/package/show/home:michael-chang:lvm_cachepool/gru... It fixed the lvm cache logical volume detection by processing it to the list of known logical volumes, and during grub runtime, the associated origin volume is used because all logical volumes are offline this cache should not containing any useful data. Please help to verify the package once the build is finished. FYI I will be off tomorrow because of national holiday in my country. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1148809 http://bugzilla.suse.com/show_bug.cgi?id=1148809#c7 Adam Spiers <aspiers@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS Flags|needinfo?(aspiers@suse.com) | --- Comment #7 from Adam Spiers <aspiers@suse.com> --- With your test package grub2-editenv runs fine with exit code 0 (although the fd leakage is still there). However as expected, the original problem with libstorage-ng as stated in https://github.com/openSUSE/libstorage-ng/issues/664 remains. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1148809 http://bugzilla.suse.com/show_bug.cgi?id=1148809#c8 --- Comment #8 from Michael Chang <mchang@suse.com> --- (In reply to Adam Spiers from comment #7)
With your test package grub2-editenv runs fine with exit code 0 (although the fd leakage is still there).
The fd leakage should be harmless, however I'll see if I could come up with a fix as well.
However as expected, the original problem with libstorage-ng as stated in https://github.com/openSUSE/libstorage-ng/issues/664 remains.
I am not clear on this part "original problem". Was it saying grub2-editenv still fail in yast bootloader ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1148809 http://bugzilla.suse.com/show_bug.cgi?id=1148809#c9 --- Comment #9 from Michael Chang <mchang@suse.com> --- (In reply to Michael Chang from comment #8)
(In reply to Adam Spiers from comment #7)
With your test package grub2-editenv runs fine with exit code 0 (although the fd leakage is still there).
The fd leakage should be harmless, however I'll see if I could come up with a fix as well.
I'm afraid it's not in grub2-editenv, as the leaked descriptor could originate from yast bootloader, or any parent process invoking grub2-editenv, which in turn invokes vgs. I couldn't reproduce with running grub2-editenv solely from command line, but with this testing shell script it is reproducible.
#!/bin/sh exec 4<>/tmp/test grub2-editenv list
IMHO "leaked" is misleading, just some fds left opening at the time calling vgs/lvs, which shouldn't be an issue .. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1148809 http://bugzilla.suse.com/show_bug.cgi?id=1148809#c10 --- Comment #10 from Adam Spiers <aspiers@suse.com> --- (In reply to Michael Chang from comment #8)
(In reply to Adam Spiers from comment #7)
With your test package grub2-editenv runs fine with exit code 0 (although the fd leakage is still there).
The fd leakage should be harmless,
Let's call it "*mostly* harmless" ;-) Any unnecessary pollution of log files makes true errors harder to spot, therefore it is still harmful to a small extent.
however I'll see if I could come up with a fix as well.
That would be great, thanks!
However as expected, the original problem with libstorage-ng as stated in https://github.com/openSUSE/libstorage-ng/issues/664 remains.
I am not clear on this part "original problem". Was it saying grub2-editenv still fail in yast bootloader ?
No, the original problem is that libstorage-ng can't correctly recognise cached LVs since the first byte of their lv_attr is 'C', so it gives them LvType::UNKNOWN and then fails to detect the filesystem. This is explained in detail in the original report at the top of https://github.com/openSUSE/libstorage-ng/issues/664 I have proposed a simple fix in my latest comment there. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1148809 http://bugzilla.suse.com/show_bug.cgi?id=1148809#c11 --- Comment #11 from Michael Chang <mchang@suse.com> --- (In reply to Adam Spiers from comment #10)
(In reply to Michael Chang from comment #8)
(In reply to Adam Spiers from comment #7)
With your test package grub2-editenv runs fine with exit code 0 (although the fd leakage is still there).
The fd leakage should be harmless,
Let's call it "*mostly* harmless" ;-) Any unnecessary pollution of log files makes true errors harder to spot, therefore it is still harmful to a small extent.
It may need the assist from YaST team to diagnose the leak, as it turns out all parents to the vgs sub-process are suspicious. I'd suggest to open another bug report for tracking if you think it worth to do so.
No, the original problem is that libstorage-ng can't correctly recognise cached LVs since the first byte of their lv_attr is 'C', so it gives them LvType::UNKNOWN and then fails to detect the filesystem. This is explained in detail in the original report at the top of https://github.com/openSUSE/libstorage-ng/issues/664
I have proposed a simple fix in my latest comment there.
Thanks a lot for your information. I am going to submit it as the patch seems harmless to other scenarios and we can move forward. Also a copy to upstream for comments. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1148809 http://bugzilla.suse.com/show_bug.cgi?id=1148809#c12 --- Comment #12 from Adam Spiers <aspiers@suse.com> --- (In reply to Michael Chang from comment #11)
(In reply to Adam Spiers from comment #10)
(In reply to Michael Chang from comment #8)
(In reply to Adam Spiers from comment #7)
With your test package grub2-editenv runs fine with exit code 0 (although the fd leakage is still there).
The fd leakage should be harmless,
Let's call it "*mostly* harmless" ;-) Any unnecessary pollution of log files makes true errors harder to spot, therefore it is still harmful to a small extent.
It may need the assist from YaST team to diagnose the leak, as it turns out all parents to the vgs sub-process are suspicious. I'd suggest to open another bug report for tracking if you think it worth to do so.
OK, submitted as bug #1151960.
No, the original problem is that libstorage-ng can't correctly recognise cached LVs since the first byte of their lv_attr is 'C', so it gives them LvType::UNKNOWN and then fails to detect the filesystem. This is explained in detail in the original report at the top of https://github.com/openSUSE/libstorage-ng/issues/664
I have proposed a simple fix in my latest comment there.
Thanks a lot for your information. I am going to submit it as the patch seems harmless to other scenarios and we can move forward. Also a copy to upstream for comments.
That's great, thanks! I'm happy to test any package you build with the patch. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1148809 http://bugzilla.suse.com/show_bug.cgi?id=1148809#c13 Knut Alejandro Anderssen González <knut.anderssen@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |knut.anderssen@suse.com Assignee|yast2-maintainers@suse.de |mchang@suse.com --- Comment #13 from Knut Alejandro Anderssen González <knut.anderssen@suse.com> --- (In reply to Michael Chang from comment #11)
(In reply to Adam Spiers from comment #10)
(In reply to Michael Chang from comment #8)
(In reply to Adam Spiers from comment #7)
With your test package grub2-editenv runs fine with exit code 0 (although the fd leakage is still there).
The fd leakage should be harmless,
Let's call it "*mostly* harmless" ;-) Any unnecessary pollution of log files makes true errors harder to spot, therefore it is still harmful to a small extent.
It may need the assist from YaST team to diagnose the leak, as it turns out all parents to the vgs sub-process are suspicious. I'd suggest to open another bug report for tracking if you think it worth to do so.
The other bug was already created and fixed by Jozef
No, the original problem is that libstorage-ng can't correctly recognise cached LVs since the first byte of their lv_attr is 'C', so it gives them LvType::UNKNOWN and then fails to detect the filesystem. This is explained in detail in the original report at the top of https://github.com/openSUSE/libstorage-ng/issues/664
I have proposed a simple fix in my latest comment there.
Thanks a lot for your information. I am going to submit it as the patch seems harmless to other scenarios and we can move forward. Also a copy to upstream for comments.
Assigning this one to Michael as it seems there is nothing pending from us ;) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1148809 https://bugzilla.suse.com/show_bug.cgi?id=1148809#c14 Benjamin Brunner <bbrunner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|mchang@suse.com |bootloader-maintainers@suse | |.de --- Comment #14 from Benjamin Brunner <bbrunner@suse.com> --- Bulk-re-assigning to the new bootloader-maintainers@suse.de group. -- You are receiving this mail because: You are on the CC list for the bug.
participants (2)
-
bugzilla_noreply＠novell.com -
bugzilla_noreply＠suse.com