Summary: | "emerge --emptytree (-e) world" (or system) wants to downgrade majority of packages and generates some unusual package masks | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Jeff H <jah> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jah |
Priority: | High | Keywords: | InVCS |
Version: | 2.1 | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 210077, 288499 | ||
Attachments: | "emerge -evp --debug world" output, "emerge --info" output, /etc/make.conf /etc/portage/package.use |
Description
Jeff H
2009-09-02 13:27:51 UTC
Created attachment 202958 [details]
"emerge -evp --debug world" output, "emerge --info" output, /etc/make.conf /etc/portage/package.use
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`? 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 ~ # 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. 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. 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://81.93.240.111/gentoo-portage 1251814316: === Sync completed with rsync://81.93.240.111/gentoo-portage 1251814316: *** terminating. 1251886501: Started emerge on: Sep 02, 2009 06:15:01 1251886501: *** emerge sync 1251886501: === sync 1251886501: >>> Starting rsync with rsync://134.68.220.73/gentoo-portage 1251886522: === Sync completed with rsync://134.68.220.73/gentoo-portage 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-2.1.13.200902232204 to / 1243116272: === (2 of 2) Cleaning (sys-apps/gradm-2.1.13.200902232204::/usr/portage/sys-apps/gradm/gradm-2.1.13.200902232204.ebuild) 1243116272: === (2 of 2) Compiling/Merging (sys-apps/gradm-2.1.13.200902232204::/usr/portage/sys-apps/gradm/gradm-2.1.13.200902232204.ebuild) 1243116282: === (2 of 2) Merging (sys-apps/gradm-2.1.13.200902232204::/usr/portage/sys-apps/gradm/gradm-2.1.13.200902232204.ebuild) And I was able to do an emerge -e world successfully after this point. Correction, the --sync with --noreplace was manual. When run by cron there was no --noreplace. 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. 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`? 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-2.1.6.7 installed: sys-apps/portage-2.1.6.13 digraph: portage depends on ('installed', '/', 'sys-apps/portage-2.1.6.13', 'nomerge') (soft) ('installed', '/', 'sys-apps/portage-2.1.6.13', '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? 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 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 :) 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. Thanks Zac This is fixed in 2.2_rc41. This is fixed in 2.1.7. |