all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Bengt Richter <bokr@bokr.com>
To: Marius Bakke <mbakke@fastmail.com>
Cc: 37931@debbugs.gnu.org
Subject: bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk
Date: Sat, 2 Nov 2019 07:42:56 -0700	[thread overview]
Message-ID: <20191102144256.GA931@PhantoNv4ArchGx.localdomain> (raw)
In-Reply-To: <87tv7stsg3.fsf@devup.no>

Hi Marius,

On +2019-10-28 23:29:16 +0100, Marius Bakke wrote:
> Hi Bengt,
> 
> Bengt Richter <bokr@bokr.com> writes:
> 
> > Hi Guix,
> >
> > IpPulled and updated to guix describe:
> > ---------------------
> > Generation 19	Oct 24 2019 22:37:20	(current)
> >   guix 6caa739
> >     repository URL: https://git.savannah.gnu.org/git/guix.git
> >     branch: master
> >     commit: 6caa7392d8e51f5ef26e9efaa867ca5f9e1cac91
> > ---------------------
> >
> > but lsblk -f still looks like this:
> > ---------------------
> > NAME        FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
> > sda                                          
> > ├─sda1                                       
> > ├─sda2                                       
> > ├─sda3                                       
> > ├─sda4                                       
> > ├─sda5                                       
> > ├─sda6                                       
> > └─sda7                                       
> > sdb                                          
> > └─sdb1                                       
> > nvme0n1                                      
> > ├─nvme0n1p1                      510M    50% /boot
> > ├─nvme0n1p2                                  
> > ├─nvme0n1p3                                  [SWAP]
> > └─nvme0n1p4                     12.6G    71% /
> > ---------------------
> > where it should look like: (got this using foreign /usr/bin/lsblk -f)
> > ---------------------
> > NAME        FSTYPE LABEL           UUID                                 FSAVAIL FSUSE% MOUNTPOINT
> > sda                                                                                    
> > ├─sda1      vfat   Phanto1EFI      98AB-229C                                           
> > ├─sda2      ext4                   d8ce4206-fc92-4248-8164-3fe5397c28fb                
> > ├─sda3      swap                   59e8ffd8-a2df-4021-ba59-c8dda6215f83                
> > ├─sda4      ext4   Phanto4ArchGx   617f2280-d34a-4dea-ac50-a1222dd18c26                
> > ├─sda5      ext4   Phanto5ArchGxOn 71e61e41-81d0-48ac-b50f-a00668723c32                
> > ├─sda6      ext4   Phanto6Arch     e5760f87-71bc-4318-92f1-d108e5c9e332                
> > └─sda7      ext4   Phanto7GuixSD   a60eac5f-2306-49c5-8c87-7cab28ff6d37                
> > sdb                                                                                    
> > └─sdb1      ext4   Cruz1GxArchivA  18fb1d34-47b0-4d62-baea-43681ec2e5a4                
> > nvme0n1                                                                                
> > ├─nvme0n1p1 vfat   PhantoV1EFI     6E3C-D410                               510M    50% /boot
> > ├─nvme0n1p2 ext4   PhantoNv2Empty  76bc8f68-126c-4a6c-8b77-afc89bd2726a                
> > ├─nvme0n1p3 swap                   24151091-f47a-46e2-a6cb-e5219eddae7c                [SWAP]
> > └─nvme0n1p4 ext4   PhantoNv4ArchGx 12eec2bf-bc81-48a8-b444-26913c078302   12.6G    71% /
> > ---------------------
> 
> The `lsblk` program requires root privileges in order to detect file
> systems and UUIDs.  I'm guessing your distribution makes it setuid root?
>

It doesn't  look like it to me (the following snip is from TTY4, where I enabled guix paths and environment,
so I can see ~/.guix-profile and /usr stuff at the same time):

Ok, I'm back from TTY4 with some stuff (enclosed by the tagged snip lines):
--8<----(from emacs shell mode, guix enabled)-----------cut here---------------start------------->8---
$ gx-mode

Current    gx-mode: MY_GUIX_MODE-enabled
Next login gx-mode: MY_GUIX_MODE-enabled

Choose by number (or q for no change)
from the following guix modes for next login:
1) MY_GUIX_MODE-enabled
2) MY_GUIX_MODE-disabled
3) MY_GUIX_MODE-shepherd
#? q
No change made to current nor next guix mode.

$ which -a lsblk
/home/bokr/.guix-profile/bin/lsblk
/usr/bin/lsblk

$ which -a lsblk|xargs readlink -f
/gnu/store/xymkwf57x988q8cny2is1dgzrbr9xdfi-util-linux-2.34/bin/lsblk
/usr/bin/lsblk

$ which -a lsblk|xargs readlink -f|xargs file
/gnu/store/xymkwf57x988q8cny2is1dgzrbr9xdfi-util-linux-2.34/bin/lsblk: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped
/usr/bin/lsblk:                                                        ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=4028ee9653d75f37372a56e4f53215d75c75f564, for GNU/Linux 3.2.0, stripped
┌───────────────────────────────────────────────────────┐
│ Notice "LSB pie executable" vs "LSB executable" above │
└───────────────────────────────────────────────────────┘

$ which -a lsblk|xargs readlink -f|xargs stat
  File: /gnu/store/xymkwf57x988q8cny2is1dgzrbr9xdfi-util-linux-2.34/bin/lsblk
  Size: 135560    	Blocks: 272        IO Block: 4096   regular file
Device: 10304h/66308d	Inode: 1186253     Links: 2
Access: (0555/-r-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2019-11-01 02:38:11.782574923 -0700
Modify: 1969-12-31 16:00:01.000000000 -0800
Change: 2019-10-08 18:18:48.226579757 -0700
 Birth: -
  File: /usr/bin/lsblk
  Size: 124992    	Blocks: 248        IO Block: 4096   regular file
Device: 10304h/66308d	Inode: 264652      Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2019-11-01 02:38:55.354524750 -0700
Modify: 2019-06-27 03:04:01.000000000 -0700
Change: 2019-07-06 00:59:13.620416635 -0700
 Birth: -
$ 
┌───────────────────────────────────────────────────────────────────┐
│ I see Access: is 0555 vs 0755, so doubt if that should be changed │
└───────────────────────────────────────────────────────────────────┘

$ which -a lsblk|xargs readlink -f|xargs readelf -h

File: /gnu/store/xymkwf57x988q8cny2is1dgzrbr9xdfi-util-linux-2.34/bin/lsblk
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
┌─────────────────────────────────────────────────────────────┐
│   Type:                              EXEC (Executable file) │
└─────────────────────────────────────────────────────────────┘
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x406440
  Start of program headers:          64 (bytes into file)
  Start of section headers:          133640 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         11
  Size of section headers:           64 (bytes)
  Number of section headers:         30
  Section header string table index: 29

File: /usr/bin/lsblk
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
┌───────────────────────────────────────────────────────────────┐
│   Type:                              DYN (Shared object file) │
└───────────────────────────────────────────────────────────────┘
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x6c50
  Start of program headers:          64 (bytes into file)
  Start of section headers:          123200 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         11
  Size of section headers:           64 (bytes)
  Number of section headers:         28
  Section header string table index: 27
$ 
--8<----(from emacs shell mode, guix enabled)-----------cut here---------------end--------------->8---

I did:

/usr/bin/strace -ittyko lsblkusr.strace lsblk -f

in "foreign" mode and

/usr/bin/strace -ittyko lsblk.strace lsblk -f

in "guix mode"
I used /usr/bin/strace in both cases because it has the -k option and the guix version doesn't.
IDK if that could be an iffy combination, but it seemed to work.

I looked at both outputs, and saw something strange in the guix mode trace which was not in the foreign version: oom references:
┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ $ grep oom lsblk.strace |uniq -c                                                                    │
│     122  > /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib/ld-2.29.so(oom+0x37) [0x1218] │
│ $ grep oom lsblkusr.strace                                                                          │
└─────────────────────────────────────────────────────────────────────────────────────────────────────┘

Would whoever is familiar with the code have a look please?
I would rather be debugging my own code ;-)

--8<----(from emacs shell mode, guix enabled)-----------cut here---------------start------------->8---
$ # Both foreign and guix versions execute lsblk -h which shows the
$ # -o options available -- identically:
$ diff -u --report <(/usr/bin/lsblk -h) <(lsblk -h)
Files /dev/fd/63 and /dev/fd/62 are identical

$ # likewise the default output
$ diff -u --report <(/usr/bin/lsblk) <(lsblk)
Files /dev/fd/63 and /dev/fd/62 are identical
$

$ # it is the -f option that calls for -o columns FSTYPE, LABEL, and UUID
$ # that hits the problem (interestingly, FSAVAIL FSUSE% both work,
    and they were unavailable before 2.34):
    
$ diff -u --report <(/usr/bin/lsblk -f) <(lsblk -f)
--- /dev/fd/63	2019-11-01 21:11:53.517902795 -0700
+++ /dev/fd/62	2019-11-01 21:11:53.521236034 -0700
@@ -1,16 +1,16 @@
-NAME        FSTYPE LABEL           UUID                                 FSAVAIL FSUSE% MOUNTPOINT
-sda                                                                                    
-├─sda1      vfat   Phanto1EFI      98AB-229C                                           
-├─sda2      ext4                   d8ce4206-fc92-4248-8164-3fe5397c28fb                
-├─sda3      swap                   59e8ffd8-a2df-4021-ba59-c8dda6215f83                
-├─sda4      ext4   Phanto4ArchGx   617f2280-d34a-4dea-ac50-a1222dd18c26                
-├─sda5      ext4   Phanto5ArchGxOn 71e61e41-81d0-48ac-b50f-a00668723c32                
-├─sda6      ext4   Phanto6Arch     e5760f87-71bc-4318-92f1-d108e5c9e332                
-└─sda7      ext4   Phanto7GuixSD   a60eac5f-2306-49c5-8c87-7cab28ff6d37                
-sdb                                                                                    
-└─sdb1      ext4                   35c979a8-e19a-4447-bc84-47b66c0ade49                
-nvme0n1                                                                                
-├─nvme0n1p1 vfat   PhantoV1EFI     6E3C-D410                               510M    50% /boot
-├─nvme0n1p2 ext4   PhantoNv2Empty  76bc8f68-126c-4a6c-8b77-afc89bd2726a                
-├─nvme0n1p3 swap                   24151091-f47a-46e2-a6cb-e5219eddae7c                [SWAP]
-└─nvme0n1p4 ext4   PhantoNv4ArchGx 12eec2bf-bc81-48a8-b444-26913c078302   12.1G    72% /
+NAME        FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
+sda                                          
+├─sda1                                       
+├─sda2                                       
+├─sda3                                       
+├─sda4                                       
+├─sda5                                       
+├─sda6                                       
+└─sda7                                       
+sdb                                          
+└─sdb1                                       
+nvme0n1                                      
+├─nvme0n1p1                      510M    50% /boot
+├─nvme0n1p2                                  
+├─nvme0n1p3                                  [SWAP]
+└─nvme0n1p4                     12.1G    72% /
$
--8<----(from emacs shell mode, guix enabled)-----------cut here---------------end--------------->8---

I assume the column widths are computed by internally buffering the outputs called for for each heading,
and values under those headings and determining the widest, and then formatting to that width plus padding.
That is consistent with the above if you assume that guix's lsblk got a null string where it unsuccessfully
tried to get FSTYPE, LABEL, and UUID values, e.g. showing headings and the lines ending in /boot: from above:

/usr/bin/lsblk successfully retrieved
-NAME        FSTYPE LABEL           UUID                                 FSAVAIL FSUSE% MOUNTPOINT
-├─nvme0n1p1 vfat   PhantoV1EFI     6E3C-D410                               510M    50% /boot

/gnu/store/xymkwf57x988q8cny2is1dgzrbr9xdfi-util-linux-2.34/bin/lsblk didn't get FSTYPE, LABEL, nor UUID
+NAME        FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
+├─nvme0n1p1                      510M    50% /boot


> To do the same on Guix System, see the "Setuid programs" section of the
> manual.  You would need something along these lines in your config:
> 
>  (operating-system
>   [...]
>   (setuid-programs (cons #~(string-append #$util-linux "/bin/lsblk"))
>                          %setuid-programs))
> 
> Does that work for you?

I think it might "work" (produce the desired output) -- but so would intercepting
lsblk in /usr/local/bin and brute forcing /usr/bin/lsblk or su -c 'lsblk -f'
(didn't try, but think so, don't want to :).

BTW, su -c 'lsblk -f' does "work," but I don't like that "solution"  ;-)

I have a hunch there's something that needs to be fixed for real,
but I could well have done something stupid :)
--
Regards,
Bengt Richter

  reply	other threads:[~2019-11-02 14:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-26  1:22 bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk Bengt Richter
2019-10-28 22:29 ` Marius Bakke
2019-11-02 14:42   ` Bengt Richter [this message]
2019-11-03 17:28     ` Marius Bakke
2019-11-06 15:40       ` bug#37931: util-linux dependency on udev Ludovic Courtès
2019-11-06 22:39       ` bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk Bengt Richter
2020-01-08 19:14         ` Marius Bakke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191102144256.GA931@PhantoNv4ArchGx.localdomain \
    --to=bokr@bokr.com \
    --cc=37931@debbugs.gnu.org \
    --cc=mbakke@fastmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.