I've bought new SSD drive and start optimising system to minimise writes. One of my first moves was to mount /tmp as tmpfs. Unfortunately env eselect modules didn't like it. Each install was ending up with this error message: /usr/share/eselect/modules/env.eselect: line 89: 19428 Segmentation fault mv ${tmpprofile} ${ENVPROFILE} !!! Error: Couldn't move //tmp/profile.0mgGXq to /etc/profile.env! Original profile.env remains unchanged. Call stack: * create_profile_env (env.eselect:168) * do_update (env.eselect:299) * check_do (core.bash:24) * do_action (core.bash:89) * main (eselect:191) exiting despite "Original profile.env remains unchanged", permission on this file were changed from 644 to 400 resulting in: /usr/libexec/paludis/ebuild.bash: line 402: //etc/profile.env: Permission denied error sourcing //etc/profile.env This simple change fixes it. --- env.eselect.org 2009-11-12 11:47:28.934914565 +0000 +++ env.eselect 2009-11-12 11:47:54.210914341 +0000 @@ -163,7 +163,8 @@ # Move new file onto old one ENVPROFILE=$(canonicalise ${ENVPROFILE}) chmod a+r ${tmpprofile} - mv ${tmpprofile} ${ENVPROFILE} \ + # we use "cp" && "rm" as "mv" doesn't work on tmpfs + cp ${tmpprofile} ${ENVPROFILE} && rm ${tmpprofile} \ || die "Couldn't move ${tmpprofile} to ${ENVPROFILE}!\n Original profile.env remains unchanged." } Reproducible: Always
going further it seems it's libattr/coreutils/kernel-filesystem problem. mv segfaults when I move from tmpfs->ext4 (cp works fine though)
Doesn't look like an eselect problem.
Please post your 'emerge --info' output to help in reproducing your bug.
