Building Debian style package fails on 2.0 branch and 1.4.0 tag #17
Comments
#!/usr/bin/make -f
%:
dh $@ --with python2
override_dh_auto_build override_dh_auto_install:
@Change |
ghost
assigned 
|
Can you please try without using setup.py? We've only tested that install method with the RPM packaging, but the Debian packaging predates it and should not require it. Ubuntu is also still on the 1.3.x branch as well (with a few patches backported), and it works just fine on Azure. We're working to have a 2.0.x agent packaged in Ubuntu sometime in the near future, although I do not have a timeframe for that. If there are any packaging changes required for 2.0.x we will be sure to get those patches pushed upstream here for Debian as well. In the meantime, if you want to test out the newest agent you can also install the agent "manually" via "waagent -install". See the readme for more details. It's not ideal, but for testing it should work. We have Debian 7.x running in our test automation, and we use this install method to "slipstream" in the latest agent before deploying on Azure. Thanks, |
|
As I am very unfamiliar with Debian style packaging, how does one remove the setup.py process in the debian/ directory for packaging purposes? |
|
setup.py is not being called by anything in the debian/ directory but by dpkg-buildpackage. You can probably just remove setup.py (or rename it) or add the parameters simpl1g was suggesting. @simpl1g, I'm not sure why a 1.4.0 or 2.0.1 package would fail to provision. Can you try to mount the VHD of the failed VM (you can actually do this from another working VM in Azure) and try to grab the logs in /var/log? I'd love to take a look and see what's wrong there. |
|
@szarkos This is what i have in waagent.log. Look like i have 2 agents running? |
|
Yes, it looks like it's running twice for some reason. Can you check your init scripts and see if it's listed twice somehow? Coincidentally, I see there is a new pull request that's supposed to fix up the package building for Debian: #19 Any chance you could pull that branch and see if it works? Steve |
|
I tried to run this update in ubuntu Looks like it was able to provision. waagent is running, but service not
What is the difference between walinuxagent and waagent, in standard azure ubuntu image they are both running |
|
You need to remove the walinuxagent package before installing a new agent manually or via a package. You may also want to disable the cloud-init service unless you are installing via Canonical's official package. When we install the agent manually, the service is called "waagent," but when installed via Ubuntu's packaging the service is walinuxagent. This was done on purpose so that the agent can determine if it was packaged or installed manually. Having both running may work usually (although you'll see all that ugliness in the logs), but it's not guaranteed to provisioning properly all the time. Another consideration is that Azure's Ubuntu cloud images for 12.04, 13.04 and 13.10 (but not 12.10) all have cloud-init enabled by default and use it to do much of the provisioning work. They also carry some patches upstream for compatibility with cloud-init: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/walinuxagent/saucy/view/head:/debian/patches/config_for_cloud-init.patch So, on Ubuntu, if installing manually via "waagent -install" or via your own 1.4 package you will likely want to also disable the cloud-init service. We test this scenario all the time and it works fine. However, if you want to use cloud-init you'll have to sync with Canonical's packaging upstream patches, which may be a bit of work. When we get the 2.0 version packaged for Ubuntu it should be a lot easier for them to upstream those patches for cloud-init as well. Thanks, |
|
I'm installing it on self-made image of ubuntu 12.04, so there is no walinuxagent installed before. |
|
@simpl1g ubuntu is using upstart, so you better not add the systemV init as well. For backward compatibility upstart also starts systemV init files if available so this would start the waagent twice. use the upstart file is installed from source @szarkos it looks like GetFirstActiveNetworkInterfaceNonLoopback returns 0.0.0.0 in GetIpv4Address for a not existing interface (i.e interfaces not yet known to the kernel) instead of a None which would make the agent wait. is that possible ? |
|
Now I have the following log. Despite the errors in log everything seems to be working. As I noticed, it's better to set |
|
That is good news. Regarding modifying the ClientAliveInterval, the Ubuntu community pushed back on the agent editing the sshd_config file because it is owned by another package, which is not allowed by some Debian packaging guidelines: https://bugs.launchpad.net/ubuntu/+source/walinuxagent/+bug/1188610 @g-k-r, I will have someone take a look at the GetFirstActiveNetworkInterfaceNonLoopback issue. Thanks, |
|
@simpl1g looks good, but which ssh-server are you using ? |
|
@g-k-r, I don't know what to answer :) Just standart |
|
ubuntu has 3 different possible ssh server the default is openssh-server |
|
the answer is in previous post:) |
|
:-) interesting. so it seems that the sshd is not yet running when the waagent is, and grep results in '1', which may also be the reason that the host key is not yet generated. try to depend the upstart job on sshd (if possible) |
|
@g-k-r Depending upstart on sshd job didn't give results This error occurs only if provisioning image with password, without ssh key This error does not appears after manual copying of waagent script and running And the final point, ssh connection freezes with package installation, I can't do anything with terminal for 5-10 minutes, even to disconnect, with manual installation - no problems, can it be connected with ClientAliveInterval? |
|
@g-k-r, @szarkos, this is what I have to do to generate fully working package for ubuntu, without any errors |
|
ok so you disable the upstart job, but why do you also disable setup.py during package generation? the /etc/init.d/waagent file is not packaged ! |
|
still opened? FYI. I'll upload waagent 2.0.8 to debian unstable, this issue is dealt with specifying override_dh_auto_install in debian/rules to specify --init-system option. |
|
Hi Hideki, Thanks for this, can you point me to the 2.0.8 package in Debian? Also, would it be possible to submit a pull request for these package changes so we can better support Debian? Thanks! |
|
On Wed, 29 Oct 2014 13:00:07 -0700
Well, it's my local disk yet ;)
Okay. |
|
now put debian package to debian experimental repository |
|
The Ubuntu package currently pulls in cloud-init, but to be clear we don't necessarily need cloud-init for the agent to work well with Debian. Cloud-init is nice to have, but I'm not sure if it should be a blocker to keep the latest agent out of the unstable branch. But if we want cloud-init, what more changes are needed? If you like feel free to email me at stephen.zarkos at microsoft.com and we can discuss in more detail. Thanks! |
Distribution is Ubuntu 12.04 and full output of the build failure is pasted below:
Funny thing is when I checkout the 1.3.x tag, the agent seems to build fine with dpkg-buildpackage and/or pbulider as described in the README file.
The text was updated successfully, but these errors were encountered: