Do "groupadd kvm" before "emerge qemu-kvm" (-; Reproducible: Didn't try
app-emulation/qemu-kvm-0.12.5-r (during emerging) tries to add group "kvm" using command "groupadd -r" but groupadd says: "groupadd: invalid option -- 'r'".
Please attach your emerge --info
(In reply to comment #2) > Please attach your emerge --info > # emerge --info Portage 2.1.8.3 (default/linux/x86/10.0, gcc-4.3.3, glibc-2.11.2-r0, 2.6.28-gentoo-r6 i686) ================================================================= System uname: Linux-2.6.28-gentoo-r6-i686-Intel-R-_Core-TM-2_CPU_T5600_@_1.83GHz-with-gentoo-1.12.11.1 Timestamp of tree: Wed, 27 Oct 2010 09:00:01 +0000 app-shells/bash: 3.2_p17-r1 dev-java/java-config: 2.1.7 dev-lang/python: 2.4.4-r13, 2.5.4-r2, 2.6.5-r3 dev-util/cmake: 2.6.2-r1 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 2.3-r1 sys-devel/autoconf: 2.13, 2.65-r1 sys-devel/automake: 1.4_p6, 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1, 1.11.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc: 3.3.6-r1, 4.1.2, 4.3.3-r2 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.6b sys-devel/make: 3.81 virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -pipe -msse -msse2 -mmmx -mssse3" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O3 -pipe -msse -msse2 -mmmx -mssse3" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://mirror.yandex.ru/gentoo-distfiles/ http://gentoo.kiev.ua/ftp/" LANG="C" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa apache2 berkdb bluetooth bzip2 cgi cli cracklib crypt ctype cups curl cxx dbus dri dvd emerald encode ffmpeg fftw firefox flac fortran ftp gdbm glitz gpm gsm gtk iconv icq ipv6 jack jpeg lame libnotify mmx modules mozilla mp3 mpeg mplayer mudflap mysql ncurses network nls nptl nptlonly ogg opengl openmp oss pam pcmcia pcntl pcre perl php png pppd python qt3 qt3support qt4 qtsupport readline samba sdl session sse sse2 ssl ssse3 sysfs tcpd theora threads tokenizer unicode v4l v4l2 win32codecs x264 x86 xcb xml xorg xsl xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" PHP_TARGETS="php5-2" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fglrx v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
What's the sys-apps/shadow version?
(In reply to comment #4) > What's the sys-apps/shadow version? > # emerge -s sys-apps/shadow Searching... [ Results for search key : sys-apps/shadow ] [ Applications found : 0 ]
You don't have shadow installed?
*** Bug 347871 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > You don't have shadow installed? > Looks like *something* provides an executable called groupadd. :)
In response to the question on the other bug: $ which groupadd /usr/sbin/groupadd $ emerge -pvq sys-apps/shadow [ebuild U ] sys-apps/shadow-4.1.4.2-r6 [4.1.4.2] USE="cracklib nls pam -audit (-selinux) -skey" $ portageq owners / /usr/sbin/groupadd sys-apps/shadow-4.1.4.2 /usr/sbin/groupadd
(In reply to comment #9) > $ emerge -pvq sys-apps/shadow > [ebuild U ] sys-apps/shadow-4.1.4.2-r6 [4.1.4.2] USE="cracklib nls pam > -audit (-selinux) -skey" OK, so there is a sys-apps/shadow upgrade due. Does everything go well after that upgrade? (emerge -u sys-apps/shadow)
Oh bummer, just realised I posted the emerge output for the wrong PC. Here's the one with the problem: $ portageq owners / /usr/sbin/groupadd sys-apps/shadow-4.0.18.2 /usr/sbin/groupadd I can't upgrade it atm because of: The current version of portage supports EAPI '2'. You must upgrade to a newer version of portage before EAPI masked packages can be installed. And I don't really have the time to do an emerge world right now. However with sys-apps/shadow-4.1.4.2 groupadd -r works, so perhaps that would be a good baseline for an additional dependency?
(In reply to comment #11) > I can't upgrade it atm because of: > > The current version of portage supports EAPI '2'. You must upgrade to a > newer version of portage before EAPI masked packages can be installed. Why don't you simply do `emerge -u portage' and then try again?
Portage won't upgrade because my Python install is too old, so I have to upgrade Python first, and then Python needs some other programs updated first, and then those programs won't upgrade because I have blocking packages currently installed, etc, etc. The problem is this is a server so it doesn't get upgraded very often, and Gentoo falls flat requiring extensive manual intervention if you don't upgrade every six months or so. I'm currently in the process of switching the machine over to Debian (hence the Puppet install) which seems better suited to powering servers. I'll just keep Gentoo on my desktop machines where it's easier to do regular upgrades.
sys-apps/shadow-4.0.18.2 went stable in February 2008, with amd64 stabilisation trailing the other arches by half a month. Now you know why you need to update the world target at least every couple of months, assuming you don't actually use the system in any way so you will never see any security issues. So keep it turned off, and turn it on every couple of months, do a full upgrade, and turn it off again. Or update more often, keep it up to date so it is as secure as possible, and you'll never see these problems with updating the system to what is current. It actually looks like none of the current sys-apps/shadow ebuilds use the EAPI variable, which means they are all still on EAPI=0, and that `USE="-*" emerge -u sys-apps/shadow' should probably work. Meanwhile, there is no bug to fix here, unless you expect Gentoo to start being backward compatible by 2.5 years. There is very likely a way out of this mess, but a bug tracker is not the place to communicate about it, mostly because you won't as easily attract the right audience as you would on http://forums.gentoo.org/, but mainly because you appear to have more than one issue, so by the end of your train of problems, we'd be at comment #500 with still no bug to solve anywhere in sight. If it helps, you might also try irc://chat.freenode.net/#gentoo for more direct conversation about this issue you have.
You're right this isn't the correct place, but just for the record I have had this discussion over at the forums and the end result was that Gentoo isn't designed for an environment where frequent updates are impractical - i.e. most server environments. The problem is that unlike desktop PCs, when servers break they can take out critical systems, and by no fault of Gentoo it's not uncommon to have to adjust configuration files etc. when upgrading to new versions of software - ignoring those environments where there are change control procedures and documentation in place. I used to dislike distros like Red Hat and Debian because the software took so long to be upgraded, but since I've had to start maintaining a number of servers I can see why it is the case. Having to deal with the odd security patch is trouble enough, let alone hundreds of packages all over the system! So in many ways it's not the fault of Gentoo, it's only because Gentoo requires such frequent system-wide upgrades that it gets in the way. The only way this could be solved was if Gentoo was better tested against ancient package versions, so it would be possible to do an 'emerge world' only once a year without having to deal with all the resulting errors you get if you do this now. But this would take a considerable amount of effort on the part of the Gentoo devs which I am sure is better spent elsewhere. Anyway I just wanted to make it clear I'm not complaining about Gentoo, it's just that the Gentoo philosophy doesn't always fit every use case. If you do wish to discuss further, by all means post a forum link and I'll follow up there.
Most of what you are saying about server environments is based on the assumption that each server compiles its own packages. This doesn't have to be the case: using a staging server, perhaps a testing server in between and ultimately rolling new packages all at once out to your production environment, including the necessary runtime configuration changes as packaged in the testing or staging environments, as required, would prevent some service disruptions and would allow you to schedule remaining service interruptions all at once, with minimal downtime, at off hours. Even the "server distros" that you named that "freeze" features (software versions) should see updates deployed as described above, instead of updating software without any research into compile time / run time configuration changes and seeing "if everything still works" when it's too late.
Interesting idea. It could work, but there's a middle ground which I am stuck in. One or two servers and you can handle everything manually, hundreds of servers and this sort of automation would be great, but I only have a dozen or so servers. Too much to do manually, not enough resources to set up testing/staging environments. At any rate, my problem boils down to one issue: I cannot upgrade often enough to suit the Gentoo schedule. And when I don't do this, the eventual upgrade requires a couple of days of downtime while broken emerges are solved (e.g. the cause of this bug - which would have been solved if the relevant dependency was included, but as you pointed out it was marked stable so long ago it was assumed everyone had upgraded already.) I don't think running a testing/staging environment would help if the emerge world can only be done say once a year, because although you would get some forewarning of the errors likely to be encountered, you'd still get those same errors when performing the production upgrade. Not to mention that after the discovery of an obscure bug it can be impossible to roll back to the previous version as it's no longer in the Portage tree...
