I have been developing the OS for a prototype device using hardware. Unfortunately, it's a very manual and buggy process to flash the OS each time and then debug the issues.
I'd like to switch to developing the OS in QEMU, so that I can be sure that the OS is loading correctly before going through the faff of programming the device for real. This will come in handy later for Continuous Integration work.
I have a full copy of the NVM device that is generated from my build process. This is a known working image I'd like to run in QEMU as a start point. This is ready to then be JTAG'd onto the device. The partition layout is:
P0 - loader - Flash of IDBLoader from rockchip loader binaries
P1 - Uboot - Flash of Uboot
P2 - trust - Flash of Trust image for rockchip specific loader
P3 - / - Root partition with Debian based image and packages required for application
P4 - data partition - Application Data
I have not changed anything with the Rockchip partitions (P0 - P2) apart from the serial console settings. When trying to boot the image though, nothing happens. There is no output at all, but the VM shows as still running. I use the following command to run it:
qemu-system-aarch64 -machine virt -cpu cortex-a53 \
-kernel u-boot-nodtb.bin \
-drive format=raw,file=image.img \
-boot c -serial stdio
I have no error information to go on to understand what is going on with it, where can I get more information or debug?
QEMU cannot not emulate arbitrary hardware. You will have to compile U-Boot to match the hardware that QEMU emulates, e.g. using make qemu_arm64_defconfig. The OS must also provide drivers for QEMU's emulated hardware.
If you want to emulate the complete hardware to debug drivers, Renode (https://renode.io/) is a good choice.
For anyone else trying to figure this out, I found good resources here:
https://translatedcode.wordpress.com/2017/07/24/installing-debian-on-qemus-64-bit-arm-virt-board/
and
https://azeria-labs.com/emulate-raspberry-pi-with-qemu/
Looking at the information though, you need to extract the kernel from your image and provide that to the qemu command line as an argument. You'll also need to append an argument telling the system which partition to use as a root drive.
My final command line for starting the machine looks like this:
qemu-system-aarch64 -machine virt -cpu cortex-a53 \
-drive format=raw,file=image.img,id=hd \
-boot c -serial stdio
-kernel <kernelextracted> -append "root=fe04"
Different Arm boards can be significantly different from one another in where they put their hardware, including where they put basic hardware required for bootup (UART, RAM, interrupt controller, etc). It is therefore pretty much expected that if you take a piece of low-level software like u-boot or a Linux kernel that was compiled to run on one board and try to run it on a different one that it will fail to boot. Generally it won't be able to output anything because it won't even have been able to find the UART. (Linux kernels can be compiled to be generic and include drivers for a wider variety of hardware, so if you have that sort of kernel it can be booted on a different board type: it will use a device tree blob, provided either by you or autogenerated by QEMU for the 'virt' board, to figure out what hardware it's running on and adapt to it. But kernels compiled for a specific embedded target are often built with only the device drivers they need, and that kind of kernel can't boot on a different system.)
There are broadly speaking two paths you can take:
(1) build the guest for the board you're emulating (here the 'virt' one). u-boot and Linux both have support for QEMU's 'virt' board. This may or may not be useful for what you're trying to do -- you would be able to test any userspace level code that doesn't care what hardware it runs on, but obviously not anything that's specific to the real hardware you're targeting.
(2) In theory you could add emulation support to QEMU for the hardware you're trying to run on. However this is generally a fair amount of work and isn't trivial if you're not already familiar with QEMU internals. I usually ballpark estimate it as "about as much work as it would take to port the kernel to the hardware"; though it depends a bit on how much functionality you/your guest need to have working, and whether QEMU already has a model of the SoC your hardware is using.
To answer the general "what's the best way to debug a guest image that doesn't boot", the best thing is usually to connect an arm-aware gdb to QEMU's gdbstub. This gives you debug access broadly similar to a JTAG debug connection to real hardware and is probably sufficient to let you find out where the guest is crashing. QEMU also has some debug logging options under the '-d' option, although the logging is partially intended to assist in debugging problems within QEMU itself and can be a bit tricky to interpret.
I am trying to install MySQL on a Windows 10 PC. I downloaded the installer package and followed those steps
Went to https://dev.mysql.com/downloads/windows/
clicked on "MySQL Installer"
Scrolled to Generally Available(GA) Releases section
Clicked on "Windows (x86, 32-bit), MSI Installer" (mysql-installer-community-5.7.21.0.msi) and it started the download.
Once the download was complete, I double clicked on the installer and it gave a usual pop-up for any installation like,"Do you want this app to make changes to your device?" after clicking on "yes" for the answer to this question, it shows "Please wait while Windows configures MySQL-Installer-community" like below screenshot.
And then it keeps showing this installation progress bar for a very long time. Like more than 7-8 hours and the installation never completes
So it seems something is wrong as I don't think MySQL installation needs this long time. I tried to restart my computer and then delete any files related to MySQL from my computer and then started the whole process of installation again. But no luck yet
Anyone has any suggestion on this or did anyone face this kind of issue before? If so, is there a fix or a work around for this?
ok. So finally this is how I resolved my issue. And I found the solution at https://bugs.mysql.com/bug.php?id=82004 . The solution to this problem is to close an open "Windows installer" (the one using 0 memory and CPU) via task manager and the installation should begin running as expected.
Alternative solution: Use an administrator command prompt to run the MySQL installer on Windows 10. Details:
(Note: if you have any problems in the following steps, you can try to restart your computer. Then restart the steps.)
Right-click the Start/Windows icon in the bottom-left corner of Windows.
Click: Windows PowerShell (Admin).
A window asks: Do you want to allow this app to make changes to your device? Click: Yes.
Change to the directory with the MySQL installer. For example, if you downloaded the MySQL installer, type something like:
cd C:\Users\my_username\Downloads\
(Note: To save some typing, you can type a few characters, and then press the tab key, to make Windows show you various auto-completion options.)
Run the MySQL installer. Type something like the following command---make sure to include the period and backslash at the beginning---and press Enter.
.\mysql-installer-community-8.0.11.0.msi
Note: The idea of using an administrator command prompt came from John Geffe, in the link below, which was cited in the answer written by the original poster (user8425592):
https://bugs.mysql.com/bug.php?id=82004
Bug #82004 MySQL Installer freezes during "Please wait while Windows configures..." phase
[6 Feb 3:58] John Geffe
To get past this problem I had to run the .msi installer from an the
Administrator command prompt. Hopefully this helps someone in the
future.
[19 Apr 18:14] Jim McCauley
John Geffe: Thanks! Your note on installing as an administrator seems
to have taken care of the problem.
this did the trick for me: https://ao.ms/mysql-community-server-msi-installer-hangs-on-windows-10/
run cmd (commandline) as Administrator
cd to your location that you downloaded the .MSI to
run the “msiexec” commandline tool with option “/i” as follows:
msiexec /i [replace with file name]
example: msiexec /i mysql-installer-community-5.7.20.0.msi
Another thing that worked for me was running the installer in compatibility mode for previous version of Windows. You can try that as well.
Go to the link you provided (the first one) and try installing MySql Workbench. That is the version that is commonly used, and one that I verified works in Windows 10. Here is the link: https://dev.mysql.com/downloads/workbench/
Obviously, make sure you choose the right architecture, have the correct permissions to install software, and have enough space on your hard drive, or on the machine you are installing to.
Please install "Update for Visual C++ 2013 and Visual C++ Redistributable Package" from Microsoft Site "http://download.microsoft.com/download/0/5/6/056DCDA9-D667-4E27-8001-8A0C6971D6B1/vcredist_x64.exe"
Please look here at https://support.microsoft.com/en-in/help/3179560/update-for-visual-c-2013-and-visual-c-redistributable-package
Yes, I also got the same problem on my Windows 10.
Followed the Powershell solution and it worked.
Just repeat the above:
Click Start on bottom left corner
Scroll down the application list until Windows Powershell
Select Windows Powershell again on sub-menu
Type in cd (to change to your .msi folder)
Type .\xxxxx.msi (this is the installer file name)
All good.
Once you install the above package run the installer again and do the steps. You will be able to install the mysql-installer-community-5.7.21.0 for 64 bit windows 10
closing Windows Installer instances using 0 memory and CPU helps me to get past this problem.
For me on Window-10 machine, there was a problem with the "mysql-connector-net-8.0.11.msi". I was not able to uninstall this and hence all my subsequent efforts to install MySQL were failing. I did the following to overcome this issue.
Re-installed "mysql-connector-net-8.0.11.msi" Get it here and used the 'Repair' option
Installed the "mysql-installer-web-community-8.0.11.0.msi"
These two things solved my problem. Hope this helps.
The reson is your antivirus didn't allow the mysql, so Disable protection(until restart),( in your task bar right side click the arrow and right click to antivirus,to select (Disable protection(until restart)).then restart your computer again install mysql installer it will work.
For this issue just run .msi file in command administration like
E:\mysql-installer-community-8.0.20.0.msi\
follow this link:
https://kb.foxitsoftware.com/hc/en-us/articles/360040660611-How-to-install-MSI-from-command-line-with-administrator
In my case, an upgrade to 5.7.29 on Windows 10 via mysql-installer-web-community-8.0.20.0.msi, the install froze "backing up the database". The log tab showed no activity for 8 minutes. I clicked on cancel, then at the "are you sure" prompt I declined to cancel, and all of a sudden the install was working again. Very strange...
I encountered the same problem, preparing but can never get started. Tried to close other installation programs with no use, but I took the inspiration and proceeded with restart the computer and it worked nicely. So, I think the issue is to get rid of everything that could be in the background running that somehow interferes the installation.
You should run the installer as an administrator but this specific installation may not provide an option for this. Some might have it but it's most likely that it's unavailable for many users. So you should run it in cmd or powershell. And don't forget to run these shells as an administrator coz that's the whole point here. Once there, navigate to the installer's location which usually is in the downloads directory and run it using this command ./name.msi
Make sure no other ongoing installation of this instance. Close it if there exists one and undo the changes made by uninstalling it from the panel. If still facing difficulties, try restarting your machine and repeat this procedure...
Have fun
I had the same Problem, A simple solution is to give access the "SYSTEM" to the msiserver...I know, this is hard to understand what I am saying....You can Simply see this Video and you will definitely find the answer https://www.youtube.com/watch?v=6SdXMjXmnUk, It is a matter of just 3 minutes...
I encountered the same issue of taking too much time to install mysql community installer.I tried 3 times by cancelling the installation and restarting to perform a new installation.But had same issue. I tried 2 things
First to end all tasks associated with installation which I performed for installing mysql using Task Manager
Reinitiated the installation but didn't solved my issue.
Secondly tried to install through Windows Powershell as admin, which solved the problem.
Click on the Windows icon/start on the bottom left corner.
Right click and select the option Windows Powershell (Admin).
A pop up window will ask Do you want to allow this app to make changes to your device?....Click Yes.
Now cd to your downloads folder/wherever you downloaded the .msi file (For example cd C:\Users\MYPC\Downloads).
Once you reach to the folder where the .msi file is kept, run the following command.
.\mysql-installer-web-community-8.0.23.0.msi (Note: this is the version which I have downloaded, modify as your version).
I'm learning how to build a basic OS kernel with https://intermezzos.github.io
I've create my .iso file and I'm at the point where I am runnning qemu-system-x86_64 -cdrom os.iso
When I press enter, QEMU runs a window with the following output:
Booting from Floppy...
Boot failed: could not read the boot disk
Booting from DVD/CD...
Boot failed: Could not read from CDROM (code 0004)
Booting from ROM...
iPXE (PCI 00:03.0) starting execution...ok
iPXE initializing devices...ok
iPXE 1.0.0+git-20131111.c3d1e78-2ubuntu1.1 -- Open Source Network Boot Firmware
-- http://ipxe.org
Features: HTTP HTTPS iSCSI DNS TFTP AoE bzImage ELF MBOOT PXE Menu
net0: 52:54:00:12:34:56 using 82549em on PCI00:03.0 (open)
[Link:up, TX:0 TXE:0 RX:0 RXE:01]
Configuring (net0 52:54:00:12:34:56)...ok
net0: 10.0.2.15/255.255.255.0 gw 10.0.2.2
Nothing to boot: No such file for directory (http://ipxe.org/2d03e13b)
No more network devices
No bootable device.
I went to the website listed in the output (http://ipxe.org/2d03e13b) and one of the tips is that I might Use the iPXE command line to perform DHCP manually, however when I press CTRL + B to access cli, I'm not able to do so.
Where do I look next to troubleshoot this problem of not being able to boot my .iso?
How do I make QEMU have access to keyboard input?
UPDATE
I don't know how, but I'm am now able to use CTRL + B to access iPXE command line.
This seems like a good place to start diagnosing my problem of not being able to boot my .iso.
What am I looking for?
UPDATE 2
Thanks to Peter Maydell's suggestion below, I've tested a known-good iso image (https://alpinelinux.org/), running qemu-system-x86_64 -cdrom alpine-3.4.3-x86_64.iso and it booted perfectly just as I expected.
I've rewritten my files from https://intermezzos.github.io to create a new iso image, this time copy and pasting the code from the repository, just in case I was previously inputting typos.
Still not booting. On to the next clue...
The first thing to do is to check whether this command line and ISO image work on a normal Linux host system. That will tell you whether the problem is (a) the Windows Subsystem for Linux not correctly implementing something QEMU relies on or (b) your ISO image actually not being a bootable CDROM.
You might also try booting a known-good ISO image such as one for a Linux distribution.
(The general principle here is to try to do diagnostic tests to split the space of "what might be the problem" into smaller sections and determine which side your problem is.)
Simple solution to the problem. Has to do with systems that use EFI to boot.
source
I needed to apt-get install grub-pc-bin and then rebuild image.
I have PHPStorm, but when I'm writing native function (for example str_poss, return, parent...) it very often freeze for about 10 seconds. I have no idea what I'm doing wrong. But it happen to me on Windows7 and on Ubuntu also. Has anyone same trouble? Thanks.
PHPStorm used to "lag" for me before quite often too... but I managed to fix it in the following ways (It did take a bit of tweaking/experimenting though to get it to work! But now it is blazing fast once again!)
Here is what I did to optimize it:
1) If you are on Linux - Make sure you are using Oracle Java on your system, not Open JDK
From: https://intellij-support.jetbrains.com/entries/23455956-Selecting-the-JDK-version-the-IDE-will-run-under it says:
On windows: "JDK is bundled with all the product installers and it's recommended that you will use the provided JDK version unless there are any specific issues.
32-bit JDK is located in IDE_HOME\jre directory and is used by the 32-bit product executable.
To run the IDE in 64-bit mode you will need to download and install 64-bit JDK (not JRE) distribution and install it yourself. IDE will find and use it from the registry when you run the 64-bit .exe file (available only for IntelliJ IDEA right now, other products can use the .bat file to run in 64-bit mode)."
2) Disable any plugins you do not ABSOLUTELY NEED! Especially any 3rd party plugins you may have installed**
GBC from PhpStorm 7 very slow and sluggish on netbook, optimize IDE for responsiveness? also had some insties:
3) Disable language injections: File -> Settings -> Language injections. un-check as many boxes as you're comfortable with. HTML was the real killer for me.
4) Disable inspections: File -> Settings -> Inspections. uncheck as many as you don't need.
I hope this helps!
I am on a mounted VM drive and everytime I was going back to PHPStorm it freezes for 5-10 sec.
Unchecked the box "Synchronize files on frame activation", in Settings > General > Synchronization, seems to solve the issue for me.
PHPStorm 7.1 on Linux
A solution I found which drastically increased my speed without having to disable any plugins or disable inspections (because they are useful - why would you want to disable them) was to enable OpenGL.
First of all go to: path-to-phpstorm\bin\PhpStorm64.exe.vmoptions
Then add these two lines below the others:
-Dawt.useSystemAAFontSettings=lcd
-Dawt.java2d.opengl=true
This helped me to get that 'eye' logo disappear and show a green tick on 6000 line file in 3 seconds rather than 2 minutes. Amazing how much difference it made.
If you're using JetBrains Toolbox, go into the Settings beside PhpStorm and crank up the "Maximum heap size". I find about 3000 MB is good.
If you're not using Toolbox, find and open phpstorm64.vmoptions and add this line:
-Xmx3000m
It does the same thing.
I had the same problem on Ubuntu. The IDE was freezing regularly on two different PCs (Using a desktop pc at home and a laptop at work), both have as OS Ubuntu 18. The freezing time was about 1-2 minutes.
It stopped after I restart IDE with VM-option: -Dawt.ime.disabled=true
Source: https://youtrack.jetbrains.com/issue/JBR-1923
I really need someone's help here.
Early, I was playing around with homebrew, macport and active state TCL/TK after I got the new mac pro. But somehow I accidentally deleted the tcl/tclsh folder when I was trying to delete the active state version of tcl.
Now the problem is when I'm trying to install MongoDB with Macport using:
sudo port install mongodb
It give me an error says:
so I guess I delete the wrong file..is there any way I can get it back? I tried install tcl/tk using active state package but didn't work.
Help really needed...!
Thanks
The problem seems to be that you've deleted (at least part of) the system Tcl/Tk pre-installed by Apple.* MacPorts explicitly uses Apple's Tcl (or its own, if you ask it, but not ActiveState's or Homebrew's or any other). That's why it's looking for /usr/bin/tclsh rather than just whatever tclsh is on the PATH.
If you dig inside the Mountain Lion installer package, you may be able to find and run the Tcl/Tk installer manually, but Apple makes that different (and harder) with each release. The easier thing to do is just run the installer and let it repair things for you.
* It's also possible that you first replaced parts of Apple's Tcl with another version, which you shouldn't have done, and then broke that other version. But the solution is the same.