[Planetlab-devel] nodes booting

["S.Çağlar Onur"]

Hey Thieery,

On Aug 25, 2010, at 7:57 AM, Thierry Parmentelat wrote:

> hi folks
> 
> catching up after a while away, I've just noticed a strange behaviour of the nightlies
> 
> the problem happens while installing the bootstrapfs image:
> 
> ----
> 
> 23:02:28(UTC) extracting /tmp/mnt/sysimg/bootstrapfs-onelab-f8-i386.tar in /tmp/mnt/sysimg
> sysexec >>> tar -C /tmp/mnt/sysimg -xpf /tmp/mnt/sysimg/bootstrapfs-onelab-f8-i386.tar 
> 23:03:40(UTC) 23:03:40(UTC) Done
> 23:03:42(UTC) Copying resolv.conf to temp dir
> sysexec >>> cp /etc/resolv.conf /tmp/mnt/sysimg/etc/
> 23:03:42(UTC) 23:03:42(UTC) Copying boot server certificates and public key
> sysexec >>> gpg --homedir=/root --export --armor --no-default-keyring --keyring /tmp/mnt/sysimg/usr/boot/pubring.gpg >/tmp/mnt/sysimg/etc/pki/rpm-gpg/RPM-GPG-KEY-planetlab
> sysexec >>> chroot /tmp/mnt/sysimg  rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-planetlab
> 23:03:43(UTC) 
> 
> Exception while running: Running chroot /tmp/mnt/sysimg  rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-planetlab failed (rc=1)
> 23:03:43(UTC) 
> 
> ----
> 
> I can't say yet for centos5.5 nor for the 64bits, but the following fedora combinations all exhibit this behaviour
> 
> k22-f8-32
> k27-f8-32
> k27-f12-32
> 
> ----
> See e.g. this run for more details
> 
> See full build log at http://build.onelab.eu/onelab/2010.08.25--k22-f8-32/log.txt
> and tail version at http://build.onelab.eu/onelab/2010.08.25--k22-f8-32.ko
> See complete set of testlogs at http://build.onelab.eu/onelab/2010.08.25--k22-f8-32/testlogs
> 
> -------
> the funny thing is, I've investigated this on a running node, and found tmp/mnt/sysimg/etc/pki/rpm-gpg/RPM-GPG-KEY-planetlab missing
> however running the gpg export command manually correctly created the file, so I'm puzzled
> 
> Anyone has a clue about a recent change that might cause this to happen ?

I might have a clue about the source of the problem. Nearly a month ago I changed a buggy behavior of BootManager. sysexec function at source/utils.py was returning True even if the triggered command reports unsuccessful exit status. I guess that problem was living there for a long time but it just become visible with my latest changes. 

> -- thierry
> _______________________________________________
> Devel mailing list
> Devel at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel

Best regards,
--
S.Çağlar Onur <caglar at cs.princeton.edu>