How to solve `ttyname failed: Inappropriate ioctl for device` in Vagrant?












16















When using this snippet (inline shell provisioner):



config.vm.provision "shell" do |s|
s.inline = <<-SHELL
<shell code>
SHELL
end


it results in:



==> default: mesg: 
==> default: ttyname failed
==> default: :
==> default: Inappropriate ioctl for device


It looks like that other people have found this issue as well. Does anybody know how to solve it?










share|improve this question























  • I noticed that even this message was shown as an error, the script was executed successfully! A few days later I saw a possible fix and I posted an answer here. So maybe you just don't need it, but you can try it and use it if it works for you.

    – Minister
    Feb 22 '17 at 16:37













  • @Minister Thank you. It solves the issue. Could you remove the answer from SO and post it on SuperUser? Stackoverflow is about programming.

    – 030
    Feb 23 '17 at 15:55











  • I'm glad the solution also works for you! Thank you for your quick confirmation! I've just posted an answer here, but I'm not sure whether I have to remove my answer from SO or a moderator should move the question from SO here on SU? I'm OK if someone with appropriate permissions edit/delete my answer there, but it may help someone else, so I'm leaving it "as is" for now, realizing it's some kind a duplicate (as the question seems like)...

    – Minister
    Feb 23 '17 at 19:35
















16















When using this snippet (inline shell provisioner):



config.vm.provision "shell" do |s|
s.inline = <<-SHELL
<shell code>
SHELL
end


it results in:



==> default: mesg: 
==> default: ttyname failed
==> default: :
==> default: Inappropriate ioctl for device


It looks like that other people have found this issue as well. Does anybody know how to solve it?










share|improve this question























  • I noticed that even this message was shown as an error, the script was executed successfully! A few days later I saw a possible fix and I posted an answer here. So maybe you just don't need it, but you can try it and use it if it works for you.

    – Minister
    Feb 22 '17 at 16:37













  • @Minister Thank you. It solves the issue. Could you remove the answer from SO and post it on SuperUser? Stackoverflow is about programming.

    – 030
    Feb 23 '17 at 15:55











  • I'm glad the solution also works for you! Thank you for your quick confirmation! I've just posted an answer here, but I'm not sure whether I have to remove my answer from SO or a moderator should move the question from SO here on SU? I'm OK if someone with appropriate permissions edit/delete my answer there, but it may help someone else, so I'm leaving it "as is" for now, realizing it's some kind a duplicate (as the question seems like)...

    – Minister
    Feb 23 '17 at 19:35














16












16








16


4






When using this snippet (inline shell provisioner):



config.vm.provision "shell" do |s|
s.inline = <<-SHELL
<shell code>
SHELL
end


it results in:



==> default: mesg: 
==> default: ttyname failed
==> default: :
==> default: Inappropriate ioctl for device


It looks like that other people have found this issue as well. Does anybody know how to solve it?










share|improve this question














When using this snippet (inline shell provisioner):



config.vm.provision "shell" do |s|
s.inline = <<-SHELL
<shell code>
SHELL
end


it results in:



==> default: mesg: 
==> default: ttyname failed
==> default: :
==> default: Inappropriate ioctl for device


It looks like that other people have found this issue as well. Does anybody know how to solve it?







vagrant






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Dec 25 '16 at 9:43









030030

94071534




94071534













  • I noticed that even this message was shown as an error, the script was executed successfully! A few days later I saw a possible fix and I posted an answer here. So maybe you just don't need it, but you can try it and use it if it works for you.

    – Minister
    Feb 22 '17 at 16:37













  • @Minister Thank you. It solves the issue. Could you remove the answer from SO and post it on SuperUser? Stackoverflow is about programming.

    – 030
    Feb 23 '17 at 15:55











  • I'm glad the solution also works for you! Thank you for your quick confirmation! I've just posted an answer here, but I'm not sure whether I have to remove my answer from SO or a moderator should move the question from SO here on SU? I'm OK if someone with appropriate permissions edit/delete my answer there, but it may help someone else, so I'm leaving it "as is" for now, realizing it's some kind a duplicate (as the question seems like)...

    – Minister
    Feb 23 '17 at 19:35



















  • I noticed that even this message was shown as an error, the script was executed successfully! A few days later I saw a possible fix and I posted an answer here. So maybe you just don't need it, but you can try it and use it if it works for you.

    – Minister
    Feb 22 '17 at 16:37













  • @Minister Thank you. It solves the issue. Could you remove the answer from SO and post it on SuperUser? Stackoverflow is about programming.

    – 030
    Feb 23 '17 at 15:55











  • I'm glad the solution also works for you! Thank you for your quick confirmation! I've just posted an answer here, but I'm not sure whether I have to remove my answer from SO or a moderator should move the question from SO here on SU? I'm OK if someone with appropriate permissions edit/delete my answer there, but it may help someone else, so I'm leaving it "as is" for now, realizing it's some kind a duplicate (as the question seems like)...

    – Minister
    Feb 23 '17 at 19:35

















I noticed that even this message was shown as an error, the script was executed successfully! A few days later I saw a possible fix and I posted an answer here. So maybe you just don't need it, but you can try it and use it if it works for you.

– Minister
Feb 22 '17 at 16:37







I noticed that even this message was shown as an error, the script was executed successfully! A few days later I saw a possible fix and I posted an answer here. So maybe you just don't need it, but you can try it and use it if it works for you.

– Minister
Feb 22 '17 at 16:37















@Minister Thank you. It solves the issue. Could you remove the answer from SO and post it on SuperUser? Stackoverflow is about programming.

– 030
Feb 23 '17 at 15:55





@Minister Thank you. It solves the issue. Could you remove the answer from SO and post it on SuperUser? Stackoverflow is about programming.

– 030
Feb 23 '17 at 15:55













I'm glad the solution also works for you! Thank you for your quick confirmation! I've just posted an answer here, but I'm not sure whether I have to remove my answer from SO or a moderator should move the question from SO here on SU? I'm OK if someone with appropriate permissions edit/delete my answer there, but it may help someone else, so I'm leaving it "as is" for now, realizing it's some kind a duplicate (as the question seems like)...

– Minister
Feb 23 '17 at 19:35





I'm glad the solution also works for you! Thank you for your quick confirmation! I've just posted an answer here, but I'm not sure whether I have to remove my answer from SO or a moderator should move the question from SO here on SU? I'm OK if someone with appropriate permissions edit/delete my answer there, but it may help someone else, so I'm leaving it "as is" for now, realizing it's some kind a duplicate (as the question seems like)...

– Minister
Feb 23 '17 at 19:35










5 Answers
5






active

oldest

votes


















11














I noticed that even this message was shown as an error (in RED colour), the script was executed successfully! A few days later I saw a possible fix and I posted an answer on SO. The "fix" is:



# Prevent TTY Errors (copied from laravel/homestead: "homestead.rb" file)... By default this is "bash -l".
config.ssh.shell = "bash -c 'BASH_ENV=/etc/profile exec bash'"


Maybe you just don't need it, but you can try it and use it if it works for you.



As you can see in the commented line above - the "mesg: ttyname failed Inappropriate ioctl for device" has been prevented from the laravel team. Thanks for this one!



Most developers would like to avoid errors/warnings when we do development, so it seems like the fix (a possible fix) we needed.



Important note: I haven't tested this solution too much, but the box starts without the "mesg: ttyname failed Inappropriate ioctl for device" error! You are free to try it and if you experience any problems, just drop a comment to save somebody else's time!






share|improve this answer





















  • 1





    Note, this seems to break vagrant ssh -c '...'. Possibly as arguments provided are ignored.

    – Skeen
    Sep 19 '17 at 14:33



















8














1) open /root/.profile



2) remove the offensive line



3) replace it with:



tty -s && mesg n



Happy linuxing and a merry new year.



George Hart, LSU






share|improve this answer



















  • 1





    Sigh. If only the ubuntu (and other?) distro(s) would fix this in the standard /root/.profile ... Though, man tty on MacOS says that "The -s option is deprecated in favor of the ``test -t 0'' command.", so a better replacement might be test -t 0 && mesg n

    – lindes
    Dec 16 '17 at 4:39





















6














It looks like this is caused by an interaction between the default vagrant configuration of config.ssh.shell to be bash -l (which simulates a login shell, thus processing login-related configuration files such as .profile) with a line in the /root/.profile file on at least some distributions of Linux (including, e.g., the one in the ubuntu/xenial64 vagrant box), which has:



mesg n || true


A better option for this line in that file would probably be to have it say:



test -t 0 && mesg n


... and, given that that's hard to change as an individual vagrant user, a more immediate solution is to drop the -l option from the vagrant configuration, e.g. with (within Vagrantfile):



config.ssh.shell="bash"


(Caveat: It's conceivable that this change could have potentially-negative side effects. It seemed to work great for me, though, with some basic shell provisioners, e.g. with apt-get update, and so forth.)






share|improve this answer


























  • Thank you very much for this! My take: Override /root/.profile github.com/felixhummel/saltstates/blob/debian9/warts/bash/…

    – felixhummel
    Mar 10 '18 at 2:04





















1














What versions of Vagrant and VirtualBox are you using?



I was facing this issue yesterday when using Vagrant 1.8.5 with VirtualBox 5.1.4 (with Ubunty 16.04). However, after I upgraded to Vagrant 1.9.2 and VirtualBox 5.1.14 today, the issue went away.



Note that, prior to upgrading, as @Minister also mentioned, the script executed without issue. It was just outputting that "ttyname failed" message, which gave the impression that an error occurred, when actually the provisioning script executed successfully.






share|improve this answer































    0














    I had this issue start happening in a Vagrant installation that I had been using for years and had upgraded from time to time as well. I upgraded to the latest Vagrant ( 1.9.1 -> 2.0.3 ) and the problem went away. ( it also eliminated some other quirky things as well that had crept into its operation )



    Not sure if it was the new version that fixed it or that existing files/configs were freshened in the upgrade process or a combination of the two.






    share|improve this answer























      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "3"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1160025%2fhow-to-solve-ttyname-failed-inappropriate-ioctl-for-device-in-vagrant%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      5 Answers
      5






      active

      oldest

      votes








      5 Answers
      5






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      11














      I noticed that even this message was shown as an error (in RED colour), the script was executed successfully! A few days later I saw a possible fix and I posted an answer on SO. The "fix" is:



      # Prevent TTY Errors (copied from laravel/homestead: "homestead.rb" file)... By default this is "bash -l".
      config.ssh.shell = "bash -c 'BASH_ENV=/etc/profile exec bash'"


      Maybe you just don't need it, but you can try it and use it if it works for you.



      As you can see in the commented line above - the "mesg: ttyname failed Inappropriate ioctl for device" has been prevented from the laravel team. Thanks for this one!



      Most developers would like to avoid errors/warnings when we do development, so it seems like the fix (a possible fix) we needed.



      Important note: I haven't tested this solution too much, but the box starts without the "mesg: ttyname failed Inappropriate ioctl for device" error! You are free to try it and if you experience any problems, just drop a comment to save somebody else's time!






      share|improve this answer





















      • 1





        Note, this seems to break vagrant ssh -c '...'. Possibly as arguments provided are ignored.

        – Skeen
        Sep 19 '17 at 14:33
















      11














      I noticed that even this message was shown as an error (in RED colour), the script was executed successfully! A few days later I saw a possible fix and I posted an answer on SO. The "fix" is:



      # Prevent TTY Errors (copied from laravel/homestead: "homestead.rb" file)... By default this is "bash -l".
      config.ssh.shell = "bash -c 'BASH_ENV=/etc/profile exec bash'"


      Maybe you just don't need it, but you can try it and use it if it works for you.



      As you can see in the commented line above - the "mesg: ttyname failed Inappropriate ioctl for device" has been prevented from the laravel team. Thanks for this one!



      Most developers would like to avoid errors/warnings when we do development, so it seems like the fix (a possible fix) we needed.



      Important note: I haven't tested this solution too much, but the box starts without the "mesg: ttyname failed Inappropriate ioctl for device" error! You are free to try it and if you experience any problems, just drop a comment to save somebody else's time!






      share|improve this answer





















      • 1





        Note, this seems to break vagrant ssh -c '...'. Possibly as arguments provided are ignored.

        – Skeen
        Sep 19 '17 at 14:33














      11












      11








      11







      I noticed that even this message was shown as an error (in RED colour), the script was executed successfully! A few days later I saw a possible fix and I posted an answer on SO. The "fix" is:



      # Prevent TTY Errors (copied from laravel/homestead: "homestead.rb" file)... By default this is "bash -l".
      config.ssh.shell = "bash -c 'BASH_ENV=/etc/profile exec bash'"


      Maybe you just don't need it, but you can try it and use it if it works for you.



      As you can see in the commented line above - the "mesg: ttyname failed Inappropriate ioctl for device" has been prevented from the laravel team. Thanks for this one!



      Most developers would like to avoid errors/warnings when we do development, so it seems like the fix (a possible fix) we needed.



      Important note: I haven't tested this solution too much, but the box starts without the "mesg: ttyname failed Inappropriate ioctl for device" error! You are free to try it and if you experience any problems, just drop a comment to save somebody else's time!






      share|improve this answer















      I noticed that even this message was shown as an error (in RED colour), the script was executed successfully! A few days later I saw a possible fix and I posted an answer on SO. The "fix" is:



      # Prevent TTY Errors (copied from laravel/homestead: "homestead.rb" file)... By default this is "bash -l".
      config.ssh.shell = "bash -c 'BASH_ENV=/etc/profile exec bash'"


      Maybe you just don't need it, but you can try it and use it if it works for you.



      As you can see in the commented line above - the "mesg: ttyname failed Inappropriate ioctl for device" has been prevented from the laravel team. Thanks for this one!



      Most developers would like to avoid errors/warnings when we do development, so it seems like the fix (a possible fix) we needed.



      Important note: I haven't tested this solution too much, but the box starts without the "mesg: ttyname failed Inappropriate ioctl for device" error! You are free to try it and if you experience any problems, just drop a comment to save somebody else's time!







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited May 23 '17 at 12:41









      Community

      1




      1










      answered Feb 23 '17 at 19:30









      MinisterMinister

      23427




      23427








      • 1





        Note, this seems to break vagrant ssh -c '...'. Possibly as arguments provided are ignored.

        – Skeen
        Sep 19 '17 at 14:33














      • 1





        Note, this seems to break vagrant ssh -c '...'. Possibly as arguments provided are ignored.

        – Skeen
        Sep 19 '17 at 14:33








      1




      1





      Note, this seems to break vagrant ssh -c '...'. Possibly as arguments provided are ignored.

      – Skeen
      Sep 19 '17 at 14:33





      Note, this seems to break vagrant ssh -c '...'. Possibly as arguments provided are ignored.

      – Skeen
      Sep 19 '17 at 14:33













      8














      1) open /root/.profile



      2) remove the offensive line



      3) replace it with:



      tty -s && mesg n



      Happy linuxing and a merry new year.



      George Hart, LSU






      share|improve this answer



















      • 1





        Sigh. If only the ubuntu (and other?) distro(s) would fix this in the standard /root/.profile ... Though, man tty on MacOS says that "The -s option is deprecated in favor of the ``test -t 0'' command.", so a better replacement might be test -t 0 && mesg n

        – lindes
        Dec 16 '17 at 4:39


















      8














      1) open /root/.profile



      2) remove the offensive line



      3) replace it with:



      tty -s && mesg n



      Happy linuxing and a merry new year.



      George Hart, LSU






      share|improve this answer



















      • 1





        Sigh. If only the ubuntu (and other?) distro(s) would fix this in the standard /root/.profile ... Though, man tty on MacOS says that "The -s option is deprecated in favor of the ``test -t 0'' command.", so a better replacement might be test -t 0 && mesg n

        – lindes
        Dec 16 '17 at 4:39
















      8












      8








      8







      1) open /root/.profile



      2) remove the offensive line



      3) replace it with:



      tty -s && mesg n



      Happy linuxing and a merry new year.



      George Hart, LSU






      share|improve this answer













      1) open /root/.profile



      2) remove the offensive line



      3) replace it with:



      tty -s && mesg n



      Happy linuxing and a merry new year.



      George Hart, LSU







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Dec 25 '16 at 15:56









      George HartGeorge Hart

      971




      971








      • 1





        Sigh. If only the ubuntu (and other?) distro(s) would fix this in the standard /root/.profile ... Though, man tty on MacOS says that "The -s option is deprecated in favor of the ``test -t 0'' command.", so a better replacement might be test -t 0 && mesg n

        – lindes
        Dec 16 '17 at 4:39
















      • 1





        Sigh. If only the ubuntu (and other?) distro(s) would fix this in the standard /root/.profile ... Though, man tty on MacOS says that "The -s option is deprecated in favor of the ``test -t 0'' command.", so a better replacement might be test -t 0 && mesg n

        – lindes
        Dec 16 '17 at 4:39










      1




      1





      Sigh. If only the ubuntu (and other?) distro(s) would fix this in the standard /root/.profile ... Though, man tty on MacOS says that "The -s option is deprecated in favor of the ``test -t 0'' command.", so a better replacement might be test -t 0 && mesg n

      – lindes
      Dec 16 '17 at 4:39







      Sigh. If only the ubuntu (and other?) distro(s) would fix this in the standard /root/.profile ... Though, man tty on MacOS says that "The -s option is deprecated in favor of the ``test -t 0'' command.", so a better replacement might be test -t 0 && mesg n

      – lindes
      Dec 16 '17 at 4:39













      6














      It looks like this is caused by an interaction between the default vagrant configuration of config.ssh.shell to be bash -l (which simulates a login shell, thus processing login-related configuration files such as .profile) with a line in the /root/.profile file on at least some distributions of Linux (including, e.g., the one in the ubuntu/xenial64 vagrant box), which has:



      mesg n || true


      A better option for this line in that file would probably be to have it say:



      test -t 0 && mesg n


      ... and, given that that's hard to change as an individual vagrant user, a more immediate solution is to drop the -l option from the vagrant configuration, e.g. with (within Vagrantfile):



      config.ssh.shell="bash"


      (Caveat: It's conceivable that this change could have potentially-negative side effects. It seemed to work great for me, though, with some basic shell provisioners, e.g. with apt-get update, and so forth.)






      share|improve this answer


























      • Thank you very much for this! My take: Override /root/.profile github.com/felixhummel/saltstates/blob/debian9/warts/bash/…

        – felixhummel
        Mar 10 '18 at 2:04


















      6














      It looks like this is caused by an interaction between the default vagrant configuration of config.ssh.shell to be bash -l (which simulates a login shell, thus processing login-related configuration files such as .profile) with a line in the /root/.profile file on at least some distributions of Linux (including, e.g., the one in the ubuntu/xenial64 vagrant box), which has:



      mesg n || true


      A better option for this line in that file would probably be to have it say:



      test -t 0 && mesg n


      ... and, given that that's hard to change as an individual vagrant user, a more immediate solution is to drop the -l option from the vagrant configuration, e.g. with (within Vagrantfile):



      config.ssh.shell="bash"


      (Caveat: It's conceivable that this change could have potentially-negative side effects. It seemed to work great for me, though, with some basic shell provisioners, e.g. with apt-get update, and so forth.)






      share|improve this answer


























      • Thank you very much for this! My take: Override /root/.profile github.com/felixhummel/saltstates/blob/debian9/warts/bash/…

        – felixhummel
        Mar 10 '18 at 2:04
















      6












      6








      6







      It looks like this is caused by an interaction between the default vagrant configuration of config.ssh.shell to be bash -l (which simulates a login shell, thus processing login-related configuration files such as .profile) with a line in the /root/.profile file on at least some distributions of Linux (including, e.g., the one in the ubuntu/xenial64 vagrant box), which has:



      mesg n || true


      A better option for this line in that file would probably be to have it say:



      test -t 0 && mesg n


      ... and, given that that's hard to change as an individual vagrant user, a more immediate solution is to drop the -l option from the vagrant configuration, e.g. with (within Vagrantfile):



      config.ssh.shell="bash"


      (Caveat: It's conceivable that this change could have potentially-negative side effects. It seemed to work great for me, though, with some basic shell provisioners, e.g. with apt-get update, and so forth.)






      share|improve this answer















      It looks like this is caused by an interaction between the default vagrant configuration of config.ssh.shell to be bash -l (which simulates a login shell, thus processing login-related configuration files such as .profile) with a line in the /root/.profile file on at least some distributions of Linux (including, e.g., the one in the ubuntu/xenial64 vagrant box), which has:



      mesg n || true


      A better option for this line in that file would probably be to have it say:



      test -t 0 && mesg n


      ... and, given that that's hard to change as an individual vagrant user, a more immediate solution is to drop the -l option from the vagrant configuration, e.g. with (within Vagrantfile):



      config.ssh.shell="bash"


      (Caveat: It's conceivable that this change could have potentially-negative side effects. It seemed to work great for me, though, with some basic shell provisioners, e.g. with apt-get update, and so forth.)







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Mar 3 '18 at 13:20

























      answered Dec 16 '17 at 5:15









      lindeslindes

      2601311




      2601311













      • Thank you very much for this! My take: Override /root/.profile github.com/felixhummel/saltstates/blob/debian9/warts/bash/…

        – felixhummel
        Mar 10 '18 at 2:04





















      • Thank you very much for this! My take: Override /root/.profile github.com/felixhummel/saltstates/blob/debian9/warts/bash/…

        – felixhummel
        Mar 10 '18 at 2:04



















      Thank you very much for this! My take: Override /root/.profile github.com/felixhummel/saltstates/blob/debian9/warts/bash/…

      – felixhummel
      Mar 10 '18 at 2:04







      Thank you very much for this! My take: Override /root/.profile github.com/felixhummel/saltstates/blob/debian9/warts/bash/…

      – felixhummel
      Mar 10 '18 at 2:04













      1














      What versions of Vagrant and VirtualBox are you using?



      I was facing this issue yesterday when using Vagrant 1.8.5 with VirtualBox 5.1.4 (with Ubunty 16.04). However, after I upgraded to Vagrant 1.9.2 and VirtualBox 5.1.14 today, the issue went away.



      Note that, prior to upgrading, as @Minister also mentioned, the script executed without issue. It was just outputting that "ttyname failed" message, which gave the impression that an error occurred, when actually the provisioning script executed successfully.






      share|improve this answer




























        1














        What versions of Vagrant and VirtualBox are you using?



        I was facing this issue yesterday when using Vagrant 1.8.5 with VirtualBox 5.1.4 (with Ubunty 16.04). However, after I upgraded to Vagrant 1.9.2 and VirtualBox 5.1.14 today, the issue went away.



        Note that, prior to upgrading, as @Minister also mentioned, the script executed without issue. It was just outputting that "ttyname failed" message, which gave the impression that an error occurred, when actually the provisioning script executed successfully.






        share|improve this answer


























          1












          1








          1







          What versions of Vagrant and VirtualBox are you using?



          I was facing this issue yesterday when using Vagrant 1.8.5 with VirtualBox 5.1.4 (with Ubunty 16.04). However, after I upgraded to Vagrant 1.9.2 and VirtualBox 5.1.14 today, the issue went away.



          Note that, prior to upgrading, as @Minister also mentioned, the script executed without issue. It was just outputting that "ttyname failed" message, which gave the impression that an error occurred, when actually the provisioning script executed successfully.






          share|improve this answer













          What versions of Vagrant and VirtualBox are you using?



          I was facing this issue yesterday when using Vagrant 1.8.5 with VirtualBox 5.1.4 (with Ubunty 16.04). However, after I upgraded to Vagrant 1.9.2 and VirtualBox 5.1.14 today, the issue went away.



          Note that, prior to upgrading, as @Minister also mentioned, the script executed without issue. It was just outputting that "ttyname failed" message, which gave the impression that an error occurred, when actually the provisioning script executed successfully.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Mar 7 '17 at 21:31









          kvjava1kvjava1

          211




          211























              0














              I had this issue start happening in a Vagrant installation that I had been using for years and had upgraded from time to time as well. I upgraded to the latest Vagrant ( 1.9.1 -> 2.0.3 ) and the problem went away. ( it also eliminated some other quirky things as well that had crept into its operation )



              Not sure if it was the new version that fixed it or that existing files/configs were freshened in the upgrade process or a combination of the two.






              share|improve this answer




























                0














                I had this issue start happening in a Vagrant installation that I had been using for years and had upgraded from time to time as well. I upgraded to the latest Vagrant ( 1.9.1 -> 2.0.3 ) and the problem went away. ( it also eliminated some other quirky things as well that had crept into its operation )



                Not sure if it was the new version that fixed it or that existing files/configs were freshened in the upgrade process or a combination of the two.






                share|improve this answer


























                  0












                  0








                  0







                  I had this issue start happening in a Vagrant installation that I had been using for years and had upgraded from time to time as well. I upgraded to the latest Vagrant ( 1.9.1 -> 2.0.3 ) and the problem went away. ( it also eliminated some other quirky things as well that had crept into its operation )



                  Not sure if it was the new version that fixed it or that existing files/configs were freshened in the upgrade process or a combination of the two.






                  share|improve this answer













                  I had this issue start happening in a Vagrant installation that I had been using for years and had upgraded from time to time as well. I upgraded to the latest Vagrant ( 1.9.1 -> 2.0.3 ) and the problem went away. ( it also eliminated some other quirky things as well that had crept into its operation )



                  Not sure if it was the new version that fixed it or that existing files/configs were freshened in the upgrade process or a combination of the two.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Apr 3 '18 at 14:24









                  G-ManG-Man

                  1012




                  1012






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Super User!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1160025%2fhow-to-solve-ttyname-failed-inappropriate-ioctl-for-device-in-vagrant%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

                      Mangá

                       ⁒  ․,‪⁊‑⁙ ⁖, ⁇‒※‌, †,⁖‗‌⁝    ‾‸⁘,‖⁔⁣,⁂‾
”‑,‥–,‬ ,⁀‹⁋‴⁑ ‒ ,‴⁋”‼ ⁨,‷⁔„ ‰′,‐‚ ‥‡‎“‷⁃⁨⁅⁣,⁔
⁇‘⁔⁡⁏⁌⁡‿‶‏⁨ ⁣⁕⁖⁨⁩⁥‽⁀  ‴‬⁜‟ ⁃‣‧⁕‮ …‍⁨‴ ⁩,⁚⁖‫ ,‵ ⁀,‮⁝‣‣ ⁑  ⁂– ․, ‾‽ ‏⁁“⁗‸ ‾… ‹‡⁌⁎‸‘ ‡⁏⁌‪ ‵⁛ ‎⁨ ―⁦⁤⁄⁕