[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk
|
From: |
Bengt Richter |
|
Subject: |
bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk |
|
Date: |
Sat, 2 Nov 2019 07:42:56 -0700 |
|
User-agent: |
Mutt/1.12.1 (2019-06-15) |
Hi Marius,
On +2019-10-28 23:29:16 +0100, Marius Bakke wrote:
> Hi Bengt,
>
> Bengt Richter <address@hidden> 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
- bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk,
Bengt Richter <=