Bug #10977
closed
Discovery image runtime extensions fail to download (intermittently)
Added by Simon Wydooghe over 9 years ago.
Updated over 9 years ago.
Description
The downloading of the runtime extensions zip file seems to work only one in three times (approximately).
It seems like this is due to the TFTP server variable being empty for some reason, this is the systemd service log:
Jul 02 07:53:11 fdi systemd1: Starting Download zip extensions to this image...
Jul 02 07:53:12 fdi discovery-setup592: Extension at: tftp:///boot/fdi-image/runtime_extensions.zip
Jul 02 07:53:12 fdi discovery-setup592: TFTP error downloading boot/fdi-image/runtime_extensions.zip: (to)
Jul 02 07:53:12 fdi systemd1: Started Download zip extensions to this image.
The path is correct, as set by the boot parameter. The server seems to be empty however. The behaviour is the same whether I use the fdi.zipserver boot parameter or not.
I use the runtime extensions to lookup a custom fact which is then used for the autoprovision hostname template. So unfortunately, this is preventing the autoprovisioning a lot of the times.
How can I help to provide more detailed info?
It looks like the ZIP_SERVER variable gets setup though, this is the printenv output when connected via SSH to the discovered host:
[root@fdi ~]# printenv
FACTERLIB=/usr/share/fdi/facts:/opt/extension/facts
XDG_SESSION_ID=1
HOSTNAME=fdi
TERM=rxvt-unicode-256color
SHELL=/bin/bash
HISTSIZE=1000
SSH_CLIENT=10.30.6.165 36217 22
SSH_TTY=/dev/pts/0
USER=root
LD_LIBRARY_PATH=/opt/extension/lib
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36:
MAIL=/var/spool/mail/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/opt/extension/bin:/root/bin
PWD=/root
LANG=en_US.UTF-8
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
LOGNAME=root
SSH_CONNECTION=10.30.6.165 36217 10.30.6.127 22
ZIP_SERVER=10.30.6.134
XDG_RUNTIME_DIR=/run/user/0
RUBYLIB=/opt/extension/lib/ruby
_=/usr/bin/printenv
And /etc/default/discovery-zip-server contains the following:
ZIP_SERVER=10.30.6.134
- Status changed from New to Duplicate
- Has duplicate Feature #10831: Introduce fdi.zipserver kernel command line option added
That does seem to work consistently now as far as I can tell. Strange, I had tried that already with the latest image but was getting the same erratic behaviour. Maybe I made a mistake somewhere. Good to know this workaround does the trick for now, thank you for your help. Let me know if you need a volunteer to test a new image.
Also available in: Atom
PDF
Updated by 
Updated by