I installed CentOS 7.6 then installed all things QEMU on my machine. I have a SPARC image I need to bringing up in a VM. I've been using qemu-system-sparc.
$ qemu-system-sparc -m 256 -hda solaris_v2-qemu_v2.2.0.disk -nographic -bios ./openbios-sparc32
This is on a box on which I have Fedora-30 installed.
Can I use qemu-sparc to bring up my Solaris image: solaris_v2-qemu_v2.2.0.disk ?
If so, how?
BTW, qemu-sparc come with (on CentOS 7.6):
$ sudo yum install qemu*
PS> I've tried to install qemu-system-sparc on my CentOS box but ended up in a never-ending whack-a-mole game of dependencies.
After a great deal of web searches, I found this:
QEMU as an userspace emulator
QEMU usually comes in two flavors: qemu-system-* are system emulators
(able to run entire operating systems as seen in the previous
section), while qemu-* are userspace emulators (only able to run
userspace applications).
QEMU as an userspace emulator is thus able to directly execute a SPARC
application, by emulating the syscalls that the application requests.
Among the greatest features of this approach are:
The output of application is directly displayed in the terminal,
Arguments to applications are directly given through the command line,
QEMU returns the return code of applications, etc. QEMU really just
acts as a wrapper around the application, as time or nice do.
The only complicated thing you have to do in this approach is to
compile a cross-toolchain for SPARC, so SPARC programs can be compiled
on the host computer. Such a cross-toolchain can be generated by using
the fabulous crosstool-ng.
So the answer appears to be: no, you CANNOT use qemu-sparc to run your image in a VM.
You need the qemu-system-sparc, wich will "emulate" a sparc system.
qemu-sparc will only emulate the CPU and syscalls, thus a SPARC compiled program (that you can extract from your disk image if needed) will run on non-sparc hosts, while most syscalls be "translated" by qemu into your host syscalls, thus a SPARC program can run on said host. file io, kernel stuff, it mostly get translated and run on your host. Handy for debugging or reverse engineering.
Try:
yum install qemu-kvm
The dependencies are required ofcourse. Not very usefull in your case but you could also compile qemu yourself, maybe the dependencies overlap:
git glib2-devel libfdt-devel pixman-devel zlib-devel
Related
I have some problems trying to test "needs-restarting -r ; echo $?" inside a RedHat distribution. The command works for cases where a reboot is not required, but I have not been able to voluntarily generate the need to reboot in the operating system, which has made it impossible for me to know if the response to the command works. That is to say the output in 1 of the needs-restarting. Do you know of any way to generate the need to reboot in a controlled manner in RedHat?
You can find which packages require a system reboot after the update to Redhat KB. If you can downgrade one of these packages, you can generate reboot required state. But this is not recommended in production systems. glibc and kernel downgrades can cause problems. You can try it at new installed Rhel server after "yum update".
I need to install Concourse(CI/CD) on my Local windows machine
Below process I followed :
Install Bosh on local system.
It was successfully install and while executing command at command prompt
then it show version all "bosh" -- "version 3.0.1-712bfd7-2018-03-13T23:26:43Z".
Try Download the concourse-lite deployment manifest file but it fails it shows below error.
Follow the below link to install Concourse :
https://concoursetutorial.com/ --- section For Windows:
I don't reccomend doing this at all because you'll be swimming so far out of the main stream that you'll find tons of issues and no one is going to care enough to want to fix them.
Even if you didn't find any issues, resources require a linux worker for anything to work so your going to need linux anyways.
I recommend running your db, web and linux worker on linux and then running windows workers as needed.
I have used pp PAR::Packer to build a standalone exe file to run on a Windows machine.
Can somebody explain how to build a Perl script with all the dependent packages from this Windows machine to create a standalone file to be run on a Linux machine?
Generating a binary that runs on a Linux machine starting from a Windows machine is not possible.
You use the pp (from PAR-Packer) command probably quite in the same way as you did in Windows
pp -S -M Some::Module -M Some::Other::Module -o youBinary.bin Script1.pl Script2.pl ScriptN.pl
Things to note:
The -M flag might be necessary because sometimes the automatic finding of dependencies may not work (some of them are loaded dynamically at runtime so it's a bit trial and error until you get the good combination). Take special care when you see warnings like these when executing pp:
Use of runtime loader module Module::Runtime detected. Results of static scanning may be incomplete.
Use of runtime loader module Module::Implementation detected. Results of static scanning may be incomplete.
The posibility to pack several scripts into one binary. You can them create different symbolic links to that binary to execute the different scripts.
When a single input program is specified, the resulting executable will behave identically as that program. However, when multiple programs are packaged, the produced executable will run the one that has the same basename as $0 (i.e. the filename used to invoke it). If nothing matches, it dies with the error "Can't open perl script "$0"
Very convenient from time to time.
Be aware also of creating the binary on a machine with an "older" libc. If you do this on a bleeding edge linux, you will need a bleeding edge linux to run it too, making it less portable.
Note that even if your perl was built with a shared library, the 'Stand-alone executable' above will not need a separate perl5x.dll or libperl.so to function correctly. But even in this case, the underlying system libraries such as libc must be compatible between the host and target machines.
Enjoy your standalone Perl binary.
EDIT
Generating a binary that runs on a Linux machine starting from a Windows machine is not possible.
The Perl Packager scripts says that it can create executable that runs in same OS. Can I use it to create Win32 binary with linux machine? Or what should I use to create Win32 executable binary on linux from my script?
It is not possible to create stand-alone binaries for different platform than what you are currently running on. This is a generally hard problem since you would have to cross-compile all XS modules and perl itself. Not nice.
For example, if you would like to develop an application on Linux and ship it for both Linux/x86 and Win32/x86, it works well to set up a Virtual Machine with a Windows (XP or 2000 or whatever) and a Perl installation. On that machine, use PAR/pp to package your application for Win32.
On what platforms can I run PAR? On what platforms will the resulting executable run?
Win32 (95/98/ME/NT4/2K/XP), FreeBSD, Linux, AIX, Solaris, Darwin and Cygwin.
The resulting executable will run on any platforms that supports the binary format of the generating platform.
I would like for a RHEL6 build machine to construct a RHEL5 compatible rpm using the maven rpm build plugin. I see how to modify the arch (amd64 vs i386) and os.name (linux vs. ...) but not RHEL5 vs. RHEL5.
Your best bet is to create a chroot (or perhaps run a VM or docker image, or use mock) that contains RHEL5 on the RHEL6 host, and use that for building packages.
There are specific ways to configure rpm to use ZLIB rather than XZ, and use MD5 rather than SHA256, as well as to change labeling of RHEL6 vs RHEL5.
There is no one magic switch to achieve building RHEL5 on RHEL6 (without using mock etc isolation) because RHEL5 and RHEL6 are distinct operating systems with different API's and versions which will block success for all but trivial packages.
Let's think about a simple C program compiled in Windows.
I can compile the program on an Intel CPU machine and run it on an AMD CPU one (same operating system). So does it mean that the instruction set of the CPU's are the same?
Why doesn't the same program run on a machine with different OS and the same CPU?
Intel and AMD line of processors in general have a big overlap in the instruction set that they implement (e.g. sometimes one the other invent some new things and there is a gap until the other company catches up) - that is why you can run programs on both architectures. The same is the reason you cannot run it on other CPU architectures - they don't have the same instruction set for starters, but there are many things that are different.
Operating systems also have their differences. For example, when you compile a program under Windows, you generally get an .exe file. That .exe has a format that only Windows understands and is very different from the format used by Linux for example.
Also, the support that OS gives is completely different - Windows has different kernel functions that you can call compared to e.g. OpenBSD. Even on more abstract levels, it's incompatible. E.g. Windows uses drive letters such as C:\, D:\ and so on to mark drives, while e.g. under Linux it's one big filesystem where you mount different partitions, e.g. under /media or so.
There are different attempts, such as Wine and Cygwin, to execute programs from one platform on another. Using Wine, you can execute Windows executables on Linux directly, as it tries to emulate what Windows provides (not everything works, though). Cygwin is a different product - you can run Windows programs that work similarly to GNU programs on Linux, but they need to be specially compiled - just giving you a hint that it's just two worlds.
That is why Java and .NET (with Mono support on Linux) try to bring these two together. When you make a Java application, you should be able to run it on Linux with more or less same code - some things might not be the same, but majority is.
They're the same, or at least your program is using only a common subset.
For your second question, a few common reasons include:
different OSes require different formats of executables
different OSes will typically have different functions for the program to use
different OSes use different ways of invoking what they provide
1) Intel CPUs and AMD CPUs are intentionally produced this way. You can not run
a program compiled for, say, SPARC CPU on, say, an ARM CPU.
2) In theory it can. Say, Linux has this Wine thing to emulate Windows.
Many Windows programs run perfectly on Linux under Wine.