Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

==> default: /tmp/vagrant-shell: line 138: /etc/postfix/main.cf: No such file or directory #628

Closed
hubdotcom opened this issue Apr 24, 2015 · 11 comments · Fixed by #1116
Closed

==> default: /tmp/vagrant-shell: line 138: /etc/postfix/main.cf: No such file or directory #628

hubdotcom opened this issue Apr 24, 2015 · 11 comments · Fixed by #1116
Labels
type:bug
Milestone
2.0.0

Comments

@hubdotcom
Copy link
Contributor

https://github.com/Varying-Vagrant-Vagrants/VVV/blob/master/provision/provision.sh#L138
@afilp
Copy link

afilp commented May 15, 2015

It also hits error for me (Win 8 host).

@chetanchauhan
Copy link

@hubdotcom @af7 Does software gets installed automatically in the virtual machine for you while doing provisioning? I am also getting this error and for me software aren't getting installed.

@jeremyfelt
Copy link
Member

Are there other errors during provisioning? I've provisioned from scratch a few times recently and haven't had any trouble, though it's possible that this error displays.

Can you paste the entire provisioning log into a gist or pastebin? It may be helpful to see all of those details.

@chetanchauhan
Copy link

Can you tell me how to copy the provisioning log from git bash?

@jeremyfelt
Copy link
Member

Depending on the terminal in use, you may be able to configure how many lines of scrollback are available. In OSX or Linux, you can pipe the results like vagrant provision > results.txt to capture a text file. You may be able to do the same thing here.

Have you tried starting over with vagrant destroy, then vagrant up? There shouldn't be any different behavior inside the VM itself once provisioning starts between Linux, OSX, and Windows.

@chetanchauhan
Copy link

I have already tried vagrant destroy then vagrant up, even reinstalled virtualbox and vagrant, but no success so far.

@jeremyfelt: Here is the log of doing vagrant up on fresh vvv installation https://gist.github.com/chetanchauhan/9a4aeb2b4653710aa8ee

@jeremyfelt
Copy link
Member

Ahh, it looks like this may be key:

==> default: Failed to fetch http://nginx.org/packages/mainline/ubuntu/pool/nginx/n/nginx/nginx_1.9.1-1~trusty_amd64.deb  Hash Sum mismatch
==> default: E
==> default: : 
==> default: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

I'm going to try a fresh vagrant up on my end. The switch to nginx 1.9.1 for the mainline branch is recent.

@jeremyfelt
Copy link
Member

Ok, everything worked fine during a fresh vagrant up just now. I'm wondering if this thread could shed some light on the issue - http://askubuntu.com/questions/41605/trouble-downloading-packages-list-due-to-a-hash-sum-mismatch-error

Are you behind a proxy at all?

Note - this is unrelated to the error in the original title of this issue. I do get that, but it's more of an informational error—though we should find a way to fix it.

@chetanchauhan
Copy link

Ahh, it looks like this may be key:

==> default: Failed to fetch http://nginx.org/packages/mainline/ubuntu/pool/nginx/n/nginx/nginx_1.9.1-1~trusty_amd64.deb Hash Sum mismatch
==> default: E
==> default: :
==> default: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
I'm going to try a fresh vagrant up on my end. The switch to nginx 1.9.1 for the mainline branch is recent.

Yes this indeed is the key. After I removed the nginx mainline signing key and custom sources added by vvv from the vm and installed the stable nginx(1.4.6) manually, it seems to be working. But, I am still unsure that everything is as stable as before.

Ok, everything worked fine during a fresh vagrant up just now. I'm wondering if this thread could shed some light on the issue - http://askubuntu.com/questions/41605/trouble-downloading-packages-list-due-to-a-hash-sum-mismatch-error

Are you behind a proxy at all?

Note - this is unrelated to the error in the original title of this issue. I do get that, but it's more of an informational error—though we should find a way to fix it.

No, I am not behind a proxy.

@jeremyfelt
Copy link
Member

I'm still seeing this postfix error during provisioning. Just updating with a note that this line may be it - https://github.com/Varying-Vagrant-Vagrants/VVV/blob/master/provision/provision.sh#L195-L196

@jeremyfelt jeremyfelt mentioned this issue Aug 16, 2016
Closed
jeremyfelt added a commit that referenced this issue Mar 4, 2017
@jeremyfelt
Remove attempt to enforce ipv4 in postfix
a41ac4b 
In #420, we added a line to provisioning that attempts to set
"ipv4" as the only allowed protocol for postfix due to issues in
how network connections managed the ipv6 connection.

Because the config file does not yet exist during initial
provisioning, that caused an error message saying as much. See #628.

It turns out that this line hasn't been doing anything. :)

I first went down the path of using `debconf-set-selections` to
set the protocol value. This works, but then disables ipv6 entirely
as a valid protocol. Since we haven't heard of any other issues
besides the original in #420, I think it's safe to not make any
change here and then watch for any problems.

I have a feeling that postfix has gotten better about this. In the
documentation for the `inet_protocols` config, it's mentioned that
"versions before 2.8 attempt to connect via IPv6 before attempting
to use IPv4."

http://www.postfix.org/postconf.5.html#inet_protocols

Now that we're past 2.8, it's entirely possible that the protocol
detection has gotten better. If we do run into an issue, there is
a newer `smtp_address_preference` config that allows us to specify
which protocol should be attempted first.

http://www.postfix.org/postconf.5.html#smtp_address_preference

In that case, we may need to create our own custom config file as
it's not entirely obvious that `debconf-set-selections` will work
for this value.

See #420.
Fixes #628.
@jeremyfelt jeremyfelt added this to the 2.0.0 milestone Mar 4, 2017
@jeremyfelt jeremyfelt mentioned this issue Mar 4, 2017
Merged
tomjn pushed a commit to tomjn/varying-vagrant-vagrants that referenced this issue Mar 7, 2017
@jeremyfelt @tomjn
Remove attempt to enforce ipv4 in postfix
b7c234e 
In Varying-Vagrant-Vagrants#420, we added a line to provisioning that attempts to set
"ipv4" as the only allowed protocol for postfix due to issues in
how network connections managed the ipv6 connection.

Because the config file does not yet exist during initial
provisioning, that caused an error message saying as much. See Varying-Vagrant-Vagrants#628.

It turns out that this line hasn't been doing anything. :)

I first went down the path of using `debconf-set-selections` to
set the protocol value. This works, but then disables ipv6 entirely
as a valid protocol. Since we haven't heard of any other issues
besides the original in Varying-Vagrant-Vagrants#420, I think it's safe to not make any
change here and then watch for any problems.

I have a feeling that postfix has gotten better about this. In the
documentation for the `inet_protocols` config, it's mentioned that
"versions before 2.8 attempt to connect via IPv6 before attempting
to use IPv4."

http://www.postfix.org/postconf.5.html#inet_protocols

Now that we're past 2.8, it's entirely possible that the protocol
detection has gotten better. If we do run into an issue, there is
a newer `smtp_address_preference` config that allows us to specify
which protocol should be attempted first.

http://www.postfix.org/postconf.5.html#smtp_address_preference

In that case, we may need to create our own custom config file as
it's not entirely obvious that `debconf-set-selections` will work
for this value.

See Varying-Vagrant-Vagrants#420.
Fixes Varying-Vagrant-Vagrants#628.
@lock
Copy link

lock bot commented Feb 22, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Feb 22, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
type:bug
Projects
None yet
Milestone
2.0.0
Development

Successfully merging a pull request may close this issue.

Remove attempt to enforce ipv4 in postfix Varying-Vagrant-Vagrants/VVV
4 participants
@jeremyfelt @chetanchauhan @hubdotcom @afilp