GNU bug report logs - #37931
Cannot guix refresh -ru util-linux to get updated lsblk

Previous Next

Package: guix;

Reported by: Bengt Richter <bokr <at> bokr.com>

Date: Sat, 26 Oct 2019 01:24:03 UTC

Severity: normal

Done: Marius Bakke <mbakke <at> fastmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37931 in the body.
You can then email your comments to 37931 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#37931; Package guix. (Sat, 26 Oct 2019 01:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bengt Richter <bokr <at> bokr.com>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Sat, 26 Oct 2019 01:24:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bengt Richter <bokr <at> bokr.com>
To: New-Bug <bug-guix <at> gnu.org>
Subject: Cannot guix refresh -ru util-linux to get updated lsblk
Date: Fri, 25 Oct 2019 18:22:48 -0700
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% /
---------------------

So I tried:

[17:59 ~/bs]$ guix refresh -r util-linux
guix/build-system/gnu.scm:143:8: findutils would be upgraded from 4.6.0 to 4.7.0
gnu/packages/commencement.scm:2183:2: binutils would be upgraded from 2.32 to 2.33.1
gnu/packages/commencement.scm:2244:2: gcc would be upgraded from 7.4.0 to 9.2.0
gnu/packages/commencement.scm:2142:2: glibc would be upgraded from 2.29 to 2.30
[18:01 ~/bs]$ guix refresh -ru util-linux
guix/build-system/gnu.scm:143:8: error: cannot download for this method: #<procedure 7f277de49100 at gnu/packages/bootstrap.scm:155:4 (url hash-algo hash #:opti
onal name #:key system)>
[18:02 ~/bs]$ lsblk --version
lsblk from util-linux 2.34
[18:04 ~/bs]$ guix package -I util-linux
util-linux      2.34    out     /gnu/store/xymkwf57x988q8cny2is1dgzrbr9xdfi-util-linux-2.34
[18:04 ~/bs]$ # was -ru combination a problem?
[18:05 ~/bs]$ guix refresh -u util-linux
[18:06 ~/bs]$ guix refresh -r util-linux
guix/build-system/gnu.scm:143:8: findutils would be upgraded from 4.6.0 to 4.7.0
gnu/packages/commencement.scm:2183:2: binutils would be upgraded from 2.32 to 2.33.1
gnu/packages/commencement.scm:2244:2: gcc would be upgraded from 7.4.0 to 9.2.0
gnu/packages/commencement.scm:2142:2: glibc would be upgraded from 2.29 to 2.30
[18:06 ~/bs]$ guix refresh -ur util-linux
guix/build-system/gnu.scm:143:8: error: cannot download for this method: #<procedure 7fb30f394e80 at gnu/packages/bootstrap.scm:155:4 (url hash-algo hash #:opti
onal name #:key system)>
[18:06 ~/bs]$ su -c 'setterm -file refresh-errors.txt -dump 1'

TIA for any help :)
--
Regards,
Bengt Richter




Information forwarded to bug-guix <at> gnu.org:
bug#37931; Package guix. (Mon, 28 Oct 2019 22:30:02 GMT) Full text and rfc822 format available.

Message #8 received at 37931 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Bengt Richter <bokr <at> bokr.com>, 37931 <at> debbugs.gnu.org
Subject: Re: bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk
Date: Mon, 28 Oct 2019 23:29:16 +0100
[Message part 1 (text/plain, inline)]
Hi Bengt,

Bengt Richter <bokr <at> 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?

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?

> So I tried:
>
> [17:59 ~/bs]$ guix refresh -r util-linux
> guix/build-system/gnu.scm:143:8: findutils would be upgraded from 4.6.0 to 4.7.0
> gnu/packages/commencement.scm:2183:2: binutils would be upgraded from 2.32 to 2.33.1
> gnu/packages/commencement.scm:2244:2: gcc would be upgraded from 7.4.0 to 9.2.0
> gnu/packages/commencement.scm:2142:2: glibc would be upgraded from 2.29 to 2.30
> [18:01 ~/bs]$ guix refresh -ru util-linux
> guix/build-system/gnu.scm:143:8: error: cannot download for this method: #<procedure 7f277de49100 at gnu/packages/bootstrap.scm:155:4 (url hash-algo hash #:opti
> onal name #:key system)>

'guix refresh -u' only works in combination with the './pre-inst-env'
script, because it tries to modify your Guix directly.

In any case util-linux is already the latest version.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#37931; Package guix. (Sat, 02 Nov 2019 14:44:02 GMT) Full text and rfc822 format available.

Message #11 received at 37931 <at> debbugs.gnu.org (full text, mbox):

From: Bengt Richter <bokr <at> bokr.com>
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: 37931 <at> debbugs.gnu.org
Subject: Re: bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk
Date: Sat, 2 Nov 2019 07:42:56 -0700
Hi Marius,

On +2019-10-28 23:29:16 +0100, Marius Bakke wrote:
> Hi Bengt,
> 
> Bengt Richter <bokr <at> 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





Information forwarded to bug-guix <at> gnu.org:
bug#37931; Package guix. (Sun, 03 Nov 2019 17:29:02 GMT) Full text and rfc822 format available.

Message #14 received at 37931 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Bengt Richter <bokr <at> bokr.com>
Cc: 37931 <at> debbugs.gnu.org
Subject: Re: bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk
Date: Sun, 03 Nov 2019 18:28:40 +0100
[Message part 1 (text/plain, inline)]
Bengt Richter <bokr <at> bokr.com> writes:

> On +2019-10-28 23:29:16 +0100, Marius Bakke wrote:
>> 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):

[...]


> $ 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 │
> └───────────────────────────────────────────────────────────────────┘

Indeed, there are no setuid bits there.

I had a look at the lsblkd source code, and found that it has an
optional dependency on udev:

https://github.com/karelzak/util-linux/blob/ccafadb7c58865f73d209fcfc74483be96cdf64d/misc-utils/lsblk-properties.c

I tried building util-linux with udev support, and got the same output
you expected without needing root privileges:

(define-public util-linux/udev
  (package/inherit
   util-linux
   (name "util-linux-with-udev")
   (inputs
    `(("udev" ,eudev)
      ,@(package-inputs util-linux)))))

Now, eudev already depends on util-linux, so adding udev support to the
regular 'util-linux' package would introduce a circular dependency.

I'm not sure what the best approach here is.  We could add a
'util-linux-minimal' for use in package inputs, and/or add a
udev-enabled variant to %base-packages.

Thoughts?
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#37931; Package guix. (Wed, 06 Nov 2019 15:41:01 GMT) Full text and rfc822 format available.

Message #17 received at 37931 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: 37931 <at> debbugs.gnu.org, Bengt Richter <bokr <at> bokr.com>
Subject: util-linux dependency on udev
Date: Wed, 06 Nov 2019 16:40:18 +0100
Hi,

Marius Bakke <mbakke <at> fastmail.com> skribis:

> I had a look at the lsblkd source code, and found that it has an
> optional dependency on udev:
>
> https://github.com/karelzak/util-linux/blob/ccafadb7c58865f73d209fcfc74483be96cdf64d/misc-utils/lsblk-properties.c
>
> I tried building util-linux with udev support, and got the same output
> you expected without needing root privileges:
>
> (define-public util-linux/udev
>   (package/inherit
>    util-linux
>    (name "util-linux-with-udev")
>    (inputs
>     `(("udev" ,eudev)
>       ,@(package-inputs util-linux)))))
>
> Now, eudev already depends on util-linux, so adding udev support to the
> regular 'util-linux' package would introduce a circular dependency.
>
> I'm not sure what the best approach here is.  We could add a
> 'util-linux-minimal' for use in package inputs, and/or add a
> udev-enabled variant to %base-packages.

I think the latter is fine and can be done right away on ‘master’.

WDYT?

Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#37931; Package guix. (Wed, 06 Nov 2019 22:40:02 GMT) Full text and rfc822 format available.

Message #20 received at 37931 <at> debbugs.gnu.org (full text, mbox):

From: Bengt Richter <bokr <at> bokr.com>
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: 37931 <at> debbugs.gnu.org
Subject: Re: bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk
Date: Wed, 6 Nov 2019 14:39:10 -0800
Hi Marius,

On +2019-11-03 18:28:40 +0100, Marius Bakke wrote:
> Bengt Richter <bokr <at> bokr.com> writes:
> 
> > On +2019-10-28 23:29:16 +0100, Marius Bakke wrote:
> >> 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):
> 
> [...]
> 
> 
> > $ 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 │
> > └───────────────────────────────────────────────────────────────────┘
> 
> Indeed, there are no setuid bits there.
> 
> I had a look at the lsblkd source code, and found that it has an
> optional dependency on udev:
> 
> https://github.com/karelzak/util-linux/blob/ccafadb7c58865f73d209fcfc74483be96cdf64d/misc-utils/lsblk-properties.c
> 
> I tried building util-linux with udev support, and got the same output
> you expected without needing root privileges:
>

Sounds great ;-)

> (define-public util-linux/udev
>   (package/inherit
>    util-linux
>    (name "util-linux-with-udev")
>    (inputs
>     `(("udev" ,eudev)
>       ,@(package-inputs util-linux)))))
> 
> Now, eudev already depends on util-linux, so adding udev support to the
> regular 'util-linux' package would introduce a circular dependency.
> 
> I'm not sure what the best approach here is.  We could add a
> 'util-linux-minimal' for use in package inputs, and/or add a
> udev-enabled variant to %base-packages.
> 
> Thoughts?

I'm a guix newbie :)

I don't yet understand the internal dependency machinery of guix,
so I'm wondering about the exact nature of the circularity.

Is it really a kind of (let((... that needs to be a let*((...
at some level? And which level of dependency are we talking about?

I mean, everything is ultimately dependent on sources and translators
in succession, but we identify intermediate collections and call them
libraries or packages or scripts or executables etc.

E.g., if part of the build sequence produces an obj library, is an interdependency
between two library elements a circular dependency if that requires two passes
for the linker to resolve? (i.e., the second is dependent on the library, but
only as container of the other element).

What is the chain of dependency that yields a user cmdline lsblk executable
on my $PATH ? As a user, I don't much care beyond hoping guix pull will keep
the functionality at my finger tips (thanks maintainers :), but...

But once I start wanting a handy customization of something, I want it
to be trivial to compose trivial things, which for me starts at a shell
command line, composing a one-liner, and then writing two-line scripts
when I find myself re-typing a lot, and so on, to things like examples
in info guile, including C extensions.

So, my thought is that whatever the solution is that puts lsblk on my $PATH,
I want the system for it to be cherry-picker-friendly.

By that I mean I want to be able to make tiny things from cherry-picked ("stolen" ;-)
snippets/elements of something big and having the net result be minimal -- unless I really
do e.g. want a busybox monolith for other reasons than puts "Hello World".

Also, being a command line user, I want to be able to access any functionality from there ;-)

That BTW includes graphics: I would like to be able to run any GUI program in headless mode
and get graphic buffer output, or streams.

Likewise, I would like guix build tools to be able e.g. to cherry-pick the sources of a browser
to get the functionality that renders an html <table ...> ...</table> to sRGB buffer
(assuming sources are modularized cherry-picker-friendly :) without incorporating more than necessary,
(and automatically doing the license/attribution stuff ;-)

IOW, sort of treating any large application's (or a kernel's! :) sources as a kind of library.
Of course, I know cherry-picker-friendly is a dream, but I think it's a nice dream :)

So I think it should be a design goal for FOSS to be easily snarfed.

Life could be a bowl of cherries if enough people descide to be friendly ;-)
--
Regards,
Bengt Richter




Reply sent to Marius Bakke <mbakke <at> fastmail.com>:
You have taken responsibility. (Wed, 08 Jan 2020 19:15:01 GMT) Full text and rfc822 format available.

Notification sent to Bengt Richter <bokr <at> bokr.com>:
bug acknowledged by developer. (Wed, 08 Jan 2020 19:15:01 GMT) Full text and rfc822 format available.

Message #25 received at 37931-done <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Bengt Richter <bokr <at> bokr.com>
Cc: 37931-done <at> debbugs.gnu.org
Subject: Re: bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk
Date: Wed, 08 Jan 2020 20:14:50 +0100
[Message part 1 (text/plain, inline)]
Bengt Richter <bokr <at> bokr.com> writes:

> Hi Marius,
>
> On +2019-11-03 18:28:40 +0100, Marius Bakke wrote:
>> Bengt Richter <bokr <at> bokr.com> writes:
>> 
>> > On +2019-10-28 23:29:16 +0100, Marius Bakke wrote:
>> >> 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):
>> 
>> [...]
>> 
>> 
>> > $ 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 │
>> > └───────────────────────────────────────────────────────────────────┘
>> 
>> Indeed, there are no setuid bits there.
>> 
>> I had a look at the lsblkd source code, and found that it has an
>> optional dependency on udev:
>> 
>> https://github.com/karelzak/util-linux/blob/ccafadb7c58865f73d209fcfc74483be96cdf64d/misc-utils/lsblk-properties.c
>> 
>> I tried building util-linux with udev support, and got the same output
>> you expected without needing root privileges:
>>
>
> Sounds great ;-)
>
>> (define-public util-linux/udev
>>   (package/inherit
>>    util-linux
>>    (name "util-linux-with-udev")
>>    (inputs
>>     `(("udev" ,eudev)
>>       ,@(package-inputs util-linux)))))
>> 
>> Now, eudev already depends on util-linux, so adding udev support to the
>> regular 'util-linux' package would introduce a circular dependency.
>> 
>> I'm not sure what the best approach here is.  We could add a
>> 'util-linux-minimal' for use in package inputs, and/or add a
>> udev-enabled variant to %base-packages.
>> 
>> Thoughts?

This was finally committed in 71e0f1e9adbce4a6476a70bddabf13f6d7af2d40
and 01bb039e7b408893009d15f56cfcbdc8af70a4af.

>
> I'm a guix newbie :)
>
> I don't yet understand the internal dependency machinery of guix,
> so I'm wondering about the exact nature of the circularity.
>
> Is it really a kind of (let((... that needs to be a let*((...
> at some level? And which level of dependency are we talking about?

The circular dependency is straightforward: eudev *requires* util-linux
as part of its build process.  Thus, eudev has util-linux as an input.
That version of util-linux can not depend on eudev, because we can not
build eudev without a working util-linux package.

Wrt the rest of the message, I share your sentiment, and think we will
get there.  'guix build --with-git-url' is pretty close already.  :-)
[signature.asc (application/pgp-signature, inline)]

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 06 Feb 2020 12:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 51 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.