Vagrant: Unable to vagrant halt Debian 4 box

[MarcinOrlowski]

I am using Vagrant 2.0.0 and I am in need to box ancient and rusted Debian Etch (4.0). I boxed it for Virtualbox for now and is available here https://app.vagrantup.com/MarcinOrlowski/boxes/debian4-i386 - it looks it works (there's no working GuestAdditions but this is not a problem from my perspective). The problem however is that I am unable to shutdown the guest with regular vagrant halt:

$ vagrant halt
==> default: Attempting graceful shutdown of VM...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

shutdown -h now

Stdout from the command:


Stderr from the command:

and guest stays alive:

$ vagrant status
Current machine states:

default                   running (virtualbox)

I can vagrant ssh and shut it down with the same shutdown -h now from there w/o problems though. I looked into guest logs and found related entries in auth.log:

Mar 30 02:26:42 debian sshd[2035]: Accepted publickey for vagrant from 10.0.2.2 port 40850 ssh2
Mar 30 02:26:42 debian sshd[2037]: (pam_unix) session opened for user vagrant by (uid=0)
Mar 30 02:26:48 debian sudo:  vagrant : TTY=pts/0 ; PWD=/home/vagrant ; USER=root ; COMMAND=/sbin/shutdown -h now
Mar 30 02:26:49 debian sshd[1835]: Received signal 15; terminating.
Mar 30 02:28:24 debian sshd[1835]: Server listening on :: port 22.

setting sshd logging level to VERBOSE reveals:

Mar 30 02:48:59 debian sshd[1936]: Connection from 10.0.2.2 port 41426
Mar 30 02:49:00 debian sshd[1936]: Failed none for vagrant from 10.0.2.2 port 41426 ssh2
...
Mar 30 02:49:02 debian sshd[1938]: Closing connection to 10.0.2.2

Using log level DEBUG shows bit more.

Mar 30 02:52:03 debian sshd[2058]: debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7
Mar 30 02:52:03 debian sshd[2056]: debug1: Forked child 2058.
Mar 30 02:52:03 debian sshd[2058]: debug1: inetd sockets after dupping: 3, 3
Mar 30 02:52:03 debian sshd[2058]: Connection from 10.0.2.2 port 41460
Mar 30 02:52:03 debian sshd[2058]: debug1: Client protocol version 2.0; client software version Ruby/Net::SSH_4.1.0 x86_64-linux
Mar 30 02:52:03 debian sshd[2058]: debug1: no match: Ruby/Net::SSH_4.1.0 x86_64-linux
Mar 30 02:52:03 debian sshd[2058]: debug1: Enabling compatibility mode for protocol 2.0
Mar 30 02:52:03 debian sshd[2058]: debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-9etch3
Mar 30 02:52:03 debian sshd[2058]: debug1: PAM: initializing for "vagrant"
Mar 30 02:52:03 debian sshd[2058]: debug1: PAM: setting PAM_RHOST to "10.0.2.2"
Mar 30 02:52:03 debian sshd[2058]: debug1: PAM: setting PAM_TTY to "ssh"
Mar 30 02:52:03 debian sshd[2058]: Failed none for vagrant from 10.0.2.2 port 41460 ssh2
Mar 30 02:52:03 debian sshd[2058]: debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
Mar 30 02:52:03 debian sshd[2058]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
Mar 30 02:52:03 debian sshd[2058]: debug1: trying public key file /home/vagrant/.ssh/authorized_keys

and vagrant halt seems to stay hung on ==> default: Attempting graceful shutdown of VM... step. CTRL-C yelds ==> default: Waiting for cleanup before exiting... but it still hungs. Second CTRL-C shows ==> default: Exiting immediately, without cleanup! and it quits (but guest remains up).

Further increase of of sshd log verbosity brings no additional information.

Guest ssh -v tells OpenSSH_4.3p2 Debian-9etch3, OpenSSL 0.9.8c 05 Sep 2006

Is there anything else I could try to figure out what is the culprit? Or any workaround?

[briancain]

Hello! Thanks for opening an issue. Please provide the full debug output in a gist from the vagrant halt command. That should help us figure out what might be going wrong. Thanks!

[MarcinOrlowski]

I executed VAGRANT_LOG=debug vagrant halt and here it is: vagrant-halt-debug.log

Quick read reveals potential culprit:

DEBUG ssh: stderr: sudo: illegal option `-E'

[briancain]

@MarcinOrlowski - Ah...that seems to be coming from the default configured sudo command https://github.com/hashicorp/vagrant/blob/master/plugins/kernel_v2/config/ssh.rb#L64

You should be able to override that in your Vagrantfile with whatever Debian 4 needs:

https://www.vagrantup.com/docs/vagrantfile/ssh_settings.html

Vagrant.configure("2") do |config|
  config.ssh.sudo_command = "sudo blahblahblah"
 # other vagrant stuff here
end

If that works let me know, and I'll go ahead and close the issue. Thanks!

[MarcinOrlowski]

Adding

config.ssh.sudo_command = "sudo -H %c"

to my Vagrant file solves this problem. Thanks!

[MarcinOrlowski]

I need to reopen this issue (or maybe I shall create new one?). I am now facing another sudo related issue trying to provision this box on new machine. I got Ansible 2.5 and Vagrant 2.0.3 installed and vagrant provision ends up with this:

DEBUG subprocess: stdout: fatal: [xxxx]: FAILED! => {"changed": false, 
"module_stderr": "Shared connection to 127.0.0.1 closed.\r\n", 
"module_stdout": "sudo: illegal option `-n'\r\nusage: sudo -K | -L | -V | -h | -k | -l | -v\r\n
usage: sudo [-HPSb] [-p prompt] [-u username|#uid]\r\n          
  { -e file [...] | -i | -s | <command> }\r\n", "msg": "MODULE FAILURE", "rc": 1}

where is -n coming from if my Vagrant file contains config.ssh.sudo_command = "sudo -H %c"?

[briancain]

@MarcinOrlowski - could you provide the entire debug output in a gist? Thanks!

[MarcinOrlowski]

Attached.
vagrant-provision-debug-log.txt

[briancain]

@MarcinOrlowski from the looks of it, it seems to be a problem with the tool ansible. It failed in the "gathering facts" step, which I believe is the ansible tool step rather than something Vagrant does. I would see if there's a way to configure ansible to use a custom sudo command. But I don't believe this is a vagrant bug.

[MarcinOrlowski]

You may be right here. I will check with Ansible guys. Thanks.

[briancain]

Hey there,

I am going to close this due to lack of response. If this is still occurring, please open a new issue and follow the provided issue template that appears when you click the "New Issue" button. This will help us in getting a reproduction and fix. Thanks!

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.