I'm running Gentoo right now, I'm using QEMU with KVM support to run a Windows VM, I need to because they're forcing us to use a proprietary CAD software at university (sadly enough). They gave us a license for a year, however when I activate it, it clearly says the license can't be used in a virtual environment. This leads me to the conclusion that somehow the system recognizes it is being emulated and I know there's a way to avoid this, but I actually have no idea what to do. I've read someone had the same problem and apparently solved it, however his solution doesn't seem to work for me. I'll leave you the URL of the question on Stack. https://serverfault.com/questions/727347/solidworks-activation-license-mode-is-not-supported-in-this-virtual-environment
This command:
qemu-system-x86_
64 -enable-kvm -hda windows.qcow2 -cpu host,kvm=off -smbios type=0,vendor=LENOVO,version=FBKTB4AUS,date=07/01/2015,release=1.180 -smbios type=1,manufacturer=LENOVO,product=30AH001GPB,version=ThinkStation P300,serial=S4M88119,uuid=cecf333d-6603-e511-97d5-6c0b843f98ba,sku=LENOVO_MT_30AH,family=P300 -m 8G
gives the output:
qemu-system-x86_64: -smbios type=1,manufacturer=LENOVO,product=30AH001GPB,version=ThinkStation: drive with bus=0, unit=0 (index=0) exists
I have no idea what to do, I also checked with ruby that the command I pasted from the post I've linked is actually ASCII, it is correct apparently.
I really need this to work, doesn't even work with a cracked license.
Thank you.
Related
I hope this question makes sense. I have a program that I have compiled in an ubuntu machine that works fine. I cannot do the same in a pc with manjaro. Is it possible somehow "to ship" my working program from the ubunto to the manjaro machine?
Somehow I think that with docker I can do this, but many examples in the web seem pretty involved for my task (which it seems to me it's an easy one... hopefully...).
I posted this question in the Unix Stack Exchange (I did quite some research I must say), valueing options like Remastersys and Respin, Clonezilla, dd, and so on. Now I am in SO because the Google-Coral Tag might be helpful. I have found in here a few posts related to backing up using dd (mostly expected from the questions I have seen), but also some errors that are arising to other users.
After getting everything working, I installed several libraries (via apt and via git clone and make install). So now, I would like to have that same system, with the same libraries,in 3 different boards.
My main idea was: The optimal path to follow is to clone the whole system, and instead of installing Mendel in a new board following the tutorial, and then running an install.sh script (that can take some time due to downloading, installing, etc), wouldn't it be easier to just boot up an image but with a Mendel system with my needed libraries? (Making a PRIME SYSTEM, cloning it to distribute it to several boards).
Problems arose as what I found from the already mentioned possible paths (Respin, Clonezilla, etc), seem that won't work on this system in this way. So booting a new Mendel from scratch and backing up the drive with dd seems like a doable option, probably needing to change afterwards some pathings and namings like usernames. If all boards were called the same, it woulnd't be a problem. More like the opposite in my specific case. But names are assigned randomly to avoid collisions with several boards at the same time.
Is there a simple way to install a Mendel system in Google Coral that is a clone of a system from another coral? (Let's call this the PRIME SYSTEM) This would mean the exact same system Google provides, but with specific libraries already installed. Or is the only path to follow to do a normal installation and then a back-up of the PRIME SYSTEM, via dd (or any other that I do not know of?), with proper naming and pathing changes after it is done?
I want to extend the QEMU TCG (tiny code generator) to accept new instructions for the risc-v guest on my x86 machine. However, I have no experience on how the TCG works, so I was wondering if someone can give me some useful pointers on where to start understanding how the TCG works in the QEMU source code?
I know there is a frontend and backend, but I don't really understand where the translation actually happens, and how are the instruction translated.
I also saw the insn32.decode file in target/riscv defining the opcodes for various operators like lui, but I am not sure how that file is used and if it's for the TCG target (ie a risc-v host) or the QEMU guest.
I am looking for something like
QEMU - Code Flow [ Instruction cache and TCG]
but up-to-date with current QEMU version.
Any help is appreciated.
im trying to make v4l2loopback work on my desktop PC (no hardware camera) with mint 19.3, kernel 5.4.0-42-generic x86_64.
I followed the official instructions and compiled from git the v4l2loopback module and everything seem to run correctly, as no error prompted while running the instructions, but when i do ll /dev/v* there's no /dev/videoN entry.
I also tried with the flags exclusive_caps=1 and devices=2 but to no avail.
Any idea what i might be missing or doing wrong?
you need to load the module (e.g. using modprobe) before you can use it.
see also https://github.com/umlaeute/v4l2loopback#run
I want to develop a new feature or change and existing program of the FreeBSD distribution, specifically the user space¹. To do so, I need to make changes to the FreeBSD code base and then compile and test them.²
Doing so on the tree in /usr/src and installing the result on the system seems like a bad idea, given that it requires you to run your development machine on CURRENT, to develop with root privileges and hoses your system if you make a mistake. I suppose there must be a better way and possibly a standard setup FreeBSD developers use.³
What is the recommended workflow to develop the FreeBSD code base?
¹ so considerations specific to kernel development aren't terribly important
² I'm familiar with the process to submit changes after I have developed them
³ I have previously read both the development handbook and the FreeBSD handbook chapter on building the source but neither seem to recommend a specific process.
I am a src committer.
I often start with the lowest release that I intend to back port to (e.g., RELENG_11_3.
I would then do (before or after making changes):
make buildworld
then deploy to a jail directory:
make DESTDIR=/usr/jails/test installworld
This jail directory, as the first responder hinted, can be used with bhyve, but I find it easier to configure a jail or even just use chroot.
I like to configure my jails in /etc/rc.conf instead of /etc/jail.conf:
Example /etc/rc.conf contents:
jail_enable="YES"
jail_list="test"
jail_test_rootdir="/usr/jails/test"
jail_test_hostname="test"
jail_test_devfs_enable="YES"
I can provide more in-depth examples, ones where the jail has a private networking stack so you can SSH into it, for example, but I don't get the sense that a networking stack is important to your testing from the posted question.
You can see the running jail with "jls" and you can enter the running jail with "jexec test bash"
Inside the jail you can test your changes.
When doing this kind of sandboxing, jails work so long as the /usr/src that you built/installed to the jail is from a release that is:
Older than the guest OS, or
In the same STABLE branch as the guest OS, or
At the very least binary-compatible with the guest OS
Situations 1 and 2 are pretty safe, while situation 3 (e.g., running a newer /usr/src than the guest OS) can get dodgy. For example, trying to run /usr/src head (13.0-CURRENT) on a 12.0-RELEASE-pX guest OS where the KBI, KPI, and API can all differ between kernel and userland (with jails, each jail runs under the guest OS's kernel).
If you find that you have to run the newest sources against an older guest OS, then bhyve is definitely the solution. You would take that jail directory and instead of running a jail with that root directory, run a bhyve instance with the jail directory as its root. I don't use bhyve that often, so I can't recall if you first have to deposit the contents inside a disk image and point bhyve at the disk image first -- others and/or Google would know the answer to that.
I'm a ports committer, not a src one, but AFAIK running CURRENT is a common practice amongst developers.
Another way to work is to setup a CURRENT VM, share it over NFS, mount from the host and install into by running make install DESTDIR=/mnt/current. You can use BHyVe for virtualizing, by the way.