An apt-get problem today

[Derek Broughton]

Luca wrote:

> On Sat, Nov 15, 2008 at 4:36 PM, Derek Broughton <news at pointerstop.ca>
> wrote:
>> Luca wrote:
>> Try:
>> LANG="C" sudo apt-get -f install
> 
> Funny (and useful) the LANG='C' options! Owhever I already tried the
> -f option...

Basically, you can set _any_ environment variable(s) on the same command line as the command you're executing to override that value for the particular command only.

> Thats my new output now!
> 
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following packages were automatically installed and are no longer
> required:
>   linux-headers-2.6.24-19-generic linux-headers-2.6.24-19
>   libneon27-gnutls
> Use 'apt-get autoremove' to remove them.
> 0 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
> 1 not fully installed or removed.
> After this operation, 0B of additional disk space will be used.
> Setting up base-files (4.0.1ubuntu5.8.04.3) ...
> xargs: xargs.c:443: main: Assertion `bc_ctl.arg_max <= (131072-2048)'
> failed. Aborted
> dpkg: error processing base-files (--configure):
>  subprocess post-installation script returned error exit status 134
> Errors were encountered while processing:
>  base-files
> E: Sub-process /usr/bin/dpkg returned an error code (1)

Darn.  That's what I _thought_ it said :-(

It _looks_ to me as if what's happening is that "base-files" postinst 
script (/var/lib/dpkg/info/base-files.postinst) is passing t0o many 
arguments to xargs (xargs is most commonly used ime to execute a 
particular program/script on the results of a "find" command - so it's 
getting two many filenames).

At a very rough guess, it might even be saying that it's passing 131072 
filenames when it can only handle 2048.  One could probably find a way to 
increase that value, but sooner or later it would break anyway.

You could try to fix the postinst script.  Better still, fix and send a 
patch to the developers!  But I suspect you might be better off fixing 
your filesystem.

$ grep -C 3 xargs `locate base-files | grep postinst`
...
# Ubiquity 1.7.5 thru 1.10.9 failed to restore the group id of
--
        /var/lib/defoma                         "

  find -L $NINER_NINER_PATHS -gid 999 -print0 |
        xargs -0rt chgrp -h 0 || true
  find $NINER_NINER_SYMLINKS -gid 999 -print0 |
        xargs -0rt chgrp -h 0 || true
  find /media -maxdepth 1 -name "cdrom[0-9]*" -gid 999 -print0 |
        xargs -0rt chgrp -h 0 || true
fi

I skipped the first "find" because I can't imagine /boot has enough files 
for this to be a problem, but I'd try to figure out what these find 
commands are looking for (and eject any CD first) and see if you can find 
anything that actually has group id 999 (no idea why it would).  If 
nothing does, just remove those lines from the postinst and run "dkpg --
configure -a".

I think though that you _will_ find there are files with gid=999, and a 
lot of them too.  So you can run "chgrp -h 0" on them yourself (that 
says "change the group to root, without dereferencing symlinks").
-- 
derek