Bug 257409 - sysutils/lsblk 3.5 seems to not show a modified label if the device is at /dev/da0 (zero)
Summary: sysutils/lsblk 3.5 seems to not show a modified label if the device is at /de...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on: 257494
Blocks:
  Show dependency treegraph
 
Reported: 2021-07-25 12:27 UTC by Graham Perrin
Modified: 2021-07-30 19:25 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (vermaden)


Attachments
A Konsole session. (7.85 KB, text/plain)
2021-07-25 12:27 UTC, Graham Perrin
no flags Details
Another Konsole session … (11.50 KB, text/plain)
2021-07-25 12:35 UTC, Graham Perrin
no flags Details
Third session (7.01 KB, text/plain)
2021-07-25 13:11 UTC, Graham Perrin
no flags Details
Fourth session (9.32 KB, text/plain)
2021-07-25 13:26 UTC, Graham Perrin
no flags Details
sh -x ~/Desktop/lsblk da0 (5.71 KB, text/plain)
2021-07-25 18:19 UTC, Graham Perrin
no flags Details
lsblk (16.50 KB, text/plain)
2021-07-25 19:02 UTC, Slawomir Wojciech Wojtczak
no flags Details
lovely-looking lolcat labels (77.11 KB, image/png)
2021-07-26 02:15 UTC, Graham Perrin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Graham Perrin 2021-07-25 12:27:46 UTC
Created attachment 226676 [details]
A Konsole session.

From the attached transcript (01): 

----

root@mowa219-gjp4-8570p:~ # gpart modify -l cache-transcend -i 1 da0
da0p1 modified
root@mowa219-gjp4-8570p:~ # lsblk da0
DEVICE         MAJ:MIN SIZE TYPE                              LABEL MOUNT
da0              2:98   14G GPT                                   - -
  <FREE>         -:-   1.0M -                                     - -
  da0p1          2:99   14G freebsd-zfs                gpt/efiboot0 <ZFS>
root@mowa219-gjp4-8570p:~ # gpart show -l /dev/da0
=>      34  30310333  da0  GPT  (14G)
        34      2014       - free -  (1.0M)
      2048  30308319    1  cache-transcend  (14G)
…

----
Comment 1 Graham Perrin 2021-07-25 12:35:15 UTC
Created attachment 226677 [details]
Another Konsole session …

… I'm not sure how to interpret the results in these two transcripts. 

At the tail of the first transcript, the expected label for the 14 G drive was shown by lsblk: 

    gpt/cache-transcend

– only after I ordered the reconnection of devices to have the drive at da1. 


----


At the tail of this second transcript, with the 14 G drive returned to da0, it's as if the label was lost: 


root@mowa219-gjp4-8570p:~ # lsblk da0
DEVICE         MAJ:MIN SIZE TYPE                              LABEL MOUNT
da0              2:114  14G GPT                                   - -
  <FREE>         -:-   1.0M -                                     - -
  da0p1          2:115  14G freebsd-zfs                gpt/efiboot0 <ZFS>


----

I'll restart the OS, review output from lsblk …
Comment 2 Slawomir Wojciech Wojtczak 2021-07-25 12:48:15 UTC
I just done that on FreeBSD 13.0.

Works as desired.

# gpart modify -i 1 -l swap da0
da0p1 modified

# lsblk da0
DEVICE         MAJ:MIN SIZE TYPE                                          LABEL MOUNT
da0              0:166  30G GPT                                               - -
  da0p1          0:167  30G freebsd-swap                               gpt/swap -




# gpart modify -i 1 -l swap1 da0
da0p1 modified

# lsblk da0                          
DEVICE         MAJ:MIN SIZE TYPE                                          LABEL MOUNT
da0              0:166  30G GPT                                               - -
  da0p1          0:167  30G freebsd-swap                              gpt/swap1 -
Comment 3 Graham Perrin 2021-07-25 13:11:47 UTC
Created attachment 226679 [details]
Third session

(In reply to vermaden from comment #2)

OK. 

I wonder what's wrong here. After restarting the system: again, it seems that a problem occurs when _either_ of the two devices is at: 

da0
Comment 4 Graham Perrin 2021-07-25 13:26:48 UTC
Created attachment 226681 [details]
Fourth session

(In reply to Graham Perrin from comment #3)

> … it seems that a problem occurs when _either_ of the two devices is at: 
> 
> da0

Not just those two devices. 

The same effect with a third device when it's at da0. From the attached transcript: 

----

…
root@mowa219-gjp4-8570p:~ # lsblk
DEVICE         MAJ:MIN SIZE TYPE                              LABEL MOUNT
ada0             0:130 466G GPT                                   - -
  ada0p1         0:132 200M efi                        gpt/efiboot0 -
  ada0p2         0:134 512K freebsd-boot               gpt/gptboot0 -
  <FREE>         -:-   492K -                                     - -
  ada0p3         0:136  16G freebsd-swap                  gpt/swap0 SWAP
  ada0p3.eli     2:82   16G freebsd-swap                          - SWAP
  ada0p4         0:138 450G freebsd-zfs                    gpt/zfs0 <ZFS>
  ada0p4.eli     0:148 450G zfs                                   - -
  <FREE>         -:-   4.0K -                                     - -
cd0              0:196  10M cd9660             iso9660/ONEPLUS%20DRIVERS -
da0              2:105  29G GPT                                   - -
  <FREE>         -:-   1.0M -                                     - -
  da0p1          2:106  29G freebsd-zfs                gpt/efiboot0 <ZFS>
da1              2:113  14G GPT                                   - -
  <FREE>         -:-   1.0M -                                     - -
  da1p1          2:114  14G freebsd-zfs         gpt/cache-transcend <ZFS>
da2              2:126 466G GPT                                   - -
  <FREE>         -:-   1.0M -                                     - -
  da2p1          2:127 466G freebsd-zfs               gpt/Transcend <ZFS>
root@mowa219-gjp4-8570p:~ # gpart show -l /dev/da0
=>      34  60437425  da0  GPT  (29G)
        34      2014       - free -  (1.0M)
      2048  60435411    1  cache-copperbowl  (29G)
…
Comment 5 Slawomir Wojciech Wojtczak 2021-07-25 13:43:49 UTC
Please try latest version from here:

https://github.com/vermaden/lsblk/blob/master/lsblk
Comment 6 Graham Perrin 2021-07-25 13:51:18 UTC
Thanks, 

(In reply to vermaden from comment #5)

I can, however (at a glance) the most recent commit <https://github.com/vermaden/lsblk/commit/ae79c5a8a15d58cb4cd4155792614e4526553a72> matches <https://cgit.freebsd.org/ports/commit/?id=3625ba51feb356d0e2e1948ea99d2090582867bb> for 3.5, which is what I already have. 

From the first attachment: 

root@mowa219-gjp4-8570p:~ # pkg info -x lsblk
lsblk-3.5

Please, is a difference expected?
Comment 7 Slawomir Wojciech Wojtczak 2021-07-25 16:11:30 UTC
(In reply to Graham Perrin from comment #6)

Try the version from GitHub.

I did not yet bumped the version.

Version in the packages/ports is older then the one on the GitHub page.
Comment 8 Graham Perrin 2021-07-25 17:53:24 UTC
(In reply to vermaden from comment #5)

% pwd
/usr/home/grahamperrin/Desktop
% chmod +x lsblk
% file lsblk 
lsblk: POSIX shell script, ASCII text executable
% lsblk
DEVICE         MAJ:MIN SIZE TYPE                              LABEL MOUNT
ada0             0:130 466G GPT                                   - -
  ada0p1         0:132 200M efi                        gpt/efiboot0 -
  ada0p2         0:134 512K freebsd-boot               gpt/gptboot0 -
  <FREE>         -:-   492K -                                     - -
  ada0p3         0:136  16G freebsd-swap                  gpt/swap0 SWAP
  ada0p3.eli     2:82   16G freebsd-swap                          - SWAP
  ada0p4         0:138 450G freebsd-zfs                    gpt/zfs0 <ZFS>
  ada0p4.eli     0:148 450G zfs                                   - -
  <FREE>         -:-   4.0K -                                     - -
cd0              0:196  10M cd9660             iso9660/ONEPLUS%20DRIVERS -
da0              2:105  29G GPT                                   - -
  <FREE>         -:-   1.0M -                                     - -
  da0p1          2:106  29G freebsd-zfs                gpt/efiboot0 <ZFS>
da1              2:113  14G GPT                                   - -
  <FREE>         -:-   1.0M -                                     - -
  da1p1          2:114  14G freebsd-zfs         gpt/cache-transcend <ZFS>
da2              2:126 466G GPT                                   - -
  <FREE>         -:-   1.0M -                                     - -
  da2p1          2:127 466G freebsd-zfs               gpt/Transcend <ZFS>
% gpart show -l /dev/da0
=>      34  60437425  da0  GPT  (29G)
        34      2014       - free -  (1.0M)
      2048  60435411    1  cache-copperbowl  (29G)

%
Comment 9 Slawomir Wojciech Wojtczak 2021-07-25 18:06:41 UTC
Please send me (or attach) the output of this command when lsblk behaves bad:

# sh -x lsblk

Thanks.
Comment 10 Graham Perrin 2021-07-25 18:19:46 UTC
Created attachment 226684 [details]
sh -x ~/Desktop/lsblk da0

(In reply to vermaden from comment #9)
Comment 11 Graham Perrin 2021-07-25 18:20:41 UTC
(In reply to Graham Perrin from comment #10)

… sorry, I ran that without superuser privileges. Should I re-run?
Comment 12 Slawomir Wojciech Wojtczak 2021-07-25 18:27:47 UTC
(In reply to Graham Perrin from comment #11)

Should do. Thanks.
Comment 13 Slawomir Wojciech Wojtczak 2021-07-25 19:02:06 UTC
Created attachment 226687 [details]
lsblk

Please try this attached modified version.
Comment 14 Graham Perrin 2021-07-26 02:15:40 UTC
Created attachment 226695 [details]
lovely-looking lolcat labels

(In reply to vermaden from comment #13)

Success :-) at a glance.
Comment 15 Slawomir Wojciech Wojtczak 2021-07-26 11:09:04 UTC
Thanks.

I will submit port update for lsblk as 3.6 in my next block of 'free' time :)

Regards.
Comment 16 Slawomir Wojciech Wojtczak 2021-07-29 18:47:06 UTC
Updated on GitHub.

https://github.com/vermaden/lsblk

Will submit a PR to update the port now.
Comment 17 Slawomir Wojciech Wojtczak 2021-07-29 21:59:32 UTC
Submitted:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257494
Comment 19 Slawomir Wojciech Wojtczak 2021-07-30 15:41:39 UTC
(In reply to Graham Perrin from comment #18)

Yes :)

Without it the ada0p1 was the same as da0p1 ... and because of grep(1) '-m' option always the first result was taken.

Regards.
Comment 20 Li-Wen Hsu freebsd_committer 2021-07-30 19:25:02 UTC
Should be fixed in 3.6 in head and 2021Q3.