Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
I'm using the 2008.0 beta 2 install cd for amd64. I haven't booted into my system yet (trying to merge system packages). All merge are concerned. Sample lines: /usr/lib64/portage/bin/ebuild.sh: line 1658: /bin/tr: Argument list too long /usr/lib64/portage/bin/ebuild.sh: line 1658: /bin/sort: Argument list too long /usr/lib64/portage/bin/ebuild.sh: line 1444: /usr/lib64/portage/bin/filter-bash-environment.py: Argument list too long /usr/lib64/portage/bin/ebuild.sh: line 1791: /bin/bzip2: Argument list too long Finally fails with: !!! FAILED postinst:1 Points to bugs 190128 and 200313 but I couldn't grasp what was relevant with them. Package seems to get correctly merged, but this does break multi package merges since portage breaks at the first error Reproducible: Always Steps to Reproduce: 1. emerge awk 2. see
emerge --info, please.
emerge --nodeps portage might help too.
Created an attachment (id=153155) [details] emerge --info output I've already done "emerge --nodeps portage" but unfortunately this hasn't solved the problem. I've attached the results of the emerge --info as a text file.
There should be only one of these: app-shells/bash: 3.2_p17-r1, 3.2_p33 Could you try and re-emerge bash?
I've re-emerged bash, but this didn't solve the problem. I'm using the app-shell/bash-3.2_p33 ebuild. bash --version returns "GNU bash, version 3.2.33(1)-release (x86_64-pc-linux-gnu)"
I have added "set -x" and "set -x" around the filter-bash-environment.py script file. Considering that there are only simple quotes on the command lines, I don't think there is any globbing taking place, and the length of the command line doesn't explain the "Argument list too long error message". Any clue ? /usr/lib64/portage/bin/filter-bash-environment.py '(^|^declare[[:space:]]+-[^[:space:]]+[[:space:]]+|^export[[:space:]]+)(DIRSTACK|EUID|FUNCNAME|GROUPS|PIPESTATUS|PPID|SHELLOPTS|UID|D|EBUILD|EBUILD_PHASE|EBUILD_SH_ARGS|EMERGE_FROM|FILESDIR|PORTAGE_BINPKG_FILE|PORTAGE_BIN_PATH|PORTAGE_IUSE|PORTAGE_PYM_PATH|PORTAGE_MUTABLE_FILTERED_VARS|PORTAGE_SAVED_READONLY_VARS|PORTAGE_TMPDIR|T|WORKDIR|BASH_[_[:alnum:]]*|PATH|SANDBOX_[_[:alnum:]]*)=.*' /usr/lib64/portage/bin/ebuild.sh: line 1448: /usr/lib64/portage/bin/filter-bash-environment.py: Argument list too long
This bug is definitely portage related ! I reinstalled a fresh 2007.0 on my box. First thing I did was emerge --nodeps portage (can't do with deps due to an obscure problem with bash). Guess what ? It started to fail the same way all over again ! But with the provided version 2.1.2.2 everything worked fine. Too bad it's out of the tree ...
I had ran to this problem with the minimal install cd and after some digging I have found that the intstall cd sets the $vga env var to some binnay data that later is expanded to \xxx\xxx values by the ebuild.sh and for some reason it grows until everything you call with that enviromen returns an Argument line too long error. A quick fix is to unset the $vga variable.
thanks for the tip ... i would post the output of `emerge --verbose --info` as an attachment
Created an attachment (id=155061) [details] emerge -v --info
blackd: sorry, i meant for drozofil to post his
with my you can see the $vga value and he already have posted his
he posted --info, not --info --verbose
Updated portage today (armed with a full dump of my disk in case stuff go wild), and ***no problem***. The only thing that have changed is that I'm in my fully functionnal gentoo environment (i.e. booting on it) while doing this, and not into the livecd chrooted environment with the framebuffer ($VGA ?). Now I could completely start all over again a fresh install to exhibit the problem, as I'm sure it's 100% reproductible. I've checked $VGA prior updating and after, and in both cases it was empty. Sorry not beeing able to give more info. Anything you want me to take back if I'm to spend a few hours installing something that will be eventually broken at some point ?
$VGA is not the same as $vga
Created an attachment (id=156805) [details] emerge --verbose --info i've stepped into the very same problem: > /usr/lib64/portage/bin/ebuild.sh: line 1492: /bin/touch: Argument list too long unmerging app-portage/eix-0.10.5.ebuild I've seen the long vga string in the environment file but I've got no $vga variables defined, nor I didn't understand where I should add/remove it.
I forgot to mention that this happens on "postrm" phase.
just do "unset vga" before emerging something releng: can we track down this vga env var and squash it ? i dont think it needs to be exported to the environment anywhere ...
Why are we being "blamed" here? He said that it happened with 2007.0. If this were a problem with the media, *somebody* would have hit it in the last year.
please refrain from using words like "blame" and assist in the debug process instead of trying to point fingers the original reporter said they're using 2008 beta 2 ... other people have seen the same issue with older versions. considering release team creates/boots livecds quite often, it's a lot easier for you to boot up a recent image and see if 'vga' is set than it is for me ... especially seeing as how i havent booted up a livecd in over a year ...
I have tried this on both 2007.0 and 2008 beta 2 and the problem shows on both after first portage update.
you see 'vga' in the env while in the livecd (not chroot), correct ? could you try doing: grep -Ir '\<vga\>' /etc /lib* and posting the results
Hmm it appears that this is hardware dependent because I cannot reproduce it on my work machine or in vmware VM. You´ll have to wait until I return home.
I do have the same problem on two of my amd64 machines, regularly during postinstall (after the old package is unmerged). Now, while testing an ebuild I'm working on I received it earlier: ebuild OpenXPKI-0.9.1263.ebuild install >>> Existing ${T}/environment for 'OpenXPKI-0.9.1263' will be sourced. Run >>> 'clean' to start with a fresh environment. * OpenXPKI-0.9.1263.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking OpenXPKI-0.9.1263.tar.gz ;-) ... [ ok ] /usr/lib64/portage/bin/ebuild.sh: line 1504: /bin/touch: Argument list too long * * ERROR: dev-perl/OpenXPKI-0.9.1263 failed. Line 1504 is touch "${T}/environment.success". dumping ${T} shows /tmp/portage/dev-perl/OpenXPKI-0.9.1263/temp/environment.success, which is not too long. ok, i changed the /usr/lib64/portage/bin/ebuild.sh preprocess_ebuild_env() function to this: preprocess_ebuild_env() { [...] ( export SANDBOX_ON=1 set > /tmp/dbg1 source "${T}/environment" || exit $? export SANDBOX_ON=0 set > /tmp/dbg2 source "${PORTAGE_BIN_PATH}/isolated-functions.sh" || exit $? save_ebuild_env || exit $? set > /tmp/dbg3 touch "${T}/environment.success" || exit $? ) > "${T}/environment.filtered" [...] The dbg2 file id 600kb(!) bigger than dbg1. Is has the following extra: KRB5CCNAME=$'\320\320\001\001\001\001\001\001\001\001\001\001\001\001\001\ and a lot more of this. It is in the imported environment file as well. I actually have no clue yet where it is set. Unsetting KRB5CCNAME before running ebuild/emerge solves the problem.
Another short update: /lib64/security]>grep -r KRB5CCNAME . Binary file ./pam_mount.so matches {root}-(Tue Jun 17 14:05:05)-<dnnote> [/lib64/security]>strings ./pam_mount.so | grep KRB5CCNAME KRB5CCNAME pam_mount(%s:%u) KRB5CCNAME setenv failed Maybe this is a candidate. Both of the machines I experienced the bug on are relying on pam_mount for encrypted home directories. Timewise correlation to the upgrade to pam_mount-0.38+ could fit.
your issue is unrelated. you should open a different bug.
grep -Ir '\<vga\>' /etc /lib* /etc/brltty.conf:#screen-parameters lx:Hfb=auto # [auto,vga,fb,0-7] striped some "No such file or directory" warnings no copy&paste in links2 Any way this seems to be hardware related because at least for me the $vga var is set to some binary value only on PCs with nvidia graphics (any one that can verify that)
So little more digging and i found that the vga var is actually passed as parameter to the kernel by grub (2008 beta 2 uses grub) any way there is a problem whit the command line processing by the kernel OR the way the command line is passed to the kernel and some binary data is appended the the last parameter (zero termination any one?). The initrd scripts use the /proc/cmdline (command line passed to the kernel) to do some initializations and for some reason sets the vga var with the value of the vga parameter. So in my opinion the problem comes from the way kernel cmdline is passed to or processed by the kernel. And for some reason this does not manifest it self on all hardware configurations.
there was a bug with grub where it wouldnt correctly NUL terminate the cmdline string, but that should be fixed in the latest version but i thought the livecd used like syslinux as the boot loader, so grub wouldnt be involved here at all i dont think there's a need for the initrd to bleed any environment settings from the /proc/cmdline into the shell environment ... if you look at /proc/<pid>/environment, you should be able to trace the parents of your shell and see what process first has the setting ...
I´ve added "debug" to the kernel cmd line this causes the initrd script to spawn a shell before giving control to the real init. # cat /proc/1/environ HOME=/ TERM=linux looptype=squashfs loop=/image.squashfs vga=791.....(binary data) The above lines are join together, cat strips the \0 chars. The process with PID 1 is "/bin/sh /init dokeymap cdroot" It seems that initrd leaks some kernel parameters in the environment. On a production system where the genkernel initrd is used there some kernel parameters like "real_root=/dev/evms/root" in the environment of the real init proces but they are missing in the other processes. p.s. This all is for 2008 beta2. I´ll it with 2007.0 this evening.
It appears that there is no such problem with 2007.0 at least not with the $vga var as it's not with binary value.
Okay, so the *real* issue here is the grub bug causing non-termination of the kernel commandline string. The 2008.0_beta[12] x86/amd64 CDs used grub, but the 2008.0 final will go back to isolinux due to other issues we ran into. If you encounter this from your normal system, upgrade grub and reinstall it.
This is a duplicate of 216307. Upgrade your grub fully folks. Make _really_ sure that the files in /boot/grub/ get updated. *** This bug has been marked as a duplicate of bug 216307 ***
Actually I do not agree. Sure grub causes the problem but still portage have to be prepared to handle such rough environment, or at least has to show a decent error message.
this isnt a dupe of grub persay ... the install media needs updating
Robin: also, genkernel shouldnt go bleeding random things from /proc/cmdline into the environment
Do you see where the genkernel init scripts are doing this? I only see 2 variables actually being exported (which is required for it to bleed into another process's env, correct?). Those variables are CDBOOT and MLIST.
Well exported or not they do exist. Try less /proc/1/environ In a system that uses the genkernel initrd. Main has "real_root=/..." Or you can add debug parameter to the kernel and inspect the environment of the debug shell.
I want to comment that I also ran into this problem when installing gentoo from a 2008.0 beta2 minimal install CD. I had to boot via CD / chroot several times (problems with the hardware, i.e. no boot from hard-disk) before the error occured for the fist time, though. Maybe that helps.
This is "fixed" on the 2008.0 final install media, since we've switched back to isolinux for other reasons. While genkernel still leaks a few vars to the env, it's very few and they'll get fixed in an upcoming refactoring of the genkernel code.
im mot sure if this needs to be reopened or not, but I just started installing from the 2008.0 amd64 non beta disk and got the same exact error. When I used the command "echo $vga" it printed gibberish and messed up the characters on the console. It looks like you are still using grub as the boot loader for the amd64 minnimal cd.
Well it appears that it is not fixed so I suggest that you reopen it.
I tried but I don't have the privileges to do that.
I still have issues with this problem. I need an advice because I don't know if I need to open a different bug or not. I started having a 'postrm' error (touch arg too long - vga) upgrading eix; after reading this thread I tried to upgrade grub, but I got the same error, so currently I have two ebuilds that can't be uninstalled. In the root shell `echo $vga` produces nothing, while looking at the ebuild environment I get the long vga string and also this string: declare -x vga="791�������������������������������������������������ȈJ�" Any help will be very much appreciated! thanks!
It looks like the amd64 minimal CD got built with grub instead of isolinux somehow. Reopening until we put out a -r1.
(In reply to comment #44) I must underline that my problem happens on an already installed machine, that used the 2008_beta2 as install medium. as stated before the only place where the vga mess happens is during postrm time, maybe only in sandbox.
Yes, because you're using the old grub version that the CD was. Upgrade your grub and be sure to re-install it into the MBR.
Well looks like it is working for me now. I didn't really do anything to fix it. After about 4-5 restarts using the minimal amd64 disk it compiled the kernel, a few needed tools and grub so I could boot it without the cd. When I was messing around with the grub.conf file I noticed if you disable the framebuffer it would cause it to not find the root partition on the cd and load the ash shell for recovery.
(In reply to comment #47) > Yes, because you're using the old grub version that the CD was. Upgrade your > grub and be sure to re-install it into the MBR. > I've upgraded to grub-0.97-r6, I've reflashed the MBR but once rebooted I still get the error when trying to emerge --clean on postrm phase. The grub-1* ebuild is just broken (can't detect lzo-2*) so I hope you don't mean that. did I miss something?
Did you run 'emerge --config' for grub? You have to do that in new versions to copy the new files to /boot/grub/, iirc.
(In reply to comment #50) > Did you run 'emerge --config' for grub? You have to do that in new versions to > copy the new files to /boot/grub/, iirc. > the --config part, as stated in the einfo msg, is only to be done if the files are to be copied elsewhere, btw nothing changed, I did, specifying /boot as destination directory and rerun setup on the MBR. No way. Still have the postrm errors.
I've got this problem too, on various packages of my gentoo 2008.0 amd64 box. Tried doing an emerge -e world because I added a compiler flag (-fno-strict-aliasing because the compiler warnings in several packages were scaring me). Only used stable packages. I have seen the binary garbage being passed to the kernel on the minimal install iso, but this is occurring in the already installed and self-booting OS with up-to-date grub and bash. I see no excessively long environment variables, $vga is not set. Portage 2.1.4.4 (default/linux/amd64/2008.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.25-gentoo-r6 x86_64) ================================================================= System uname: 2.6.25-gentoo-r6 x86_64 AMD Athlon(tm) 64 Processor 3500+ Timestamp of tree: Sun, 20 Jul 2008 14:45:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.5.2-r5 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.7.9-r1, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O3 -pipe -fomit-frame-pointer -mmmx -msse -msse2 -m3dnow -fno-strict-aliasing" CHOST="x86_64-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" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=athlon64 -O3 -pipe -fomit-frame-pointer -mmmx -msse -msse2 -m3dnow -fno-strict-aliasing" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://de-mirror.org/distro/gentoo/ " LDFLAGS="-Wl,-O1" LINGUAS="de" PKGDIR="/usr/portage/packages" 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" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow X a52 aac acl acpi alsa amd64 apache2 apm bash-completion berkdb bzip2 cairo cdr cli cracklib crypt ctype cups cxx dri dvd dvdr encode exif expat ffmpeg firefox flac fontconfig fortran ftp gd gdbm gif gpm graphviz gtk hal hddtemp iconv imagemagick imap innodb ipv6 isdnlog java jpeg jpeg2k kde lame lua lzo mad matroska midi mime mmx mng mono mozilla mp3 mpeg mplayer mudflap multilib mysql mysqli ncurses nls nocd nptl nptlonly ogg openal openexr opengl openmp oss pam pch pcre pdf perl png pppd python qt3 qt4 quicktime raw rdesktop readline reflection rss ruby samba sdl session shorten soap sockets speex spell spl sqlite sqlite3 sse sse2 ssl subversion svg syslog tcl tcpd theora threads tiff tk truetype unicode videos vorbis wavpack wmf x264 xml xmlrpc xorg xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci 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 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 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" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="fbdev glint i810 mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
I came across this today on the AMD64 minimal install CD (2008.0). I entered the word debug after the vga=791 line on the Gentoo grub entry when booting from the CD and it booted up as normal. Upon chrooting and trying to emerge the package which failed earlier (gentoo-sources) it worked fine this time around. I can confirm I have a nvidia card built into the motherboard. Odd behaviour!
Same with me, if I "emerge --update package" the failed ebuild manually after the error occurs, it works fine. When I then do another "emerge -e world", the error pops up again (after maybe 30 minutes of compiling) in the very same packages. Tried the ~amd64 portage to no avail. The specific error I'm seeing in the console is /usr/lib64/portage/bin/ebuild.sh line 1496 - /bin/touch - Argument list too long I tried dumping the environment like Christian Schmidt did, but since I do an "emerge -e world", the changes will be overwritten right when the emerge begins. If I try to add the lines later on, Python gets confused with the file offset and dies.
Got a workaround: Edit /usr/src/linux/include/linux/limits.h Replace #define ARG_MAX 131072 /* # bytes of args + environ for exec() */ with #define ARG_MAX 1048576 Recompile your kernel, update the kernel image on your boot partition. Truely an ugly and ignorant hack ;-). Christian Schmidt mentioned a 600 kb size increase in the environment, so doing the simple math, 1mb > (131072b + 600kb), the new kernel will happily cope with all the garbage and let me recompile my system. Still hoping for a real solution!
Sorry that workaround didn't... work around the problem after all. Still getting the errors. I can see the $vga variable in eg. /var/tmp/binpkgs/app-text/ghostscript-gpl-8.62/temp/environment but not from typing 'set' or 'env' in my bash. I'm not too experienced here, anyone got an idea how to track down the source of these strings? Or was the $vga variable only set when I booted from the Gentoo 2008.0 install DVD and emerge somehow saves the original environment a package was built under? That would mean a) it should not happen again once I get rid of that string from the saved environments (HOW?) and b) the Gentoo 2008.0 install DVD could somehow cope with this long string -- it got my packages compiled, after all. For me this bug is a blocker since I can't recompile or update any package on my system anymore.
look at /var/db/pkg/package name/environment.bz2 may be you have to edit this file to remove the vga var p.s. keep a copy of the original just in case
I would try that, but this error occurred in hundreds of packages. In the meantime, my careless fixing attempts ended up in disaster and I ended up deleting my whole /var/db/ directory (: - I'm reinstalling my system with "unset vga". For the actual binary data contained in the $vga variable and some more info, check this forum post by me: http://forums.gentoo.org/viewtopic-p-5159672.html#5159672
I applied Jinesh's solution in comment #53 during a fresh install from a 2008.0 minimal CD yesterday. I edited the kernel line in the boot menu by appending "debug" to the end of the line. Seemed to work, and I never saw this error during the entire installation. *shrug*
Created an attachment (id=161457) [details] emerge --verbose --info I got the same Problem with a huge vga string in the environment file, but (as of now) only for pkgconfig-0.22: > /usr/lib64/portage/bin/ebuild.sh: line 1492: /bin/touch: Argument list too long However, while my system is amd64 and was installed from the amd64 minimal disc, i use lilo as Bootloader (with the line "vga=0x31B" in lilo.conf). Therefore the Problem might not be limited to grub, or it is caused elsewhere. Appending a "debug" at the end, eliminating the "vga=0x31B" or changing it to "vga=346" did not solve the problem for me. I made an upgrade to Python 2.5 and to the 2.6.25 kernel right before i got this error, and i use a NVIDIA Card, too.
the problem is present on ATI video too. At least for my 01:05.0 VGA compatible controller: ATI Technologies Inc Unknown device 796e
Removing vga helps. Simple scripts below could help unattended user :) /tmp/1.sh: #!/bin/sh bzcat $1 | sed -e '/^declare -x vga/d' >$1.new || exit -1 bzip2 $1.new || exit -1 mv $1.new.bz2 $1 /tmp/2.sh: #!/bin/sh bzcat $1 | sed -e '/^vga/d' >$1.new || exit -1 bzip2 $1.new || exit -1 mv $1.new.bz2 $1 After that: cd /var/db/pkg find . -name environment.bz2 -exec /tmp/1.sh \{} \; find . -name environment.bz2 -exec /tmp/2.sh \{} \; Somebody could combine them into one :) It is too late for me to do so.
*** Bug 234962 has been marked as a duplicate of this bug. ***
(In reply to comment #63) Don't know if this adds any more information to help, but I'm having the same problem, installed from AMD64 Beta2 (can't remember if it was minimal or not), with an on-board ATI 780G video chipset. I use pam_mount to mount an encrypted partition on login, though it's not the home partition. I'm pretty sure I've updated grub, but I'll need to check that tomorrow. '# echo $vga' returns no data. 'emerge -e system' made no difference.
(In reply to comment #64) > (In reply to comment #63) Just for the record, upgrading to grub version 0.97-r6 followed by grub-install hasn't solved the problem. Portage versions 2.1.4.4 and 2.1.5.6 both show the error. In fact, my problem looks more like comment 25 as it appears to be something to do with $KRB5CCNAME rather than $vga, because that's the long gibberish string in the environment files. My problem looks more like bug 230738, but it is not fixed in portage 2.1.5.6 as that bug would suggest.
The issues at hand (grub not putting a terminating NUL and the amd64 2008.0 minimal using grub instead of isolinux) have been fixed. As far as I can tell, this wasn't genkernel's fault (as it appears it was busybox init exporting the kernel commandline to the env), either, so there's nothing to fix.
(In reply to comment #66) > ... so there's nothing to fix. So do I need to open a new bug then, because there is very much something broken on my system?
I think there are two manifestations of this bug. I can confirm that at least one of them is not fixed, which means this bug should be opened, however read below for more info: The first manifestation is if your current environment has an overly large $vga variable. Many commands (even outside of portage. try `find /tmp` for example) will choke on it. You can check this with echo $vga to see if that's your case. The second manifestation, and the one I ran into, is that even if the $vga is not set, it might have been set at some point in time and captured into the "environment snapshot" when installing a package. This snapshot is restored at package unmerging time and the bug crops up. (sometimes.. it depends on the site of $vga - I've seen some snapshots with a few Ks and some a bit over 700Ks) I believe the above happened to me since I installed gentoo (2008 minimal amd64) using framebuffer mode. I rebuilt my own kernel and manually configured grub for the actual installation, so packages installed after the first reboot were not affected. This command lists installed packages which have a vga captured environment variable: for f in /var/db/pkg/*/*/environment.bz2; do bzcat $f | grep -q vga=; if [ "$?" == "0" ]; then echo $f; fi; done As you can see, the output on my machine lists packages very commonly installed during the installer cd process: /var/db/pkg/app-admin/eselect-1.0.10/environment.bz2 /var/db/pkg/app-admin/eselect-ctags-1.5/environment.bz2 /var/db/pkg/app-admin/eselect-vi-1.1.5/environment.bz2 /var/db/pkg/app-admin/logrotate-3.7.2/environment.bz2 /var/db/pkg/app-admin/syslog-ng-2.0.9/environment.bz2 /var/db/pkg/app-emulation/emul-linux-x86-baselibs-20080316/environment.bz2 /var/db/pkg/app-vim/gentoo-syntax-20070506/environment.bz2 /var/db/pkg/dev-libs/eventlog-0.2.7/environment.bz2 /var/db/pkg/dev-libs/glib-2.16.3-r1/environment.bz2 /var/db/pkg/dev-util/ctags-5.7/environment.bz2 /var/db/pkg/dev-util/pkgconfig-0.23/environment.bz2 /var/db/pkg/net-mail/mailbase-1/environment.bz2 /var/db/pkg/net-misc/dhcpcd-3.2.3/environment.bz2 /var/db/pkg/sys-apps/slocate-3.1-r1/environment.bz2 /var/db/pkg/sys-boot/grub-0.97-r6/environment.bz2 /var/db/pkg/sys-fs/reiserfsprogs-3.6.19-r2/environment.bz2 /var/db/pkg/sys-kernel/gentoo-sources-2.6.25-r7/environment.bz2 /var/db/pkg/sys-process/cronbase-0.3.2-r1/environment.bz2 /var/db/pkg/sys-process/vixie-cron-4.1-r10/environment.bz2 The fix is fairly easy. I simply use `vi` to edit all those files (it can natively handle bz2 files) and delete all the "vga=" and "declare -x vga=" lines. As mentioned above, new packages installed after the reboot don't suffer from this problem. I'm not too familiar with the internals of portage, but perhaps the next update should filter out this variable when restoring the snapshott-ed environment ? It might help people avoid this problem instead of having to manually fix their snapshots as described above.
(In reply to comment #68) For me it's definitely nothing to do with the $vga variable. The symptoms are the same, but running your script gives no output. It is however something to do with the $KRB5CCNAME variable which is very, very long in all the affected packages. I'm really frustrated having had my bug moved into this RESOLVED, FIXED one, when it's neither resolved nor fixed. Does anyone know what sets the KRB5CCNAME variable? I suppose it's something to do with kerberos, and have thought about putting USE="-kerberos" in /etc/make.conf, but I'm frightened of screwing something else up, as this is my office's main server.
Agreed. Sometimes I've got the impression Gentoo's quality is not exactly on the rise. That this bug even made it beyond the first release candidate is surprising. That there's no fix provided is disconcerting. And now it's even marked as resolved. -- FYI to the other people plagued with this: The bug affects the last environment variable passed to the kernel. During my search for help, both 'VGA' and 'KRB5CCNAME' were the candidates that seemed to pop up most often. As you have noticed, this bug is not resolved at all. Even if the install DVD had been fixed in the meantime, all the users out there with the garbage environment variable in their system are still prevented from updating. A small automated script which corrects the contents of the various environment.bz2s in /var/db (for example by capping all environment variables in there to 64k characters) would solve all these users issues. But, as it stands now, the only solution is to either write this script yourself or to reinstall from scratch, running "unset VGA" or "unset KRB5CCNAME" directly after booting from the install DVD.
For people still being hit by this bug after upgrading grub, have you tried just removing the environment.bz2 and re-emerging the effected packages?
Created an attachment (id=164284) [details] filter \1 (start of heading) characters for portage-2.1.4.4 Use this patch if you have portage-2.1.4.4. If this patch is saved as /tmp/soh_2.1.4.4.patch then it can be applied as follows: patch /usr/lib/portage/bin/filter-bash-environment.py /tmp/soh_2.1.4.4.patch
Created an attachment (id=164288) [details] filter \1 (start of heading) characters for portage-2.2_rc8 If this patch is saved as /tmp/soh_2.2_rc8.patch then it can be applied as follows: patch /usr/lib/portage/bin/filter-bash-environment.py /tmp/soh_2.2_rc8.patch
(In reply to comment #71) That stopped being funny a *long* time ago. Having to continually delete environment files and re-emerge is very annoying, especially if it's a bigish package like php for example. (In reply to comment #72) What does your script do Zac?
(In reply to comment #74) > What does your script do Zac? It's a patch which causes portage's environment filter to exclude \1 characters which trigger the problem. Here's the comment from the patch that applies to portage-2.2_rc8 which is in svn and is also attached to this bug: + # Filter out any instances of the \1 character from variable values + # since this character multiplies each time that the environment + # is saved (strange bash behavior). This can eventually result in + # mysterious 'Argument list too long' errors from programs that have + # huge strings of \1 characters in their environment. See bug #222091.
*** Bug 236641 has been marked as a duplicate of this bug. ***
(In reply to comment #75) Great, that's sorted it. Thank you Zac :-)
*** Bug 236743 has been marked as a duplicate of this bug. ***
