-
Notifications
You must be signed in to change notification settings - Fork 14
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.
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
biosdevname #1
Comments
Also that whois thing still hasn't propagated. Any ideas? Apparently it got reverted. Where's your new PR? |
One more question, I used your mkpasswd patch, so it now finishes installing, but ssh doesn't start on startup even though I used Apparently it does start, but not accessible from Packer. |
Yeah. So, I use So, for example, if you had these lines your Vagrantfile: config.vm.network "private_network", type: "dhcp" # Adapter #1
config.vm.network "private_network", ip: "192.168.50.4" # Adapter #2
config.vm.network "public_network" # Adapter #3 Given the configuration above, the Vagrant guest plugin is invoked with a list of "networks", each with a given adapter number as seen above. What the plugin isn't given is the device name, which is what I actually need to put in the configuration file. Remember that you always have one more interface than what you have in your Vagrantfile - that interface is the NAT, which you don't want to configure. So I jump through these hoops to get the right names for each adapter number, and thus avoid accidentally configuring the NAT. (To be extra explicit, the order that the kernel discovers interfaces isn't deterministic. For instance, if you have a server, and you see that you have an If While all of above might sound convincing, I actually discovered most of this stuff over the past week or so. So, if anyone sees any holes in my understanding, and can explain why some of these gyrations aren't necessary, I'd gladly simplify the code in the Vagrant plugin (and I always like to learn when I'm wrong). You can check out the PR that added the above support: hashicorp/vagrant#3830
Yeah, that got reverted because it made use of I'll submit a compatible PR shortly.
Hmmm... I'm not sure why that would be, but I can keep it in the back of my mind. If you put your Packer definition online, I'll take a look and see if anything stands out. |
Oh right, so biosdevname is intended to be used with the Vagrant plugin you have. Is that plugin automatically ran, or do I have to configure it somewhere? |
It will automatically run. You'll need to wait for the v1.6.3 release though (or manually install HEAD). It will write |
So that's what the empty vagrant-network and vagrant-hostname is for. A question, why does Nixos need this special treatment and not other OSes? |
Yep!
What special treatment are you referring to? I'm asking genuinely (not being snarky). |
Do other OSes need biosdevname as well? Because I was doing ctrl+f on the vagrant plugin, and I saw the conditional logic regarding biosdevname vs ifconfig -a, I was wondering if this just specific to nixos. |
Other OSes need similar support to be as bullet proof. If you look at the other Vagrant guest OS plugins, most are pretty simple - they usually just prefix the adapter number with "eth" and get something like The simple "prefix the adapter number with eth rule" is also a bad assumption anyway, because So the simple plugins are simple because they don't support OSes with non-ethN style interface names, don't protect against the nondeterminism in how the Linux kernel detects/names interfaces, or because they make an assumption or two about what packages are installed. This isn't a failing on NixOS's part; it's universally tricky to (correctly) answer the question "what's the name of the NIC in the Nth slot?" |
Hey have you added biosdevname to the official Nix packages? That way we don't need to patch it in during our builds. It would be great if there was a way to autocreate the vagrant-hostname and vagrant-networks during the vagrant provisioning phase instead of the packer phase though. |
I'm getting a build error with regards to biosdevname:
I tried using dos2unix and unix2dos but I don't think this is the makefile patch that you have in your current repository, its coming from somewhere else. But yes, biosdevname is not installable on my NixOS currently. |
Is this with the package that I added upstream? Can you share the Here's something to watch out for: if you copied the patch file from the browser, tabs will probably be replaced with spaces, which will cause |
Hmm... that could be the source of the problem. But why is biosdevname not in the official channels? Also my box is working without biosdevname right now, so I'm semi happy. I deleted the Makefile thing and biosdevname so I don't have atm. |
I think the package is just waiting for someone to backport, or waiting to be part of the next release. |
So it's already part of the master? |
Yep! |
Should I put up an issue asking for backporting? Do you have a link to the specific commit for the biosdevname package in master branch? |
That might not be a bad idea; here's the PR: NixOS/nixpkgs#2632 |
If biosdevname becomes available, do we still need to create vagrant-hostname and vagrant-networks? I guess so since they are somewhat orthogonal. Is there a way to declaratively create those files, rather than just making those files and expecting something else to fill them out later? |
It got backported! Still wondering about my above question though. |
Wow after studying MAC addresses, hexadecimals, IPV6, biosdevname, ethernet NICs and your pull request, I finally get it. Ok so the reason we have those empty vagrant-hostname/vagrant-networks.nix files is so that Nix won't throw an error when we are importing those. However the vagrant PR is only available in 1.6.3, which is now available. Thanks, I'll try to use it and report back with any errors. |
Yep! I might add a comment to the empty files to clarify - a sort of "this page left intentionally blank". |
Something's weird. I've done everything, but when I go and checkout what's inside Is the biosdevname kicking in during the provisioning phase? Because it doesn't seem to be working. |
I did notice you changed some stuff especially here:
I was just putting in biosdevname as a package that needs to be installed. Any ideas? |
The files should be written whenever you restart the box, e.g.
I just made the |
I've tried doing that, vagrant halt and vagrant up, and also nixos-rebuild switch. But nothing. My vagrant version is 1.6.3. Here's my files: vagrant-hostname.nix
vagrant-network.nix
Here's the import in my configuration.nix (which works of course)
Bringing in the biosdevname:
In my provisioning script in Packer I have this line (which works as well):
My vagrant file is just this:
So nothing special. The biosdevname is installed, and the files inside Perhaps there's a permission issue? Maybe the overwriting is failing because of permissions? In that case, here's my users portion of my
|
In the example Vagrantfile you gave, you're not specifying a hostname or any networks - perhaps Vagrant doesn't run those two "capabilities" (in Vagrant terms) when neither are specified. Would you mind setting those and seeing if that makes a difference? |
Hey I set this Then I checked the vagrant-hostname.nix and vagrant-network.nix. I found this inside my vagrant-network.nix:
However vagrant-hostname.nix was still the same and nothing got changed. So it looks like biosdevname is working, but I'm guessing something else is meant to be triggering vagrant-hostname.nix? |
It should work if you put |
Hey @cstrahan
So what is the biosdevname used for? Is it related to this issue? hashicorp/vagrant#2614
Why does Vagrant need biosdevname, and is biosdevname not part of the standard packages?
The text was updated successfully, but these errors were encountered: