ERROR with invocation of apt-get update

Fortier,Vincent [Montreal] Vincent.Fortier1 at EC.GC.CA
Thu Sep 4 15:20:37 CEST 2008


Hi all,

Using SVN snapshot of September 2nd I get an error where, after the disk
partitionning it hangs on the "apt-get update" call:
root      3206     1  0 12:01 tty1     00:00:00 init boot
root      3207  3206  0 12:01 tty1     00:00:00  \_ /bin/bash
/etc/init.d/rcS
root      3724  3207  0 12:02 tty1     00:00:00      \_ cat /proc/kmsg
root      4290  3207  0 12:02 tty1     00:00:00      \_ /bin/bash
/etc/init.d/rcS
root      4527  4290  0 12:02 tty1     00:00:00      |   \_ /bin/bash
/usr/lib/fai/updatebase
root      4561  4527  0 12:02 tty1     00:00:00      |       \_ apt-get
-y -o Dpkg::Options::="--force-confdef" -o
Dpkg::Options::="--force-confold" update
root      4563  4561  0 12:02 tty1     00:00:00      |           \_
/usr/lib/apt/methods/http
root      4564  4561  0 12:02 tty1     00:00:00      |           \_
/usr/lib/apt/methods/http
root      4566  4561  0 12:02 tty1     00:00:00      |           \_
/usr/lib/apt/methods/gzip
root      4569  4561  0 12:02 tty1     00:00:00      |           \_
/usr/lib/apt/methods/gpgv
root      4291  3207  0 12:02 tty1     00:00:00      \_ tee -a
/tmp/fai/fai.log

Updating base
Get:1 http://etch.apt.wul.qc.ec.gc.ca etch Release.gpg [386B]
Ign http://sarge.apt.wul.qc.ec.gc.ca flash/all/i386/ Release.gpg
Get:2 http://sarge.apt.wul.qc.ec.gc.ca flash/all/i386/ Release [95B]
Get:3 http://sarge.apt.wul.qc.ec.gc.ca flash/all/i386/ Packages [901B]
Get:4 http://etch.apt.wul.qc.ec.gc.ca etch/updates Release.gpg [189B]
Get:5 http://etch.apt.wul.qc.ec.gc.ca etch-backports Release.gpg [189B]
Ign http://etch.apt.wul.qc.ec.gc.ca envcan-ifw-testing/etch/all/
Release.gpg
Ign http://etch.apt.wul.qc.ec.gc.ca envcan-ifw-testing/src/ Release.gpg
Ign http://etch.apt.wul.qc.ec.gc.ca envcan-qc/etch/all/ Release.gpg
Ign http://etch.apt.wul.qc.ec.gc.ca envcan-qc/etch/amd64/ Release.gpg
Ign http://etch.apt.wul.qc.ec.gc.ca envcan-qc/src/ Release.gpg
Ign http://etch.apt.wul.qc.ec.gc.ca envcan-qc-ati/etch/amd64/
Release.gpg
Get:6 http://etch.apt.wul.qc.ec.gc.ca etch Release [58.2kB]
Get:7 http://etch.apt.wul.qc.ec.gc.ca etch/updates Release [37.6kB]
Get:8 http://etch.apt.wul.qc.ec.gc.ca etch-backports Release [43.7kB]
Ign http://etch.apt.wul.qc.ec.gc.ca envcan-ifw-testing/etch/all/ Release
Ign http://etch.apt.wul.qc.ec.gc.ca envcan-ifw-testing/src/ Release
Ign http://etch.apt.wul.qc.ec.gc.ca envcan-qc/etch/all/ Release
Ign http://etch.apt.wul.qc.ec.gc.ca envcan-qc/etch/amd64/ Release
Ign http://etch.apt.wul.qc.ec.gc.ca envcan-qc/src/ Release
Ign http://etch.apt.wul.qc.ec.gc.ca envcan-qc-ati/etch/amd64/ Release
Get:9 http://etch.apt.wul.qc.ec.gc.ca envcan-ifw-testing/etch/all/
Packages [1385B]
Get:10 http://etch.apt.wul.qc.ec.gc.ca envcan-ifw-testing/src/ Sources
[3339B]
Get:11 http://etch.apt.wul.qc.ec.gc.ca envcan-qc/etch/all/ Packages
[2952B]
Get:12 http://etch.apt.wul.qc.ec.gc.ca envcan-qc/etch/amd64/ Packages
[20B]
Get:13 http://etch.apt.wul.qc.ec.gc.ca envcan-qc/src/ Sources [2373B]
Get:14 http://etch.apt.wul.qc.ec.gc.ca envcan-qc-ati/etch/amd64/
Packages [20B]
Get:15 http://etch.apt.wul.qc.ec.gc.ca etch/main Packages [5534kB]
Get:16 http://etch.apt.wul.qc.ec.gc.ca etch/main Packages [5534kB]
Get:17 http://etch.apt.wul.qc.ec.gc.ca etch/contrib Packages [60.1kB]
Get:18 http://etch.apt.wul.qc.ec.gc.ca etch/non-free Packages [76.7kB]
Get:19 http://etch.apt.wul.qc.ec.gc.ca etch/updates/main Packages
[351kB]
Get:20 http://etch.apt.wul.qc.ec.gc.ca etch-backports/main Packages
[450kB]
Get:21 http://etch.apt.wul.qc.ec.gc.ca etch-backports/contrib Packages
[3408B]
Get:22 http://etch.apt.wul.qc.ec.gc.ca etch-backports/non-free Packages
[5588B]

... _hung_here_ ...

It does that very very often but not always...  

So I dived into the problem and found out that, when FAI install apt on
the /target it copies all the files recursivelly from /etc/apt/* from
the nfsroot to the target drive which is exactly the intended
behaviour... With one exception... Somehow somewhere it also created a
one-liner sources.list file with the content of what I presume being the
content of FAI_DEBOOTSTRAP variable from the make-fai-nfsroot.conf.  I
think this file gets created when there is no default sources.list file
in the nfsroot or something similar (I'm using sources.list.d/*.list
files) .... What happends is that this one liner apt depot is a
duplication of one of my configuration located under the
sources.list.d/*.list files so APT hang due to a duplicate channel.  It
actually hang often but not always...

To confirm this I've created a small patch to the
usr/lib/fai/subroutines-linux:

--- subroutines-linux   2008-09-04 08:31:52.000000000 -0400
+++ subroutines-linux.NEW       2008-09-04 08:31:25.000000000 -0400
@@ -236,6 +236,10 @@ EOF
     # during normal installation, we need sources.list from /etc/apt
     [ $do_init_tasks -eq 1 ] && FAI_ETC_DIR=/etc
     [ -d $FAI_ETC_DIR/apt ] && cp -r $FAI_ETC_DIR/apt/*
$FAI_ROOT/etc/apt/
+    # If there are sources.list.d/*.list files then remove the
+    # fai-created default sources.list in order to avoid conflicts
+    [ "`ls -1 $FAI_ROOT/etc/apt/sources.list.d/*.list 2>/dev/null`" ] \
+         && rm -f $FAI_ROOT/etc/apt/sources.list
 }
 # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 task_updatebase() {


This seems to solve the problem.... Although the original problem in my
opinion is that it should create that sources.list file not only when it
does not exist but also conditionnally with: does any *.list file exists
in the sources.list.d/ directory?  Although I have'nt found where it
does that just yet.

Anyhow, this patch completelly solves my problem for now.. I'm now
wondering if this fix could be included in the next release (or the
other approach of not creating the sources.list file conditionnally to
the existence of sources.list.d/*.list files).

Thnx!

- vin




More information about the linux-fai mailing list