Dear list,
I'm trying to deploy EL 7 in an test environment. The templates are almost
vanilla. When the installation ends the machine is rebooting and gets into
installation mode via pxe again. When i change the boot order the system is
booting up and i can see that the installation was finished successfully.
For debugging reasons i added a echo command right before "exit 0" of the
template but unfortuanlly it didn't appear in the log file. My question -
what is the procedure to debug such problems?
Cheers,
Vadim
finish.txt (1.44 KB)
provision.txt (2.88 KB)
PXELinux.txt (453 Bytes)
anaconda-ks.cfg (3.65 KB)
install.post.log (8.11 KB)
>
> Dear list,
>
> I'm trying to deploy EL 7 in an test environment. The templates are
> almost vanilla. When the installation ends the machine is rebooting and
> gets into installation mode via pxe again. When i change the boot order
> the system is booting up and i can see that the installation was
> finished successfully. For debugging reasons i added a echo command
> right before "exit 0" of the template but unfortuanlly it didn't appear
> in the log file.
It looks like you added the echo to the finish template. This isn't
used when doing a PXE/network installation of EL7 using the default
templates, as the %post section in the provision (kickstart) does that
instead. Finish templates would only be used for EL7 image builds or
Debian/Ubuntu variants.
> My question - what is the procedure to debug such
> problems?
The install.post.log shows it reaches the "Informing Foreman that we are
built" step. This call to Foreman, if it succeeds, would reset the
PXELinux menu to boot from the local disk instead of the installer.
Check that the
/unattended/built?token=24b04fe8-a188-4e42-9665-255e8671b6c7 call is
received by Foreman in its log file (/var/log/foreman/production.log)
and that it's completing successfully. There's probably a failure
around here.
···
On 07/04/16 09:48, Vadim Bulst wrote:
–
Dominic Cleal
dominic@cleal.org
Hi Dominic,
thanks for your quick response. Yeah you seem to right. I reintiated the
deployment again and same result. When i checked the production.log i could
see the GET of the right token:
> Started GET
"/unattended/provision?token=7ab4f96b-d8be-4728-b9d4-18e4a83c0961" for
172.18.73.62 at 2016-04-07 11:17:55 +0200
But when i look in to the pxelinux.cfg dir i see the still existing
boot-conf:
[root@urzlxdeploy urzadmin]# grep -e
"/unattended/provision?token=7ab4f96b-d8be-4728-b9d4-18e4a83c096"
/var/lib/tftpboot/pxelinux.cfg/*
/var/lib/tftpboot/pxelinux.cfg/01-00-50-56-93-5b-7f: APPEND
initrd=boot/Scientific-7-x86_64-initrd.img
ks=http://urzlxdeploy.rz.uni-leipzig.de:80/unattended/provision?token=7ab4f96b-d8be-4728-b9d4-18e4a83c0961
network ks.sendmac
Thanks for your help 
Best,
Vadim
···
On Thursday, April 7, 2016 at 10:58:55 AM UTC+2, Dominic Cleal wrote:
>
> On 07/04/16 09:48, Vadim Bulst wrote:
> >
> > Dear list,
> >
> > I'm trying to deploy EL 7 in an test environment. The templates are
> > almost vanilla. When the installation ends the machine is rebooting and
> > gets into installation mode via pxe again. When i change the boot order
> > the system is booting up and i can see that the installation was
> > finished successfully. For debugging reasons i added a echo command
> > right before "exit 0" of the template but unfortuanlly it didn't appear
> > in the log file.
>
> It looks like you added the echo to the finish template. This isn't
> used when doing a PXE/network installation of EL7 using the default
> templates, as the %post section in the provision (kickstart) does that
> instead. Finish templates would only be used for EL7 image builds or
> Debian/Ubuntu variants.
>
> > My question - what is the procedure to debug such
> > problems?
>
> The install.post.log shows it reaches the "Informing Foreman that we are
> built" step. This call to Foreman, if it succeeds, would reset the
> PXELinux menu to boot from the local disk instead of the installer.
>
> Check that the
> /unattended/built?token=24b04fe8-a188-4e42-9665-255e8671b6c7 call is
> received by Foreman in its log file (/var/log/foreman/production.log)
> and that it's completing successfully. There's probably a failure
> around here.
>
> --
> Dominic Cleal
> dom...@cleal.org
>
The log entries after this header should show whether this succeeded or
not, ending in a Completed line.
···
On 07/04/16 10:56, Vadim Bulst wrote:
> thanks for your quick response. Yeah you seem to right. I reintiated the
> deployment again and same result. When i checked the production.log i
> could see the GET of the right token:
>
> > Started GET
> "/unattended/provision?token=7ab4f96b-d8be-4728-b9d4-18e4a83c0961" for
> 172.18.73.62 at 2016-04-07 11:17:55 +0200
–
Dominic Cleal
dominic@cleal.org
Sorry, I didn't send the complete entry:
2016-04-07 11:17:55 [app] [I]
> Started GET
"/unattended/provision?token=7ab4f96b-d8be-4728-b9d4-18e4a83c0961" for
172.18.73.62 at 2016-04-07 11:17:55 +0200
2016-04-07 11:17:55 [app] [I] Processing by UnattendedController#provision
as /
2016-04-07 11:17:55 [app] [I] Parameters:
{"token"=>"7ab4f96b-d8be-4728-b9d4-18e4a83c0961"}
2016-04-07 11:17:55 [app] [I] Found urzlxdeploy-client01.ad.uni-leipzig.de
2016-04-07 11:17:58 [app] [D] rendering DB template Kickstart default
Scientific Proxy - provision
2016-04-07 11:17:58 [app] [D] rendering snippet kickstart_networking_setup
2016-04-07 11:17:58 [app] [D] rendering snippet puppet.conf
2016-04-07 11:17:58 [app] [I] Rendered inline template (858.4ms)
2016-04-07 11:17:58 [app] [I] Completed 200 OK in 3186ms (Views: 836.2ms |
ActiveRecord: 35.9ms)
2016-04-07 11:26:18 [app] [I]
> Started GET "/node/urzlxdeploy-client01.ad.uni-leipzig.de?format=yml"
for 139.18.16.90 at 2016-04-07 11:26:18 +0200
2016-04-07 11:26:19 [app] [I] Processing by HostsController#externalNodes
as YML
2016-04-07 11:26:19 [app] [I] Parameters:
{"name"=>"urzlxdeploy-client01.ad.uni-leipzig.de"}
2016-04-07 11:26:19 [app] [D] Verifying request from
["urzlxdeploy.rz.uni-leipzig.de"] against ["urzlxdeploy.rz.uni-leipzig.de"]
2016-04-07 11:26:19 [app] [D] Setting current user thread-local variable to
foreman_api_admin
2016-04-07 11:26:20 [app] [I] Rendered text template (0.0ms)
2016-04-07 11:26:20 [app] [I] Completed 200 OK in 1645ms (Views: 165.9ms |
ActiveRecord: 82.8ms)
2016-04-07 11:26:22 [app] [I]
···
On Thursday, April 7, 2016 at 12:01:57 PM UTC+2, Dominic Cleal wrote:
>
> On 07/04/16 10:56, Vadim Bulst wrote:
> > thanks for your quick response. Yeah you seem to right. I reintiated the
> > deployment again and same result. When i checked the production.log i
> > could see the GET of the right token:
> >
> > > Started GET
> > "/unattended/provision?token=7ab4f96b-d8be-4728-b9d4-18e4a83c0961" for
> > 172.18.73.62 at 2016-04-07 11:17:55 +0200
>
> The log entries after this header should show whether this succeeded or
> not, ending in a Completed line.
>
> --
> Dominic Cleal
> dom...@cleal.org
>
Ah sorry, I should have noticed, that's not the "built" request.
/provision is for the initial kickstart/provisioning script.
There should be a subsequent /built request from the wget command.
You may want to remove the -q -O /dev/null options from wget at the end
of the kickstart to ensure the output and information is written to
install.post.log.
···
On 07/04/16 11:12, Vadim Bulst wrote:
> Sorry, I didn't send the complete entry:
>
> 2016-04-07 11:17:55 [app] [I]
> > Started GET
> "/unattended/provision?token=7ab4f96b-d8be-4728-b9d4-18e4a83c0961" for
> 172.18.73.62 at 2016-04-07 11:17:55 +0200
–
Dominic Cleal
dominic@cleal.org
Hi Dominic,
I guess i found the reason. There is no NAT between the networks and i have
to use a proxy - so i configured a proxy. Now wget seems to use the proxy
to connect to the foreman-proxy and the regular http-proxy is not able to
connect to the forman-proxy - see here:
Informing Foreman that we are built
–2016-04-07 07:58:35–
http://urzlxdeploy.rz.uni-leipzig.de/unattended/built?token=9c735f45-f42e-43e1-b934-580d50464c56
Resolving proxy.uni-leipzig.de (proxy.uni-leipzig.de)… 139.18.1.5
Connecting to proxy.uni-leipzig.de
(proxy.uni-leipzig.de)|139.18.1.5|:3128… connected.
Proxy request sent, awaiting response… 503 Service Unavailable
2016-04-07 07:58:35 ERROR 503: Service Unavailable.
I'll edit the options of wget again and add --no-proxy .
Thanks for your help!
Greets,
Vadim
···
On Thursday, April 7, 2016 at 12:22:45 PM UTC+2, Dominic Cleal wrote:
>
> On 07/04/16 11:12, Vadim Bulst wrote:
> > Sorry, I didn't send the complete entry:
> >
> > 2016-04-07 11:17:55 [app] [I]
> > > Started GET
> > "/unattended/provision?token=7ab4f96b-d8be-4728-b9d4-18e4a83c0961" for
> > 172.18.73.62 at 2016-04-07 11:17:55 +0200
>
> Ah sorry, I should have noticed, that's not the "built" request.
> /provision is for the initial kickstart/provisioning script.
>
> There should be a subsequent /built request from the wget command.
>
> You may want to remove the -q -O /dev/null options from wget at the end
> of the kickstart to ensure the output and information is written to
> install.post.log.
>
> --
> Dominic Cleal
> dom...@cleal.org
>
