releng

#7814 Fedora Scientific 29 Beta 1.3 vagrant box - virtualbox issue
Closed: Fixed Opened by amitksaha.

Closed: Fixed
Reopen Issue
  • Describe the issue

I downloaded the Fedora Scientific Vagrant box for VirtualBox from [1] and noticed that neither SSH auth nor password auth works. SSH auth:

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'Fedora-Scientific-29-Beta-1.3'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM:
scientific_spin_tests_default_1537156143474_55182
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
..

For password auth, the default vagrant password doesn't work either:

> vagrant ssh
vagrant@127.0.0.1's password:

I tried another Vagrant box (Fedora Python classroom) and that looks good as far as the SSH auth is concerned.

[1] https://dl.fedoraproject.org/pub/alt/stage/29_Beta-1.3/Labs/x86_64/images/

Any suggestions on how to figure out what's going on?

  • When do you need this? (YYYY/MM/DD)

Sooner the better

  • When is this no longer needed or useful? (YYYY/MM/DD)

After Fedora 29 release

  • If we cannot complete your request, what is the impact?

We will not have working Fedora Scientific vagrant boxes

Since the fedora-scientific-vagrant.ks includes fedora-cloud-base-vagrant.ks I would try out the cloud base and see if that looks good. If so I would extract the /root/anaconda-ks.cfg from the bad one (scientific) and a good one and diff them to see what's different.

Thanks for the tip! I did a diff, and besides the packages, the diff is:

diff cloud-base.cfg fedora-scientific.cfg
4c4,5
< bootloader --append="no_timer_check console=tty1 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0" --location=mbr --timeout=1 --boot-drive=vdaautopart --type=plain --nohome --noboot --noswap
---
> bootloader --append="no_timer_check console=tty1 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0" --location=mbr --timeout=1 --boot-drive=vda
> autopart --type=plain --nohome --noboot --noswap
13c14
< repo --name="koji-override-0" --baseurl=http://kojipkgs.fedoraproject.org/compose/29/Fedora-29-20180912.0/compose/Everything/x86_64/os
---
> repo --name="koji-override-0" --baseurl=http://kojipkgs.fedoraproject.org/compose/29/Fedora-29-20180916.0/compose/Everything/x86_64/os
15c16
< url --url="https://kojipkgs.fedoraproject.org/compose/29/Fedora-29-20180912.0/compose/Everything/x86_64/os"
---
> url --url="https://kojipkgs.fedoraproject.org/compose/29/Fedora-29-20180916.0/compose/Everything/x86_64/os"

I then compared the classroom vagrant image configuration with scientific, but cannot see any
other difference other than the packages.

Would you have any other suggestions?

bootloader --append="no_timer_check console=tty1 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0" --location=mbr --timeout=1 --boot-drive=vdaautopart --type=plain --nohome --noboot --noswap is all on one line in one of the files. that looks wrong

can you confirm that is the case?

That was me diffing wrongly. Besides, I diffed Beta 1.1 and Beta 1.3.

Now, I re-diffed Beta 1.3 of Scientific and Cloud base and I see no differences other than the additional packages in Scientific. Everything looks sane!

I cannot use vagrant/vagrant or root/vagrant to login from the virtualbox console either (no SSH i.e.).
Edited by amitksaha

i guess it's possible something in the package set is causing things to get locked down? Can you build images locally? If so I would try to build a cloud base image and verify it works then build the scientific image and make sure it doesn't, then try to add in packages and see if there is any one (or group) that causes the problem to crop up.

i guess it's possible something in the package set is causing things to get locked down? Can you build images locally? If so I would try to build a cloud base image and verify it works then build the scientific image and make sure it doesn't, then try to add in packages and see if there is any one (or group) that causes the problem to crop up.

I can do that - is there instructions somewhere for vagrant box building?

I should mention that, I tested a virtual box vagrant image for Scientific when the support was first landed, and had no issues back then,

Thanks for your help so far!

i guess it's possible something in the package set is causing things to get locked down? Can you build images locally? If so I would try to build a cloud base image and verify it works then build the scientific image and make sure it doesn't, then try to add in packages and see if there is any one (or group) that causes the problem to crop up.

I can do that - is there instructions somewhere for vagrant box building?

something like this might help, but I warn that it's not the easiest thing to set up.

I should mention that, I tested a virtual box vagrant image for Scientific when the support was first landed, and had no issues back then,

can you test against rawhide? that might give us another datapoint

Thanks for your help so far!

np. sorry I can't really do any work for this, but I can try to guide and ask questions

i guess it's possible something in the package set is causing things to get locked down? Can you build images locally? If so I would try to build a cloud base image and verify it works then build the scientific image and make sure it doesn't, then try to add in packages and see if there is any one (or group) that causes the problem to crop up.
I can do that - is there instructions somewhere for vagrant box building?

something like this might help, but I warn that it's not the easiest thing to set up.

Thanks. Not something I can get up and running easily for sure :-(

I should mention that, I tested a virtual box vagrant image for Scientific when the support was first landed, and had no issues back then,

can you test against rawhide? that might give us another datapoint

Same result. I went as far back as /Fedora-Scientific-Vagrant-Rawhide-20180903.n.0.x86_64.vagrant-virtualbox.box, but same result.

Thanks for your help so far!

np. sorry I can't really do any work for this, but I can try to guide and ask questions

i guess it's possible something in the package set is causing things to get locked down?

looks like it was the eclipse group that was causing the issue. https://pagure.io/fedora-kickstarts/pull-request/440 is a workaround for now.

Actually turns out, it was eclipse-linuxtools-vagrant
Edited by amitksaha

Looking good as of https://koji.fedoraproject.org/koji/buildinfo?buildID=1148209

Thanks for all the help @dustymabe

Looking good as of https://koji.fedoraproject.org/koji/buildinfo?buildID=1148209
Thanks for all the help @dustymabe

:thumbsup:

Metadata Update from @dustymabe:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.