|
Bugzilla – Full Text Bug Listing |
| Summary: | WSL: yast2-users: lsblk doesn't work in WSL | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Ludwig Nussel <lnussel> |
| Component: | YaST2 | Assignee: | YaST Team <yast-internal> |
| Status: | RESOLVED FIXED | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | kanderssen, leslie.satenstein |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| URL: | https://trello.com/c/0qw1I9fL | ||
| See Also: | http://bugzilla.suse.com/show_bug.cgi?id=1154962 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | yast logs | ||
|
Description
Ludwig Nussel
2019-10-16 15:17:50 UTC
Created attachment 821715 [details]
yast logs
Just for record and as was commented on IRC: We should try to detect that we are running on WSL or WSL2 ommiting the importat in that case. Added the bug to our Incoming Trello Board in order to be planning / implemented in future sprints. decided to make it browse /mnt instead. So the feature is still kind of useful the pr is still open. any plans to merge it? Hi Ludwig, I used lsblk from the command line, not from yast. And as I mentioned in my post, a system update solved the problem. I did not find a way to close or merge the two issues. Since Yast invokes lsblk, I would just change the post here and to my original first post to solved. update of January 9,2010 replaced lsblk with a new functioning version. Also found an undocumented command line option lsblk -o +kname,+otherfield..... The +option is nowhere documented. Leslie, whatever the problem you are referring to is, this bug report is specifically about yast2-firstboot and WSL. Please do not close it unless it's actually fixed. lsblk shows 88k size. lsblk with other distributions shows 130k size. lsblk is requiring root privileges where other distributions do not require root privileges. Other distributions (older Tumbleweed, Fedora 31,32, Clear Linux) and Ubunto What happens is the following: Tumbleweed as regular user /usr/bin/lsblk -Pnp -o mountpoint,uuid,partuuid,name,label,fstype,partlabel MOUNTPOINT="/boot" UUID="" PARTUUID="" NAME="/dev/sda2" LABEL="" FSTYPE="" PARTLABEL="" missing uuid, partuuid, fstype etc. with /usr/local/bin/lsblkx (copied from older Tumbleweed distro) MOUNTPOINT="/boot" UUID="eb99fd6d-62db-4d0b-b7fa-7a8257e0dd79" PARTUUID="73416286-c9ce-475f-a779-8d0db239532e" NAME="/dev/sda2" LABEL="kdeboot" FSTYPE="ext4" PARTLABEL="KDEboot" Restore old lsblk version so that the information does not require root privileges. version needing replacement -rwxr-xr-x 1 root root 88184 Feb 7 15:08 lsblk working version -rwxr-xr-x 1 leslie leslie 138104 Feb 25 08:38 lsblk (from older Tumbleweed version) Note 2: The new lsblk not providing info appears to be using or following the rules of /usr/bin/blkid in order to present the missing info. The change to the older lslbk may correct the yast issue too. -rwxr-xr-x 1 root root 154896 Mar 18 23:01 /usr/bin/lsblk The one that works (taken from Fedora 31 and 32 beta ) -rwxr-xr-x 1 root root 88184 Mar 8 19:29 /usr/bin/lsblk.bug The one that does not as regular non root user lsblk -o UUID,mountpoint does not list UUIDs but every distr has lsblk as non root listing every field. The working version is 155k, the defective one is 88. This bug is outstanding since February. I am using the output of lsblk for an application. It is located within /usr/bin as: -rwxr-xr-x 1 root root 138104 Apr 7 00:27 lsblk <==== the one from Fedora, Centos,Redhat, Ubuntu, Arch (Universal version) -rwxr-xr-x 1 root root 88184 Mar 8 19:29 lsblk <=== the different from all the rest used within Tumbleweed, Leap, Leap15.1 and the beta. NOTE THE DIFFERENCE IN SIZE. with the non SUSE version(regular user) typical good output. MOUNTPOINT="" FSTYPE="ext4" KNAME="sdb1" NAME="sdb1" UUID="bdc4349d-9b02-4d49-8d0a-a617f3f16539" PARTUUID="8363523f-0fe5-4a67-b202-ff3cb0ad37b7" LABEL="TwdBoot" PARTLABEL="twdBoot" MOUNTPOINT="" FSTYPE="vfat" KNAME="sdb2" NAME="sdb2" UUID="3B61-25DD" PARTUUID="178b6f64-dd86-40e7-b44c-4a1d81428b32" LABEL="TWDEFI" PARTLABEL="TwdEFI" MOUNTPOINT="" FSTYPE="swap" KNAME="sdb3" NAME="sdb3" UUID="2ff5bbad-eecf-474b-865b-63c37403be4f" PARTUUID="a5234696-5ce5-4957-8043-6fe58ec0b05d" LABEL="sdxSwap" PARTLABEL="" and so forth. With the SUSE version regular version Notice Missing information. MOUNTPOINT="" FSTYPE="" KNAME="sdb1" NAME="sdb1" UUID="" PARTUUID="" LABEL="" PARTLABEL="" MOUNTPOINT="" FSTYPE="" KNAME="sdb2" NAME="sdb2" UUID="" PARTUUID="" LABEL="" PARTLABEL="" MOUNTPOINT="" FSTYPE="" KNAME="sdb3" NAME="sdb3" UUID="" PARTUUID="" LABEL="" PARTLABEL="" MOUNTPOINT="" FSTYPE="" KNAME="sdb4" NAME="sdb4" UUID="" PARTUUID="" LABEL="" PARTLABEL="" MOUNTPOINT="" FSTYPE="" KNAME="sdb5" NAME="sdb5" UUID="" PARTUUID="" LABEL="" PARTLABEL="" MOUNTPOINT="" FSTYPE="" KNAME="sdb6" NAME="sdb6" UUID="" PARTUUID="" LABEL="" PARTLABEL="" MOUNTPOINT="" FSTYPE="" KNAME="sdb7" NAME="sdb7" UUID="" PARTUUID="" LABEL="" PARTLABEL="" MOUNTPOINT="" FSTYPE="" KNAME="sdb8" NAME="sdb8" UUID="" PARTUUID="" LABEL="" PARTLABEL="" MOUNTPOINT="" FSTYPE="" KNAME="sdb9" NAME="sdb9" UUID="" PARTUUID="" LABEL="" PARTLABEL="" The user does not have root or sudo permissions. I filed bug reports but would like someone to report the same issue as confirmation. By the way, the universal version does not work on the proposed Leap 15.x beta Some glib libraries are missing. What is it used for. I call it from a C program and peel off the information I use the information to check a /etc/fstab, The entries are validated against the lsblk listing, and the table reformatted into columns [CODE]Sample validated and reformatted /etc/fstab # Tumbleweed installation created at 2020-04-06 at 08:19 Local time. # This file formatted and cross referenced by fstabxref #<file system> <mount> <type> <options> <dmp pass> <xref> <label/uuid> UUID=174c3c6c-6803-4154-bf7a-c39e58923a38 / xfs defaults,relatime 0 0 #/dev/sda4 TWeedSlash UUID=94bcaca3-7fdc-47f3-8f5a-a87914989d71 /backup ext4 user,noauto,data=ordered 0 2 #/dev/sdc10 sdc10Backup UUID=963006ad-22e6-4c04-8ba3-6287ad66c958 /backup2 ext4 user,noauto,data=ordered 0 2 #/dev/sdc6 sdc6backup2 UUID=aac575f5-dee6-47d9-89fa-80a7e1a6ea5e swap swap defaults,relatime 0 0 #/dev/sda5 sda5swap UUID=64ae397f-e99c-4d4f-90dd-7a29ae520b10 /boot ext4 data=ordered,relatime 0 2 #/dev/sda3 TweedBoot UUID=acefc30a-d7fc-40fb-82c5-e0cae7c85ff0 /share ext4 data=ordered,relatime 0 2 #/dev/nvme0n1p5 nvme0n1p5Share UUID=87a338d1-ee1f-4c17-a7af-363c425cda11 /share2 ext4 user,noauto,data=ordered 0 2 #/dev/sdc2 sdc2share2 UUID=371d1798-4db0-4929-8abe-71e00d825490 /scratch1 ext4 user,noauto,data=ordered 0 2 #/dev/sdc1 scratch1 UUID=c1632f4f-7f3c-464a-b3dc-4f574b585304 /junk ext4 data=ordered 0 2 #/dev/sdc4 junk UUID=ecc640e9-335c-45f2-adf0-f658eb2645b6 /home ext4 data=ordered,relatime 0 2 #/dev/sda10 TweedHome UUID=A36A-536A /boot/efi vfat defaults,relatime 0 2 #/dev/sda1 TBLWEED [/CODE] Original bug filed October 2019, Currentl date 2020-04-07 lsblk should work from the command line. (In reply to Leslie Satenstein from comment #12) > I am using the output of lsblk for an application. > ... (in this environment lsblk behaves differently from what you expect) Leslie, this is actually a completely different bug. It's also not at all YaST related which is what this bug is all about. If this remains here, this will probably get lost. So please open a separate bug report for this. Ludwig's pull request which was what this bug was all about was merged (2020-01-14) and submitted to OBS (2020-01-16). https://github.com/yast/yast-users/pull/219 This concluded what this bug was all about: Not offering an option in the YaST users module that would cause a problem in the WSL environment. So this bug should have been closed as FIXED. You added more comments which actually are about something completely unrelated (comment #6 and later). This should have gone to a new bug report. Having two completely unrelated issues in one single Bugzilla entry just creates confusion, and there is no way to track both things properly. This is about workflows between teams and maintainers and keeping track what work is done and what is still left to do. This bug is still assigned to the YaST team, but the YaST team's part of this is done, so from that perspective, this is RESOLVED FIXED. Please open a new bug report for your other problem so it can be assigned and handled properly. Feel free to copy your comments from here to that new bug report. Closing this as a start to resolve the confusion. |