[gentoo-user] qemu-kvm replacement
Hi, with my recent qemu update from 1.6 to 2.0 I got the following error: * The kvm/qemu-kvm wrappers no longer exist, but your libvirt * instances are still pointing to it. Please update your * configs in /etc/libvirt/qemu/ to use the -enable-kvm flag * and the right system binary (e.g. qemu-system-x86_64). * ERROR: app-emulation/qemu-2.0.0::gentoo failed (pretend phase): * update your virt configs to not use qemu-kvm * * Call stack: * ebuild.sh, line 93: Called pkg_pretend * qemu-2.0.0.ebuild, line 225: Called die * The specific snippet of code: * die update your virt configs to not use qemu-kvm I found this bug which explains the why but sadly not the how. https://bugs.gentoo.org/show_bug.cgi?id=506566 I need to get rid of the reference to the /usr/bin/qemu-kvm shell script which is basically only a wrapper for exec /usr/bin/qemu-system-x86_64 -machine accel=kvm $@ So if I sudo virsh edit vmname and substitute /usr/bin/qemu-kvm by /usr/bin/qemu-system-x86_64 -machine accel=kvm -enable-kvm I only get this error :( error: Cannot check QEMU binary /usr/bin/qemu-system-x86_64 -machine accel=kvm -enable-kvm: No such file or directory How is this supposed to work? Do I need to create a custom shell skript or just use /usr/bin/qemu-system-x86_64 w/o the args an hope it magically uses kvm acceleration? thanks for the help! heiko -- Just go ahead and write your own multitasking multiuser os! Worked for me all the times. -- Linus Torvalds
[gentoo-user] Re: Eth0 interface not found - udev that little slut!!!!!
On 06.04.2013 21:11, Jörg Schaible wrote:
Jarry wrote:
On 06-Apr-13 19:10, Alan Mackenzie wrote:
STOP SPREADING THIS FUD
It did not happen to pretty much everybody. It happened to people
who
blindly updated thignsd and walked away, who did not read the news
announcement, who did not read the CLEARLY WORDED wiki article at
freedesktop.org or alternatively went into mod-induced panic and
started
making shit up in their heads.
Steady on, old chap! By it I was meaning the general
inconvenience
all round occasioned by the changes between udev-{197,200}. Not
everybody encountered this. For example Dale, and Walt D. didn't
have
to do anything. But pretty much everybody else did.
The problem is, news item is not correct! I followed it
and yet finished with server having old network name (eth0).
Problem was the point 4. in news item, which is not quite clear:
-
4. predictable network interface names:
If /etc/udev/rules.d/80-net-name-slot.rules is an empty file
or a symlink to /dev/null, the new names will be disabled and
the kernel will do all the interface naming...
-
Well, in my case 80-net-names-slot.rules was neither empty,
nor symlink to dev null, but FULL OF COMMENTS AND NOTING ELSE,
which basically did the same thing as empty file: disabled
new network names. Unfortunatelly, I found it just after
screwed reboot. But I did everything I found in news item:
checked and verified that file was not symlink to /dev/null
and that it was not empty (1667 bytes does not seem to me
to be empty file).
As I wrote previously, I am pretty sure I never created this
file manually so it must have been created by som previous
udev-version. So I finished up with similar problem as OP:
after rebooting I did not find interface I expected. The
only difference is I expected already interface with new
name, and OP is probably the old one...
You're not alone, this happened for me on all my 4 machines.
Same confusion here, but this paragraph saved my ass
--
In a normal new installation there are no files in /etc/udev/rules.d
and if you haven't edited any files you have in there, you should most
likely backup and delete them all if they don't belong to any packages.
--
So I checked and just removed all files. luckily everything went fine
:)
So I must add my point to complaining about news item
not beeing quite clear. And this happens quite often...
heiko
Re: [gentoo-user] fetchmail + certs = problems
On Sat, Oct 02, 2010 at 12:31:38PM +0200, meino.cra...@gmx.de wrote: Hi, fetchmail's log told me, that there is something wrong with the setup of the certificats. In the log there is the following section fetchmail: Server certificate: fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Subject CommonName: pop.gmx.net fetchmail: pop.gmx.net key fingerprint: A6:57:BC:4A:97:AD:DB:99:00:E9:3A:B8:81:55:D7:B6 fetchmail: Server certificate verification error: unable to get local issuer certificate fetchmail: This means that the root signing certificate (issued for /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=pop.gmx.net) is not in the trusted CA certificate locations, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page. fetchmail: Server certificate: fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Subject CommonName: pop.gmx.net fetchmail: Server certificate verification error: certificate not trusted fetchmail: Server certificate: fetchmail: Issuer Organization: Thawte Consulting cc fetchmail: Issuer CommonName: Thawte Premium Server CA fetchmail: Subject CommonName: pop.gmx.net fetchmail: Server certificate verification error: unable to verify the first certificate fetchmail: Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!) In beforehand I did the following: i did pretty much the same thing without success :( but the sslcertfile option in the default section of my .fetchmailrc finaly solved the problem: he...@chiefwiggum:~ cat .fetchmailrc defaults proto pop3 limit 0 mda /usr/bin/procmail -d %T sslcertfile /etc/ssl/certs/ca-certificates.crt poll pop.1und1.de user xxx keep ssl poll pop.gmx.net user xxx keep ssl option sslcertfile in the fetchmail manpage and the update-ca-certificates manpage gave me the hint. cheers heiko -- This email is not and cannot, by its nature, be confidential. En route from me to you, it will pass across the public Internet, easily readable by any number of system administrators along the way. If you have received this message by mistake, it would be ridiculous for me to tell you not to read it or copy to anyone else, because, let's face it, if it's a message revealing confidential information or that could embarrass me intensely, that's precisely what you'll do. Who wouldn't? Likewise, it is superfluous for me to claim copyright in the contents, because I own that anyway, even if you print out a hard copy or disseminate this message all over the known universe. I don't know why so many corporate mail servers feel impelled to attach a disclaimer to the bottom of every email message saying otherwise. If you don't know either, why not email your corporate lawyers and system administrators and ask them why they insist on contributing so much to the waste of bandwidth? To say nothing of making the presence of your mail on public discussions or mailinglists of explicitly contratictory nature. May as well just delete it, eh? Oh, and this message is probably plagued with viruses as well. pgp8wdHnW3hk1.pgp Description: PGP signature
