Knoppix 7.0.2-EN DVD notes & comments

[ruymbeke]

Last week this recipe worked perfectly, but now it hangs... Is there any way to get around this ? ... For me, this is a very serious problem...

Hello Capricorny,
I don't have any problem using the script below:

#!/bin/sh
sudo apt-get update
sudo apt-get -y -d -t unstable install libc-bin libc-dev-bin libc6 libc6-dev gcc-4.6-multilib g++-4.6-multilib
sudo apt-get -y -t unstable --reinstall install libc-bin libc-dev-bin libc6 libc6-dev
sudo chroot /UNIONFS/ apt-get -y -t unstable -f install
sudo apt-get -y -t unstable --reinstall install gcc-4.6-multilib g++-4.6-multilib

After booting Knoppix 7.0.2 from the DVD and using the 64 bits kernel
I can compile and execute 64 bits libraries and applications such as Pi
cf: http://h2np.net/pi/pi_record_e.html
(after editing the start.sh script to add the "-m64" parameter on the two lines using "cc" to compile "v" and "pi")

That being said, during the install I get a very worrying error message:

apt-get -y -t unstable --reinstall install  libc-bin libc-dev-bin libc6 libc6-dev
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 4 reinstalled, 0 to remove and 1453 not upgraded.
Need to get 0 B/10.2 MB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 430147 files and directories currently installed.)
Preparing to replace libc-bin 2.13-33 (using .../libc-bin_2.13-33_i386.deb) ...
Unpacking replacement libc-bin ...
Processing triggers for man-db ...
Setting up libc-bin (2.13-33) ...
(Reading database ... 430147 files and directories currently installed.)
Preparing to replace libc6:i386 2.13-33 (using .../libc6_2.13-33_i386.deb) ...

A copy of the C library was found in an unexpected directory:
  '/UNIONFS/lib/i386-linux-gnu/libc-2.13.so'
It is not safe to upgrade the C library in this situation;
please remove that copy of the C library or get it out of
'/UNIONFS/lib/i386-linux-gnu' and try again.

dpkg: error processing /var/cache/apt/archives/libc6_2.13-33_i386.deb (--unpack):
 subprocess new pre-installation script returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/libc6_2.13-33_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

==> dpkg: error processing /var/cache/apt/archives/libc6_2.13-33_i386.deb (--unpack): <==
Is it possible that the "libc6_2.13-33_i386.deb" package be corrupted on the Debian repository ?
Even with that error, it looks like that I can still compile and execute 64 bits code...

BTW, did you try my patch yet ?
Best Regards,
Gilles

[Capricorny]

Hello Capricorny,
I don't have any problem using the script below:

#!/bin/sh
sudo apt-get update
sudo apt-get -y -d -t unstable install libc-bin libc-dev-bin libc6 libc6-dev gcc-4.6-multilib g++-4.6-multilib
sudo apt-get -y -t unstable --reinstall install libc-bin libc-dev-bin libc6 libc6-dev
sudo chroot /UNIONFS/ apt-get -y -t unstable -f install
sudo apt-get -y -t unstable --reinstall install gcc-4.6-multilib g++-4.6-multilib

After booting Knoppix 7.0.2 from the DVD and using the 64 bits kernel
I can compile and execute 64 bits libraries and applications such as Pi
cf: http://h2np.net/pi/pi_record_e.html
(after editing the start.sh script to add the "-m64" parameter on the two lines using "cc" to compile "v" and "pi")

That being said, during the install I get a very worrying error message:

apt-get -y -t unstable --reinstall install  libc-bin libc-dev-bin libc6 libc6-dev
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 4 reinstalled, 0 to remove and 1453 not upgraded.
Need to get 0 B/10.2 MB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 430147 files and directories currently installed.)
Preparing to replace libc-bin 2.13-33 (using .../libc-bin_2.13-33_i386.deb) ...
Unpacking replacement libc-bin ...
Processing triggers for man-db ...
Setting up libc-bin (2.13-33) ...
(Reading database ... 430147 files and directories currently installed.)
Preparing to replace libc6:i386 2.13-33 (using .../libc6_2.13-33_i386.deb) ...

A copy of the C library was found in an unexpected directory:
  '/UNIONFS/lib/i386-linux-gnu/libc-2.13.so'
It is not safe to upgrade the C library in this situation;
please remove that copy of the C library or get it out of
'/UNIONFS/lib/i386-linux-gnu' and try again.

dpkg: error processing /var/cache/apt/archives/libc6_2.13-33_i386.deb (--unpack):
 subprocess new pre-installation script returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/libc6_2.13-33_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

==> dpkg: error processing /var/cache/apt/archives/libc6_2.13-33_i386.deb (--unpack): <==
Is it possible that the "libc6_2.13-33_i386.deb" package be corrupted on the Debian repository ?
Even with that error, it looks like that I can still compile and execute 64 bits code...

BTW, did you try my patch yet ?
Best Regards,
Gilles

Thank you very much for your response, Gilles!

First, my current working version is remastering #4, so I havent tried out your patch. As told, I also already did this successfully, but in another "branch", which has been overwritten.

The important observation for me is that you get precisely the same error message as me, effective halting the upgrading of libc6, leaving a "broken" package from apt's point of view. And I pointed out the approximate location of the error in the preinst script -it's corrupted logic, not corrupted files. The ordinary upgrade of libc6 stable also crashes the same way.

To fix the problem, we must have access to and patch the offending downloaded .deb packages. This may be accomplished in a number of ways, right now I tend to support the more drastical ones, to be able to stop Debian apt madness on the spot when needed.

[Capricorny]

To fix the problem, we must have access to and patch the offending downloaded .deb packages. This may be accomplished in a number of ways, right now I tend to support the more drastical ones, to be able to stop Debian apt madness on the spot when needed.

Here is a general solution to the problem, found on github:gist, https://gist.github.com/1729559

It amounts to running a script on the troublesome downloaded .deb package, to remove the associated pre/postrm scripts. I think it should be fairly safe to use, and in any case far safer than the default dive-into-it Debian "method", which may leave us with a broken system even if everything is correct, because the scripts are buggy - as they very often tend to be.

The script is called stripdeb.sh, and I installed it in /usr/local/bin:

#!/bin/bash
# Usage: stripdeb.sh something.deb
# From: https://gist.github.com/1729559
# Patch /etc/apt.conf.d/70debconf: DPkg::Pre-Install-Pkgs {"xargs -rL1 bash /usr/local/bin/stripdeb.sh 2>&1 | logger -t stripdeb"}
# 20120624  tay: This patching didn't seem to work, and using on a regular basis may not be that smart either. 
# Safer to run it only on individual packages basis: 
# #> sudo stripdeb.sh /var/cache/apt/archives/libc6_2.13-33_i386.deb
# Don't use apt-get afterwards, it may notice something is changed and download the old madness again
# #> dpkg -i /var/cache/apt/archives/libc6_2.13-33_i386.deb

echo "Args: $*"
echo "Stripping $1 of pre/post maintainer scripts"
tmpdir=$(mktemp -d)

[ ! -f $1 ] && exit 1

genldconfigscript() {
  # Maybe we should just make the always run 'ldconfig'
  cat << EOF
#!/bin/sh
[ "\$1" = "configure" ] && ldconfig
[ "\$1" = "remove" ] && ldconfig
true
EOF
}

# The .deb is an 'ar' archive, grab the control files.
ar -p $1 control.tar.gz | tar -C $tmpdir -zxf -

# Kill the stupid package scripts, but log what we do.
for i in $tmpdir/{post,pre}{rm,inst} ; do
if [ -f $i ] ; then

    # Linux sucks, so we have to run ldconfig on any library changes.
    # So if the post/pre script includes ldconfig
    if grep -q ldconfig $i ; then
echo "$1: Replacing $i with a generic 'ldconfig' script"
      genldconfigscript > $i
      chmod 755 $i
    else
echo "$1: Stripping $(basename $i)"
      rm $i
    fi
fi
done

# Rebuild the control tarball
tar -C $tmpdir -zcf control.tar.gz .

# And replace the old one with the stripped one back into the .deb
ar -r $1 control.tar.gz

# Clean up
rm control.tar.gz

So, to get around the Debian package bugs, I ran the script before chvt'ing, and used dpkg instead of apt-get after init 2. The modified version of Klaus2008's recipe thus becomes:

sudo apt-get update 
sudo apt-get -d -t unstable install libc-bin libc-dev-bin libc6 libc6-dev 
sudo stripdb.sh /var/cache/apt/archives/libc6_2.13-33_i386.deb

sudo chvt 1
init 2
dpkg -i libc-bin libc-dev-bin libc6 libc6-dev 

chroot /UNIONFS/ 
apt-get -t unstable -f install 
exit 
init 5 
chvt 5

sudo apt-get -y -t unstable install gcc-4.6-multilib g++-4.6-multilib

It worked for me, and with due modifications it ought to work more generally.
We must of course be pretty sure that the scripts aren't really needed for the particular package.

[ruymbeke]

Hi Capricorny,
Thank you very much for offering a fix proposal. I tried it and I found two problems:

sudo stripdb.sh /var/cache/apt/archives/libc6_2.13-33_i386.deb

The first one is a typo in your modified Klaus2008's recipe: stripdb.sh ==> stripdeb.sh
(to match the location of the /usr/local/bin/stripdeb.sh script)

dpkg -i libc-bin libc-dev-bin libc6 libc6-dev

The second: dpkg -i complains about not finding the archive, please see the log below:

dpkg -i libc-bin libc-dev-bin libc6 libc6-dev
dpkg: error processing libc-bin (--install):
cannot access archive: No such file or directory
dpkg: error processing libc-dev-bin (--install):
cannot access archive: No such file or directory
dpkg: error processing libc6 (--install):
cannot access archive: No such file or directory
dpkg: error processing libc6-dev (--install):
cannot access archive: No such file or directory
Errors were encountered while processing:
libc-bin
libc-dev-bin
libc6
libc6-dev

Best Regards,
Gilles

[Capricorny]

Right you are, Gilles!
This reporting was very quickly done, a bit too fast.
What I actually ran was

sudo apt-get update  
sudo apt-get -d -t unstable install libc-bin libc-dev-bin libc6 libc6-dev  
sudo stripdeb.sh /var/cache/apt/archives/libc6_2.13-33_i386.deb  

sudo chvt 1 
init 2
# The other libs were correctly installed already, next line implicit - didn't run it
# sudo apt-get -y -t unstable --reinstall install libc-bin libc-dev-bin libc6-dev 

# Give dpkg exact file address
dpkg -i /var/cache/apt/archives/libc6_2.13-33_i386.deb 

chroot /UNIONFS/ 
apt-get -t unstable -f install  
exit  

init 5  
chvt 5  

sudo apt-get -y -t unstable install gcc-4.6-multilib g++-4.6-multilib

But I wasn't able to copy from the chvt 1 commands, thus only edited the line from the recipe. apt-get may possibly be used, but told not to download again? It just downloaded the unmodified .deb libc6 over the modified one for me.
The most robust thing to do might be to adjust the dpkg command.

PS: The autoformatting here REALLY SUCKS!