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

Debian Wheezy build error: qemu-system-x86_64: -device virtio-rng-pci: Parameter 'driver' expects device type #127

Closed
ghost opened this Issue Dec 13, 2013 · 10 comments

Comments

Projects
None yet
6 participants
@ghost

ghost commented Dec 13, 2013

Building OSv under Debian Wheezy x64 and there is the following error:

Creating bare.img as qcow2

/usr/local/src/OSv/osv/scripts/mkzfs.py -o bare.img -d bare.img.d -m /usr/local/src/OSv/osv/build/release/bootfs.manifest
qemu-system-x86_64: -device virtio-rng-pci: Parameter 'driver' expects device type
Traceback (most recent call last):
File "/usr/local/src/OSv/osv/scripts/mkzfs.py", line 40, in
upload_manifest.upload(osv, manifest, depends)
File "/usr/local/src/OSv/osv/scripts/upload_manifest.py", line 58, in upload
s.connect(("127.0.0.1", 10000));
File "/usr/lib/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(args)
socket.error: [Errno 111] Connection refused
make[1]: *
* [bare.img] Error 1
make[1]: *** Deleting file `bare.img'

@KarimAllah

This comment has been minimized.

Show comment
Hide comment
@KarimAllah

KarimAllah Jan 5, 2014

Rebuild qemu with VirtFS enabled ( ./configure --enable-virtfs )

For me I rebuilt it from source and had to do "${qemu-src}/pc-bios/bios-256k.bin /usr/local/share/qemu/" because for some reason it was missing

KarimAllah commented Jan 5, 2014

Rebuild qemu with VirtFS enabled ( ./configure --enable-virtfs )

For me I rebuilt it from source and had to do "${qemu-src}/pc-bios/bios-256k.bin /usr/local/share/qemu/" because for some reason it was missing

@dorlaor

This comment has been minimized.

Show comment
Hide comment
@dorlaor

dorlaor Jan 5, 2014

Contributor

Can you please clarify - is OSv the issue or Qemu?
OSv doesn't support vplan over virtio (virtFS) yet.

Contributor

dorlaor commented Jan 5, 2014

Can you please clarify - is OSv the issue or Qemu?
OSv doesn't support vplan over virtio (virtFS) yet.

@KarimAllah

This comment has been minimized.

Show comment
Hide comment
@KarimAllah

KarimAllah Jan 11, 2014

Okay, I've rechecked what I've done before to make sure that my steps are correct.

Apparently --enable-virtfs has nothing to do with it, actually even with --disable-virtfs it will just work.
I think recompiling qemu from sources fixed that problem. I don't think this OSv specific issue, I think it's one of the features in qemu that is disabled in the ubuntu/debian build.

KarimAllah commented Jan 11, 2014

Okay, I've rechecked what I've done before to make sure that my steps are correct.

Apparently --enable-virtfs has nothing to do with it, actually even with --disable-virtfs it will just work.
I think recompiling qemu from sources fixed that problem. I don't think this OSv specific issue, I think it's one of the features in qemu that is disabled in the ubuntu/debian build.

@slivne

This comment has been minimized.

Show comment
Hide comment
@slivne

slivne Jul 31, 2014

Contributor

@dorlaor can we close this ?

Contributor

slivne commented Jul 31, 2014

@dorlaor can we close this ?

@dorlaor

This comment has been minimized.

Show comment
Hide comment
@dorlaor

dorlaor Jul 31, 2014

Contributor

It depends whether we handle a case where there is no rng device in Debian.
I guess it's worth to check run.py to test this condition anyway.

On Thu, Jul 31, 2014 at 12:01 PM, slivne notifications@github.com wrote:

@dorlaor https://github.com/dorlaor can we close this ?


Reply to this email directly or view it on GitHub
#127 (comment)
.

Contributor

dorlaor commented Jul 31, 2014

It depends whether we handle a case where there is no rng device in Debian.
I guess it's worth to check run.py to test this condition anyway.

On Thu, Jul 31, 2014 at 12:01 PM, slivne notifications@github.com wrote:

@dorlaor https://github.com/dorlaor can we close this ?


Reply to this email directly or view it on GitHub
#127 (comment)
.

@penberg

This comment has been minimized.

Show comment
Hide comment
@penberg

penberg Jul 31, 2014

Member

There was a patch on the list to parse QEMU version in run.py and only enable virtio-rng if QEMU supports it. The patch was never merged because it was quite invasive and the benefit was pretty small. Most people develop on up-to-date distributions so it's not a huge problem.

Member

penberg commented Jul 31, 2014

There was a patch on the list to parse QEMU version in run.py and only enable virtio-rng if QEMU supports it. The patch was never merged because it was quite invasive and the benefit was pretty small. Most people develop on up-to-date distributions so it's not a huge problem.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Aug 1, 2014

Hopefully you don't consider the current stable release of Debian as not up-to-date

ghost commented Aug 1, 2014

Hopefully you don't consider the current stable release of Debian as not up-to-date

@penberg

This comment has been minimized.

Show comment
Hide comment
@penberg

penberg Aug 1, 2014

Member

@KSSea What do you mean?

The whole point of Debian stable is to be stable, not up-to-date. QEMU 1.3 (which is the first one to support virtio-rng) was released in November 2012 and AFAICT Debian stable is still shipping 1.1.2 which was released earlier that year.

Most developers I know use Debian unstable, not Debian stable exactly because the stable branch lags behind so much. We fixed this problem in Capstan because we want people to be able to use OSv on older distributions. However, developing OSv on Debian stable is going to be painful anyway because of GCC is locked at version 4.6 or 4.7 and we're aggressively using C++11 features. So I don't see a huge benefit in fixing run.py to support older QEMU versions.

Of course, if there's someone who actually develops OSv on Debian stable, feel free to send a patch to fix this up and I'll apply the patch.

Member

penberg commented Aug 1, 2014

@KSSea What do you mean?

The whole point of Debian stable is to be stable, not up-to-date. QEMU 1.3 (which is the first one to support virtio-rng) was released in November 2012 and AFAICT Debian stable is still shipping 1.1.2 which was released earlier that year.

Most developers I know use Debian unstable, not Debian stable exactly because the stable branch lags behind so much. We fixed this problem in Capstan because we want people to be able to use OSv on older distributions. However, developing OSv on Debian stable is going to be painful anyway because of GCC is locked at version 4.6 or 4.7 and we're aggressively using C++11 features. So I don't see a huge benefit in fixing run.py to support older QEMU versions.

Of course, if there's someone who actually develops OSv on Debian stable, feel free to send a patch to fix this up and I'll apply the patch.

@wkozaczuk

This comment has been minimized.

Show comment
Hide comment
@wkozaczuk

wkozaczuk Jun 14, 2018

Collaborator

Should this one be closed?

Collaborator

wkozaczuk commented Jun 14, 2018

Should this one be closed?

@nyh

This comment has been minimized.

Show comment
Hide comment
@nyh

nyh Jun 17, 2018

Contributor

Yes. virtio-rng was added to qemu at the end of 2012. Nobody should be using older qemu today.

Contributor

nyh commented Jun 17, 2018

Yes. virtio-rng was added to qemu at the end of 2012. Nobody should be using older qemu today.

@nyh nyh closed this Jun 17, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment