FreeBSD: Error adding new user – pw: user ‘mysql’ disappeared during update

Today when I installed mysql5.7 on my new freebsd server, I got below problem:

This issue is not common. And it’s caused by atabases are out of sync.
To fix this issue, just Run

Update ESXi 6.5 to ESXi 6.5.0d

Put the host into maintenance mode, ssh to the host, and then run below command:

Then reboot the host after installation finished:)

Do not rename the only domain controller… And how to fix it if you have already done so..

Even though MS provide the document about how to rename domain controller, the thing is, if you only have one domain controller, the “rename” will break the AD service and you are not able to roll back.

The issue you will get is that after you rename domain controller, the AD DS services are still using the old hostname because you didn’t transfer the FSMO roles from the old name to the new name. And if you want to start any domain management tools you’ll get error said that domain is unavailable. And if you want to change domain controller name back you will get the same error because dc is not available and your renaming will failed too. And this issue won’t happen if your domain get two or more domain controllers.

Ok, how to fix this issue if you have already done so? What we can do now is to update registry and change the computer name back to the old one. Below are the four registry keys you need to update:

HKLM\System\CCS\Control\Computername "Computername"
HKLM\System\CCS\Control\Computername "ActiveComputername"
HKLM\System\CCS\Services\Tcpip\Parameters "Hostname"
HKLM\System\CCS\Services\Tcpip\Parameters "NVHostname"

Vmware NSX for vSphere 6.2.2 bugs — lost network connection

We are using VMware NSX in our production environment for a long time.
And recently we got some problem with NSX, the symptoms is

Some VMs will lose network connection after migrated to another VM;
New firewall rules are not able to apply on some of the VMs.

After engaged VMware, VMware confirmed that it’s a bug in NSX.

VMware assigned about 1.6G heap memory for NSX firewall on each of the ESX hosts. If you applied too much rules or you have too many VMs and you’ll reach the memory limit. Then you’ll get this issue…

Current fix is to upgrade to 6.2.3…

Reading a memory.dmp or other .dmp file

This can be accomplished with 7 easy steps:

Step 1. Obtain and install the debugging tools.

Debugging Tools Windows

All you need to install is the “Install Debugging Tools for Windows as a Standalone Component (from Windows SDK)” and during the install only select “Debugging Tools for Windows”. Everything else is used for more advanced troubleshooting or development, and isn’t needed here. Today I followed the link to “Install Debugging Tools for Windows as a Standalone Component (from Windows SDK)” although for a different OS you may need to follow a different link.

Step 2. From an elevated command prompt navigate to the debugging folder. For me with the latest tools on Windows Server 2012 it was at C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\. You can specify the path during the install.

Step 3. Type the following:

kd –z C:\Windows\memory.dmp (or the path to your .dmp file)

Step 4. Type the following:

.logopen c:\debuglog.txt

Step 5. Type the following:

.sympath srv*c:\symbols*http://msdl.microsoft.com/download/symbols

If you computer can’t connect to internet, you can download the symbols from below link:

https://developer.microsoft.com/en-us/windows/hardware/download-symbols

Step 6. Type the following:

.reload;!analyze -v;r;kv;lmnt;.logclose;q

Step 7. Review the results by opening c:\debuglog.txt in your favorite text editor. Searching for PROCESS_NAME: will show which process had the fault. You can use the process name and other information from the dump to find clues and find answers in a web search. Usually the fault is with a hardware drivers of some sort, but there are many things that can cause crashes so the actual analyzing of the dump may take some research.

Often times a driver update will fix the issue. If the summary information doesn’t offer enough information then you’ll need to dig further into the debugging tools or open a CSS case with Microsoft. The steps above will provide you with a summary mostly-human-readable report from the dump. There is much more information available in the memory dump although it gets exponentially more difficult to track down the details the further you get into windows debugging.

Hopefully these quick steps are helpful for you as you troubleshoot the unwelcome BSOD.