You might get to see the above error while booting your VM’s on VMWare Workstation 9.x on Ubuntu.
This issue might get sorted by adding the following line to .vmx line of the VM.
mks.gl.allowBlacklistedDrivers = TRUE
Read the further discussion on this topic at vmware forum.
If you’re unable to enter the license key for VMWare workstation version 8 or 9 on your Debian/Ubuntu based machines try the following command:
sudo /usr/lib/vmware/bin/vmware-vmx –new-sn
Note: Replace
This should fix the issue.
Web servers can support compression of the websites content on server itself. If web servers such as apache is compiled with mod_deflate and configured to compress static files such as html, js, css, images etc your site would load faster.
To test whether your web server is already having compression feature you can use the following link:
http://www.whatsmyip.org/http-compression-test/
If you don’t find the compression support, request your web host for the same.
RAID1 Drives allow you to have a redundant solution to bring back system with a mirrored drive during disk failures.
Let us look at a disk failure in one of the linux machines.
Run
cat /proc/mdstat
This will show the current raid statistics as as follows:
server1:~# cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 sdb3[1]
4594496 blocks [2/1] [_U]
md1 : active raid1 sdb2[1]
497920 blocks [2/1] [_U]
md0 : active raid1 sdb1[1]
144448 blocks [2/1] [_U]
unused devices:
The current output shows that the primary drive has gone bad (Observe [_U]).
You can further investigate this using mdadm command as follows:
# mdadm --detail /dev/md0
# mdadm -D /dev/md0
The output would confirm the drive which has gone bad.
If your server is unstable, you might think of removing the bad drive and boot it back temporarily from the second drive in place. For this you should ensure that the grub is installed on the second drive as well so that it boots without any trouble. It is a best practice to install the grub on both drives after configuring RAID1. If it is not done, Not an issue, its not too late to configure that before rebooting the machine for disk removal. Even otherwise through rescue mode grub can be installed easily.
To install grub when you’re on working server:
With (Grub v1.x), Goto grub prompt
grub>>
Find existing grub setups using find command
grub>> find /grub/stage1
If you have any you will find
root (hd0,0)
otherwise you will have to continue with the grub setup as follows,
grub>> root(hd0,0)
grub>> setup(hd0)
grub>> root(hd1,0)
grub>> setup(hd1)
The above lines setup grub on MBR of both the drives. Depending on the drives currently available on the machine/status of your raid you can follow the above instrutions to recover the GRUB while troubleshooting RAID1 setup’s.
If you’re on (Grub v2.x) grub-install /dev/sdX (PS: X in /dev/sdX is drive letter. eg: if you want to install grub on first drive ie sda, then change X with a) command should do all the work.
Once you have the grub installed on drive, you can remove the bad drive from the RAID array using mdadm commands.
In our case (from the initial mdstats output), we should mark bad drive as fail and remove it from the RAID array as follows:
mdadm --manage /dev/md0 --fail /dev/sda1
mdadm --manage /dev/md0 --remove /dev/sda1
Repeat this command for other arrays’s too.
Now you’re good to go ahead shutdown the system and remove the drive. If you have a replacement drive, better add it before rebooting and follow the instructions required to rebuild the RAID arrays.
Due to power failure if your Citrix Xen Slave server doesn’t get back online in pool, this might help:
When the Xen environment changes the pool master, If a slave cannot reach the pool master it goes into a failed state. To change this edit pool.conf file (vi /etc/xensource/pool.conf) and changed the pool master IP address from 10.174.XX.XX to 10.174.XX.YY (to the correct new pool master address). The following identifies the changes as represented within the .conf file:
slave:10.174.20.155
to
slave:10.174.20.157
Once the change is complete, run xe-toolstack-restart. The management interfaces should be restarted and as a precaution the server restart should help. On reboot, you will be able to see the slave server joining the pool without any trouble.
Reference: http://forums.citrix.com/thread.jspa?threadID=242210&tstart=30
Use the following command to copy the partition table from sda to sdb.
sfdisk -d /dev/sda | sfdisk -f /dev/sdb
sfdisk -d dumps the partition table on to stdout. This is being piped to sfdisk /dev/sdb with the –force to write it on /dev/sdb.
You can use dd to copy the Master Boot Record (MBR) from one device to another (or to a file). For example, copying the MBR from sda to sdb would be done with
dd if=/dev/sda of=/dev/sdb bs=512 count=1
The flags are
if, input file (either device or ordinary file)
of, output file (either device or ordinary file)
bs, block size in bytes
count, number of blocks to copy.
The MBR contains the partition table for the four primary partitions, so this solution alone will not copy the definition for the extended partitions.
Reference: http://serverfault.com/questions/54797/mirroring-partition-table