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
next prev parent 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
List information: https://guix.gnu.org/
* 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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).