I am making a new attempt with ERPNext but can’t get the ship sailing due to installation failure (ubuntu 16.04)
I find very simmilar situation as decsribed in this topic which claims to be SOLVED but apparently isn’t entirely:
I get almost the exact same error (additional 'site.yml') on various platform (ubuntu 16.04 LXD Container, 16.04 VM, centos7 container (proxmox), deb8 LXD container)
if I run the script twice in a VM (that’s seems to be the only difference then running in a container) the installation formally finishes but factually there is no running erpnext site (just a big E on the Desktop after login) it seems frappe is not really existing (even though the ~/apps/frappe folder is there).
As my goal is to run in a LXD container I haven’t digged much deeper into this VM problem)
is there any cure for this which I just haven’t found yet?
The situation in the post thread you list in this new thread was in fact resolved.
However, it was not due to anything that you might have control over. It turns out the person responsible for the install.py playbook had made some alterations that completely sent the install process off the rails.
He did eventually dig in and find the issue in his edits and fix them. However, one thing that remained after his fix was the requirement to install some extra packages before running the install.py script.
See THIS LINK for a little more details on what he recommended.
Hope this helps. If not you might try reaching out to him directly to see if he can shed any light on your new recurrence of the same error. @codingCoffee was very helpful when we worked together on resolving it the last time.
Ahh… one last thing. His work was hampered at the time by his exclusive use of the --develop switch with the install.py… It was not until he looked at it from our perspective (–production) that the errors in his edits were located. He did promise to pay closer attention to the difference for future edits. His experience in this may be helpful to your current errors.
thanks @bkm. however the topic you recommend studying’s solution practically is that the script should work now (after fixes applied to the install.py by @codingCoffee (thanks for all the work btw))
Apparently there is still something not quite right unfortunately.
would it be an idea to install with the --develop option and turn it into a production site once it’s running? Or would one just get another bunch of problems through that approach?
@vrms if your goal is to install ERPNext in an LXD container, I don’t think you’ll be able to do it as yet. The install script doesn’t support container based virtualization yet.
However, if you’re facing any issues related to installation in a hypervisor based virtualization (like VMware or VirtualBox) can you please post the tracelog? It’ll be helpful to debug the issue.
hm, then we have made a step backwards. Last time I checked it was possible without any problem to install in a linux container (LXC/LXD) just like inside a VM or baremetal server. Actually I would think that from inside a container the OS would look just alike a VM or baremetal 16.04.
This how-to worked actually when it was published.
Also there are actually people (@kirthi@fblauer) using LXC for production. I don’t know however how they have managed installation in the container.
Generally I think a Linux Container (LXC/LXD) is a way more flexible environment then a VM and much less complex then a dockerized setup. And it would be super awesome whether at any point in time there was a supported LXC template for ERPNext
Those guys who did it must’ve done the installation manually. When I said installation is not possible, I meant it’s not possible via the easy install script which we use. Manual installation is possible. The easy install script doesn’t work because we depend on systemctl in the script, and last I checked docker has issues with that. I’m not that well acquainted with LXD or LXC, and I might’ve prematurely generalized all container based virtualization, thereby coming to the conclusion about the failure of the easy install script. If you could provide some logs, maybe I could fix the issue/come to a better conclusion.
On a side note, support for LXD or LXC doesn’t seem to be a high priority task for now, so I’m not sure when the feature will be added. You are however free to contribute
systemctl exists and works in LXC/LXD containers (if the container OS like ubuntu/debian use systemd).
Does the error message strike you as being caused by failing systemctl?
Let’s talk again about that once I can make it work.
are u sure of that as in “tried’ & worked”? @fblauer how did u install ERPNext in a LXC container?
Okay in that case maybe if we prevent the playbook setting locale, I think we can get the install script to work in LXD/LXC
I haven’t tried it myself, but I’m sure others in the community have. I’m optimistic about its working because I’ve done it in a docker container without any issues, so I presume it shouldn’t be that difficult in LXC/LXD.
File “/usr/lib/python2.7/subprocess.py”, line 540, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command ‘[‘ansible-playbook’, ‘-c’, ‘local’, ‘production/install.yml’, site.yml, ‘-e’, ‘@/t
mp/extra_vars.json’, ‘–become’, ‘–become-user=frappe’]’ returned non-zero exit status 2
that’d be nothing less then phantastic! I really appreciate that. I’ll try to get a group going that may be willing to provide & maintain an LXD template. I myself don’t have too much technical understanding to take on that endeavor all by myself I’m afraid
exactly. I (among others) did it. But it is not working anymore
haha, sorry. Now I feel really stupid: Where can I find that trace log exactly? I|m inside a Virtualbox machine and can’t copy’n’paste is from the bash. I guess it may be stored somewhere, but can’t figure out the exact file/location. :~|
@wale no sorry. I can reproduce the misbehavior but thus far could not figure out how to get the entire error log of the installation procedure as requested by @codingCoffeeyet
@wale can you post the list of commands you executed and in what order.
Also please post a few lines above and below the traceback you posted. They will be required to find the origin of the issue…
So it turns out this issue was somehow linked to how mariadb was setup on the server. I eventually did the installation on a fresh instance (without mariadb pre-installed) and it worked fine