core-updates warning: Not ready for GuixSD deployment

core-updates warning: Not ready for GuixSD deployment

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

I recommend you do not reconfigure any systems that are important based
on the current core-updates branch.

After applying the proposed fix for GPM [0], I reconfigured my headless
GuixSD system using core-updates.

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.

[0] <https://bugs.gnu.org/29975>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ludovic Courtès]

Hi Leo,

Leo Famulari <leo@famulari.name> 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.

It sounds like ‘usermod’ has overridden everything.  Could it be a
change in Shadow?

Thanks for the heads-up, I was considering reconfiguring my laptop, so
I’m glad I saw your warning.  :-)

Ludo’.

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

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> 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

  https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=4610ab7c9a5327df0d475262817bc081a5891aa8

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

Ludo’.


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---
$ /gnu/store/6caisrnj208hpwklm5clsznzwrlbihw5-guile-static-stripped-2.2.3/bin/guile -c '(pk (getpwnam "ludo"))'
guile: warning: failed to install locale
Backtrace:
           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---
$ /gnu/store/3ir873f4dsdl3aaj48iqykn6437ilk0p-guile-static-stripped-2.2.2/bin/guile -c '(pk (getpwnam "ludo"))'

;;; (#("ludo" "x" 1000 998 "Ludovic Court?s" "/home/ludo" "/gnu/store/ars9lm9jk9hgdifg0gqvf1jrvz5mdg1j-bash-4.4.12/bin/bash"))
--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---
openat(AT_FDCWD, "/gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.26.105-g0890d5379c/lib/tls//x86_64/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.26.105-g0890d5379c/lib/tls//libnss_compat.so.2", 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---
/tmp/guix-build-guile-static-2.2.3.drv-0/guile-2.2.3/libguile/posix.c:363: 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!

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

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

On Wed, Jan 10, 2018 at 10:13:51AM +0100, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> 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
> 
>   https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=4610ab7c9a5327df0d475262817bc081a5891aa8
> 
> Below is the message I wrote as I was investigating, if you’re curious.
> :-)

Thanks, I was very curious :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]