From mboxrd@z Thu Jan 1 00:00:00 1970 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 Message-ID: <20191102144256.GA931@PhantoNv4ArchGx.localdomain> References: <20191026012248.GA119672@PhantoNv4ArchGx.localdomain> <87tv7stsg3.fsf@devup.no> Reply-To: Bengt Richter Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:51312) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iQudK-0000CI-GI for bug-guix@gnu.org; Sat, 02 Nov 2019 10:44:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iQudH-0005S2-07 for bug-guix@gnu.org; Sat, 02 Nov 2019 10:44:06 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:52225) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iQudG-0005O5-LL for bug-guix@gnu.org; Sat, 02 Nov 2019 10:44:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iQudG-0005wS-D6 for bug-guix@gnu.org; Sat, 02 Nov 2019 10:44:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: Content-Disposition: inline In-Reply-To: <87tv7stsg3.fsf@devup.no> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Marius Bakke Cc: 37931@debbugs.gnu.org Hi Marius, On +2019-10-28 23:29:16 +0100, Marius Bakke wrote: > Hi Bengt, > > Bengt Richter 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