[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: core-updates warning: Not ready for GuixSD deployment

From: Ludovic Courtès
Subject: Re: core-updates warning: Not ready for GuixSD deployment
Date: Wed, 10 Jan 2018 10:13:51 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Leo Famulari <address@hidden> skribis:

> After rebooting, I found that my user's numerical ID had changed, so I
> no longer owned any of my files. Not being able to read ~/.ssh means you
> can't log in remotely.
> Additionally, several of root's "dotfiles" had been replaced with their
> default versions, erasing my modifications. For example,
> ~root/.bash_profile no longer contained my modifications.
> Finally, my users's password no longer worked. I fixed this as root
> before I noticed that my user's files were inaccessible; I don't know if
> I could have avoided the password reset by re-chowning my files.

Long story short: this should be fixed by

Below is the message I wrote as I was investigating, if you’re curious.


Looking more closely, what (gnu build activation) does is this:

--8<---------------cut here---------------start------------->8---
(define* (ensure-user name group
                      #:key uid comment home create-home?
                      shell password system?
                      (supplementary-groups '())
                      (log-port (current-error-port))
                      #:rest rest)
  "Make sure user NAME exists and has the relevant settings."
  (if (false-if-exception (getpwnam name))
      (apply modify-user name group rest)
      (apply add-user name group rest)))
--8<---------------cut here---------------end--------------->8---

Presumably ‘getpwnam’ threw an exception in your case, so we went
calling ‘add-user’.  We first do that for the root user, and that ends
up wiping /etc/passwd altogether (instead of invoking ‘useradd’), which
is why subsequent invocations of ‘useradd’ created new user accounts,
copied skeletons, etc.

At boot time nscd is not running so libc should get the info directly
from /etc/passwd.

The new statically-linked Guile against glibc 2.26 fails getpwnam:

--8<---------------cut here---------------start------------->8---
 -c '(pk (getpwnam "ludo"))'
guile: warning: failed to install locale
           6 (apply-smob/1 #<catch-closure d2d100>)
In ice-9/boot-9.scm:
    705:2  5 (call-with-prompt ("prompt") #<procedure d456a0 at 
ice-9/eval.scm:330:13 ()> #<procedure default-prompt-handler (k proc)>)
In ice-9/eval.scm:
    619:8  4 (_ #(#(#<directory (guile-user) de1140>)))
In ice-9/command-line.scm:
   181:18  3 (_ #<input: string dfda80>)
In unknown file:
           2 (eval (pk (getpwnam "ludo")) #<directory (guile-user) de1140>)
In ice-9/eval.scm:
   191:35  1 (_ #f)
In unknown file:
           0 (getpw "ludo")

ERROR: In procedure getpw:
In procedure getpw: entry not found
--8<---------------cut here---------------end--------------->8---

… whereas the previous one (against glibc 2.25) works fine:

--8<---------------cut here---------------start------------->8---
 -c '(pk (getpwnam "ludo"))'

;;; (#("ludo" "x" 1000 998 "Ludovic Court?s" "/home/ludo" 
--8<---------------cut here---------------end--------------->8---

Looking more closely, glibc 2.26 tries to dlopen NSS libs (whereas
2.25’s libc.a included libnss_files functionality):

--8<---------------cut here---------------start------------->8---
 O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
 O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
--8<---------------cut here---------------end--------------->8---

Indeed, while linking guile statically we now have this message:

--8<---------------cut here---------------start------------->8---
warning: Using 'getpwnam' in statically linked applications requires at runtime 
the shared libraries from the glibc version used for linking
--8<---------------cut here---------------end--------------->8---

Why we didn’t have this problem before is unclear to me because
‘nss_interface_function’ in nss/nsswitch.h uses ‘static_link_warning’,
which produces the warning above, since 2012.

Wait, we lack the static NSS modules.  Hey, ‘glibc-for-bootstrap’ in
(gnu packages make-bootstrap) produces them in the “static” output but
we lack that afterwards!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]