Skip Navigation
Guix @lemmy.ml worldofgeese @lemmy.world

Diagnosing No such file or directory when writing a package

My error message when trying to run minikube from a guix shell is bash: /gnu/store/ixry3pdrrb52mdiypmlrdn19c7gcc5r4-minikube-1.31.2/bin/minikube: No such file or directory

According to ldd and file, it looks like everything is hunky dory as far as where all my linkers are pointing. I'm also including an strace further below. I've run out of options for debugging this and would welcome any feedback and suggestions!

ldd shows what looks like clean RPATHs:

 /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so.6 (0x00007f9299546000)
	libpthread.so.0 => /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libpthread.so.0 (0x00007f9299541000)
	libresolv.so.2 => /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libresolv.so.2 (0x00007f929952e000)
	/lib64/ld-linux-x86-64.so.2 => /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2 (0x00007f9299744000)

Here's file:

/gnu/store/xhyv7k87gy9k368yrv6faray37z615cr-minikube-1.31.2/bin/minikube: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2, Go BuildID=aBEWfkldQzf4mlUsITym/a6aHGcy9omlZPRTvR8ta/1-lUpI-DPce979zTpJQy/jMuF_0TfmkRW2e3NFst2, not stripped

And strace:

Error:
strace /gnu/store/xhyv7k87gy9k368yrv6faray37z615cr-minikube-1.31.2/bin/minikube
execve("/gnu/store/xhyv7k87gy9k368yrv6faray37z615cr-minikube-1.31.2/bin/minikube", ["/gnu/store/xhyv7k87gy9k368yrv6fa"...], 0x7ffc5f304810 /* 109 vars */) = 0
brk(NULL)                               = 0x50b7000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2daf26c000
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x400318} ---
+++ killed by SIGSEGV +++
Segmentation fault
    (define-module (worldofguix packages minikube)
      #:use-module (guix packages)
      #:use-module (guix download)
      #:use-module ((guix licenses) :prefix license:)
      #:use-module (guix gexp)
      #:use-module (gnu packages gcc)
      #:use-module (gnu packages commencement)
      #:use-module (nonguix build-system binary))

    (define-public minikube
      (package
       (name "minikube")
       (version "1.31.2")
       (source (origin
                 (method url-fetch)
                 (uri (string-append "https://github.com/kubernetes/minikube/releases/download/v" version "/minikube-linux-amd64"))
                  (sha256
                   (base32
                    "16vi7b6vkapc2w3f2yx8mzany5qqvrgvlshc58dambcn2q2hra48"))))
        (build-system binary-build-system)
        (inputs `((,gcc "lib")
              ,gcc-toolchain))
        (arguments
         (list
          #:substitutable? #f
          #:patchelf-plan
           #~'(("./minikube"
              ("gcc" "gcc-toolchain")))
          #:install-plan
          #~'(("minikube" "bin/"))
          #:phases
          #~(modify-phases %standard-phases
              (replace 'unpack
                (lambda _
                  (copy-file #$source "./minikube")
                  (chmod "minikube" #o644)))
              (add-before 'install 'chmod
                (lambda _
                  (chmod "minikube" #o555))))))
        (home-page "https://minikube.sigs.k8s.io")
        (synopsis "minikube is a tool for running local Kubernetes clusters.")
        (description "minikube implements a local Kubernetes cluster. minikube's primary goals are to be the best tool for local Kubernetes application development and to support all Kubernetes features that fit.")
        (license license:asl2.0)))

    minikube
4
4 comments
  • Looks like a segfault at the end there. Can you try and get a backtrace with gdb?

    Also the SEGV_ACCERR seems to mean permission denied (no idea here, maybe related to the earlier mmap?)

    • Looks like a segfault at the end there. Can you try and get a backtrace with gdb?

      Also the SEGV_ACCERR seems to mean permission denied (no idea here, maybe related to the earlier mmap?)

      Hey there, sorry for the wait! This is my first time using gdb. Here's what I got:

      10:04:37 worldofgeese@mahakala ~ → gdb /gnu/store/xhyv7k87gy9k368yrv6faray37z615cr-minikube-1.31.2/bin/minikube
      GNU gdb (GDB) 12.1
      Copyright (C) 2022 Free Software Foundation, Inc.
      License GPLv3+: GNU GPL version 3 or later 
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
      Type "show copying" and "show warranty" for details.
      This GDB was configured as "x86_64-unknown-linux-gnu".
      Type "show configuration" for configuration details.
      For bug reporting instructions, please see:
      .
      Find the GDB manual and other documentation resources online at:
          .
      
      For help, type "help".
      Type "apropos word" to search for commands related to "word"...
      Reading symbols from /gnu/store/xhyv7k87gy9k368yrv6faray37z615cr-minikube-1.31.2/bin/minikube...
      (No debugging symbols found in /gnu/store/xhyv7k87gy9k368yrv6faray37z615cr-minikube-1.31.2/bin/minikube)
      (gdb) run
      Starting program: /gnu/store/xhyv7k87gy9k368yrv6faray37z615cr-minikube-1.31.2/bin/minikube 
      
      Program received signal SIGSEGV, Segmentation fault.
      0x00007ffff7fe6c77 in dl_main () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2
      
      • Ok not much help there, for what is worth I tried building your recipe here. The full backtrace is not helpful - it just shows that the linker failed to run the binary:

        Program received signal SIGSEGV, Segmentation fault.
        0x00007ffff7fe6c77 in dl_main () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2
        (ins)(gdb) bt
        #0  0x00007ffff7fe6c77 in dl_main () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2
        #1  0x00007ffff7fe3074 in _dl_sysdep_start () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2
        #2  0x00007ffff7fe4c91 in _dl_start () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2
        #3  0x00007ffff7fe3a98 in _start () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2
        #4  0x0000000000000001 in ?? ()
        #5  0x00007fffffffdf31 in ?? ()
        #6  0x0000000000000000 in ?? ()
        

        Strangely my ldd shows nothing for the final minikube binary. file does show the guix interpreter though and it looks good:

        $ file /gnu/store/xhyv7k87gy9k368yrv6faray37z615cr-minikube-1.31.2/bin/minikube 
        /gnu/store/xhyv7k87gy9k368yrv6faray37z615cr-minikube-1.31.2/bin/minikube: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2, Go BuildID=aBEWfkldQzf4mlUsITym/a6aHGcy9omlZPRTvR8ta/1-lUpI-DPce979zTpJQy/jMuF_0TfmkRW2e3NFst2, not stripped
        

        readelf is a bit more helpful than ldd:

        $ readelf -d /gnu/store/xhyv7k87gy9k368yrv6faray37z615cr-minikube-1.31.2/bin/minikube 
        
        Dynamic section at offset 0x270 contains 21 entries:
          Tag        Type                         Name/Value
         0x000000000000001d (RUNPATH)            Library runpath: [/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib:/gnu/store/fzsz6gk7g5spr7j5jx5zh6rysd5r0n64-gcc-toolchain-11.3.0/lib]
         0x0000000000000004 (HASH)               0x2dcbb20
         0x0000000000000006 (SYMTAB)             0x2dcc080
         0x000000000000000b (SYMENT)             24 (bytes)
         0x0000000000000005 (STRTAB)             0x4003c0
         0x000000000000000a (STRSZ)              795 (bytes)
         0x0000000000000007 (RELA)               0x2dcb668
         0x0000000000000008 (RELASZ)             24 (bytes)
         0x0000000000000009 (RELAENT)            24 (bytes)
         0x0000000000000003 (PLTGOT)             0x3e65300
         0x0000000000000015 (DEBUG)              0x0
         0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
         0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
         0x0000000000000001 (NEEDED)             Shared library: [libresolv.so.2]
         0x000000006ffffffe (VERNEED)            0x2dcbaa0
         0x000000006fffffff (VERNEEDNUM)         3
         0x000000006ffffff0 (VERSYM)             0x2dcba40
         0x0000000000000014 (PLTREL)             RELA
         0x0000000000000002 (PLTRELSZ)           960 (bytes)
         0x0000000000000017 (JMPREL)             0x2dcb680
         0x0000000000000000 (NULL)               0x0
        

        Another way to check rpath is to use patchelf

        $ patchelf --print-rpath minikube 
        /gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib:/gnu/store/fzsz6gk7g5spr7j5jx5zh6rysd5r0n64-gcc-toolchain-11.3.0/lib
        

        The one thing that stands out to me there is that runpath lacks glibc. I also don't know why gcc is in there (but it was in the build recipe).

        So I added the libc to the runpath (your paths will be different)

        $ patchelf --set-rpath /gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib:/gnu/store/fzsz6gk7g5spr7j5jx5zh6rysd5r0n64-gcc-toolchain-11.3.0/lib:/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib minikube
        

        and voila

        $ ./minikube 
        minikube provisions and manages local Kubernetes clusters optimized for development workflows.
        
        Basic Commands:
          start            Starts a local Kubernetes cluster
          status           Gets the status of a local Kubernetes cluster
          stop             Stops a running local Kubernetes cluster
        (...)
        

        I never used patchelf-plan, so I'm not sure what you should do there, but maybe find other recipes that use it? I see some in nonguix that add glibc there.