Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 283513 - "emerge --emptytree (-e) world" (or system) wants to downgrade majority of packages and generates some unusual package masks
Summary: "emerge --emptytree (-e) world" (or system) wants to downgrade majority of p...
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: Portage team
Keywords: InVCS
Depends on:
Blocks: 210077 288499
  Show dependency tree
Reported: 2009-09-02 13:27 UTC by Jeff H
Modified: 2009-10-11 01:06 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---

"emerge -evp --debug world" output, "emerge --info" output, /etc/make.conf /etc/portage/package.use (emerge-emptytree-debug.txt,232.36 KB, text/plain)
2009-09-02 13:30 UTC, Jeff H

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff H 2009-09-02 13:27:51 UTC
While doing a new amd64 installation, after unpacking the stage3 tarball (stage3-amd64-20090813.tar.bz2) and the latest portage snapshot (Aug 29) then installing enough packages to boot (grub, lvm2 and hardened-sources plus ccache) and doing a --sync, I tried to do an "emerge -eva world" for the first time.  emerge wanted to downgrade most of my packages and also produced some unusual package masks, flagging quite a few currently installed packages as being (masked by: ); masked but no reason given for the mask.  emerge --update, --deep and --newuse produce the normally expected results, no downgrades or package masks.  The new install is my desktop workstation but I have four other Gentoo systems, all servers.  After encountering this problem with my new install I had a look at the other systems and discovered that they had also developed the same problem.  

Reproducible: Always

Steps to Reproduce:
I've been trying to figure out how not to reproduce it, it happens every time.

Actual Results:  
Total: 82 packages (21 upgrades, 52 downgrades, 4 new, 5 in new slots), Size of downloads: 198,279 kB
Conflict: 4 blocks (4 unsatisfied)

See attachment for "emerge -evp --debug" output

The new install and three of the others are on my home network.  The new install is an Athlon 64 X2 5600+ Windsor 2.8GHz 2 x 1MB L2 Cache Socket AM2 89W Dual-Core processor.  The other three are Dual-Core AMD Opteron 2200 series processors.  The fifth system is located remotely (co-located) and has had Gentoo installed for five or six years.  It's an Athlon XP 3200+.  As the new install is my working desktop machine and I was installing Gentoo to replace my Windows installation (with the intention of running Windows as a KVM guest) I was swapping drives while working on the Gentoo install.  Since I ran into problems I switched back to Windows and changed focus for troubleshooting to one of the other machines that is a fairly recent install with minimal configuration changes.  I intend to use this machine as an asterisk server but wasn't ready to spring for the asterisk hardware yet so I just did a fairly basic install and let it sit.  In fact I powered it down on August 20 and just powered it up yesterday (Sep 1) to see if it had the same issue.  I did the install on May 23, 2009, did an emerge -e system/emerge -e world twice, the last one on July 15. On July 16 I installed nfs-utils which pulled in three more packages and then on July 17 I did an update, emerge -uv. Cron has been doing a --sync once a day.  This system and all the others are all stable branch installs, defaulting to ACCEPT_KEYWORDS="amd64" with the exception of the Athlon XP which is ACCEPT_KEYWORDS="x86".  It might be worth noting that I had been testing Gentoo, KVM and Gnome on my workstation for several months in my spare time.  The test install was with the unstable branch (~amd64) and worked perfectly.  Once I was satisfied with the test I wiped it and attempted to install using the stable branch for my permanent install.  That's when I first encountered the problem.  

Because the problem is so odd, I can't shake the feeling that I am looking past the basics and missing some simple mistake but posting the issue in the Portage forum didn't produce any answers.  See that post for some history:
Comment 1 Jeff H 2009-09-02 13:30:50 UTC
Created attachment 202958 [details]
"emerge -evp --debug world" output, "emerge --info" output, /etc/make.conf /etc/portage/package.use
Comment 2 Zac Medico gentoo-dev 2009-09-02 18:24:06 UTC
Are you sure that default/linux/amd64/2008.0 is a valid profile? Is that one show in in the output of `eselect profile list`?
Comment 3 Jeff H 2009-09-02 18:54:05 UTC
Yes.  I have tried 2008.0, 2008.0/desktop, 10.0 and 10.0/desktop all with the same results.

root@asterisk ~ # eselect profile list
Available profile symlink targets:
  [1]   default/linux/amd64/2008.0 *
  [2]   default/linux/amd64/2008.0/desktop
  [3]   default/linux/amd64/2008.0/developer
  [4]   default/linux/amd64/2008.0/no-multilib
  [5]   default/linux/amd64/2008.0/server
  [6]   default/linux/amd64/10.0
  [7]   default/linux/amd64/10.0/desktop
  [8]   default/linux/amd64/10.0/developer
  [9]   default/linux/amd64/10.0/no-multilib
  [10]  default/linux/amd64/10.0/server
  [11]  hardened/amd64
  [12]  hardened/amd64/multilib
  [13]  selinux/2007.0/amd64
  [14]  selinux/2007.0/amd64/hardened
  [15]  selinux/v2refpolicy/amd64
  [16]  selinux/v2refpolicy/amd64/desktop
  [17]  selinux/v2refpolicy/amd64/developer
  [18]  selinux/v2refpolicy/amd64/hardened
  [19]  selinux/v2refpolicy/amd64/server
  [20]  hardened/linux/amd64
root@asterisk ~ #

Not sure if it could be related but I notice that 10.0 came out sometime between the time when I last did a successful emerge -e world and now (on my new asterisk server):

root@asterisk ~ # ll /usr/portage/profiles/default/linux/amd64
total 20
drwxr-xr-x  4 portage portage 4096 Aug  6 02:41 .
drwxr-xr-x 14 portage portage 4096 Aug 20 15:09 ..
drwxr-xr-x  6 root    root    4096 Aug 17 15:08 10.0  <-----
drwxr-xr-x  6 portage portage 4096 Apr 30  2008 2008.0
-rw-r--r--  1 portage portage   37 Apr  1  2008 parent
root@asterisk ~ #
Comment 4 Zac Medico gentoo-dev 2009-09-03 00:46:37 UTC
Your debug output shows --noreplace in the options, which is abnormal:

myopts {'--noreplace': True, '--pretend': True, '--debug': True, '--verbose': True, '--emptytree': True}

Since you don't seem to have EMERGE_DEFAULT_OPTS set, the source of that option is somewhat mysterious.
Comment 5 Jeff H 2009-09-03 01:08:28 UTC
I agree, I noticed that too. I assumed it was some sort of default because I never specified it on the command line or in any config files.  In fact, I'm completely unfamiliar with that option.
Comment 6 Jeff H 2009-09-03 01:16:25 UTC
Checking emerge.log on my asterisk server, I notice it's always inserted whenever I run an emerge.  I thought I had seen it in more than just that debug output.  Check this out:

1251814278: Started emerge on: Sep 01, 2009 10:11:18
1251814278:  *** emerge --noreplace sync
1251814278:  === sync
1251814279: >>> Starting rsync with rsync://
1251814316: === Sync completed with rsync://
1251814316:  *** terminating.
1251886501: Started emerge on: Sep 02, 2009 06:15:01
1251886501:  *** emerge  sync
1251886501:  === sync
1251886501: >>> Starting rsync with rsync://
1251886522: === Sync completed with rsync://
1251886522:  *** terminating.

The above is cron running a sync:

15 06 * * * /usr/bin/emerge --sync > /dev/null 2>&1

However, checking back to the beginning of the log i see that it has been inserted since the day I installed this system:

1243116025:  ::: completed emerge (1 of 1) sys-kernel/hardened-sources-2.6.28-r7 to /
1243116025:  *** Finished. Cleaning up...
1243116025:  *** exiting successfully.
1243116025:  *** terminating.
1243116247: Started emerge on: May 23, 2009 18:04:07
1243116247:  *** emerge --noreplace --ask =sys-apps/gradm-2.1.13*
1243116257:  >>> emerge (1 of 2) sys-apps/paxctl-0.5 to /
1243116265:  === (1 of 2) Cleaning (sys-apps/paxctl-0.5::/usr/portage/sys-apps/paxctl/paxctl-0.5.ebuild)
1243116265:  === (1 of 2) Compiling/Merging (sys-apps/paxctl-0.5::/usr/portage/sys-apps/paxctl/paxctl-0.5.ebuild)
1243116269:  === (1 of 2) Merging (sys-apps/paxctl-0.5::/usr/portage/sys-apps/paxctl/paxctl-0.5.ebuild)
1243116271:  === (1 of 2) Post-Build Cleaning (sys-apps/paxctl-0.5::/usr/portage/sys-apps/paxctl/paxctl-0.5.ebuild)
1243116271:  ::: completed emerge (1 of 2) sys-apps/paxctl-0.5 to /
1243116271:  >>> emerge (2 of 2) sys-apps/gradm- to /
1243116272:  === (2 of 2) Cleaning (sys-apps/gradm-
1243116272:  === (2 of 2) Compiling/Merging (sys-apps/gradm-
1243116282:  === (2 of 2) Merging (sys-apps/gradm-

And I was able to do an emerge -e world successfully after this point.
Comment 7 Jeff H 2009-09-03 01:18:29 UTC
Correction, the --sync with --noreplace was manual.  When run by cron there was no --noreplace.
Comment 8 Jeff H 2009-09-03 01:28:21 UTC
Sorry for the multiple entries... Looking back some more I see that the two times I successfully ran "emerge --emptytree world", --noreplace was not inserted.
Comment 9 Zac Medico gentoo-dev 2009-09-03 01:40:41 UTC
The --noreplace option seems to be the problem, since that makes the installed version of the package appear to be masked. Is that option inserted for every command? For example, how about `emerge -vp --debug portage`?
Comment 10 Jeff H 2009-09-03 02:06:45 UTC
Seems so:

root@asterisk ~ # emerge -vp --debug portage                               
myaction None
myopts {'--noreplace': True, '--pretend': True, '--debug': True, '--verbose': True}

These are the packages that would be merged, in order:

Calculating dependencies  
      Arg: portage
     Atom: sys-apps/portage
   ebuild: sys-apps/portage-
installed: sys-apps/portage-


portage depends on
  ('installed', '/', 'sys-apps/portage-', 'nomerge') (soft)
('installed', '/', 'sys-apps/portage-', 'nomerge') (no children)

   ebuild: app-admin/eselect-1.1.1
   ebuild: app-admin/eselect-1.1.1
installed: app-admin/eselect-1.0.12
installed: app-admin/eselect-news-20080320
installed: app-admin/eselect-news-20080320
... done!

Total: 0 packages, Size of downloads: 0 kB
root@asterisk ~ # 

Any ideas about where it come be coming from?
Comment 11 Zac Medico gentoo-dev 2009-09-03 02:28:19 UTC
The most likely suspect is EMERGE_DEFAULT_OPTS, but it didn't show in your emerge --info output.

You can try this command to double check that variable:

  portageq envvar EMERGE_DEFAULT_OPTS

Also, it could also be that you somehow got an alias for emerge. The shell should report that if you run this command:

 type emerge
Comment 12 Jeff H 2009-09-03 02:59:36 UTC
It's an alias:

root@asterisk ~ # type emerge
emerge is aliased to `/usr/bin/emerge -n'
root@asterisk ~ #

And I found it in my /root/.bashrc:

alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'
alias rndc='rndc -k /usr/local/jail1/etc/bind/rndc.key'
alias emerge='/usr/bin/emerge -n'

I do copy that file around to every machine I install early on, mainly for the "rm -i", cp, mv, etc.  I have no recollection of putting the emerge alias in there though.  I wasn't even familiar with what it did until you mentioned it. I guess I must have put it in one of the older machines for some long forgotten reason and then propagated it to the others.

I'm really sorry I wasted your time troubleshooting my bonehead mistake.  Since nobody else seemed to be having the same problem I had a nagging fear that it was going to turn out to be something like this.  I am grateful that you zeroed in on the problem so quickly though.  I don't know how long it would have taken me to figure out the root cause, much less go looking for it in my .bashrc.  Removing the alias obviously fixed the problem.  Let me know if there is anything I can do to work off my support debt :)
Comment 13 Zac Medico gentoo-dev 2009-09-03 03:28:05 UTC
No problem. In svn r14181 I've added a check inside emerge so that it bails out with an error message if both --noreplace and --emptytree are enabled simultaneously.
Comment 14 Jeff H 2009-09-03 14:31:01 UTC
Thanks Zac
Comment 15 Zac Medico gentoo-dev 2009-09-20 00:24:19 UTC
This is fixed in 2.2_rc41.
Comment 16 Zac Medico gentoo-dev 2009-10-11 01:06:08 UTC
This is fixed in 2.1.7.