This system enables you to handover in ssh on the machine and also to check the hardware.
The advantage is that it is not necessary to contact support to schedule an intervention, because with rescue-mode you can run tests when it's best for you, and when it doesn't disturb the use of your server.
If one of the tests fails or shows errors, just log into the manager: Support section and then submit an incident. Simply send the result of your test, for example: server crashed during the cpu test.We will immediately intervene to replace your hardware.
Attention: You must not use the web interface and ssh at the same time. You must not launch a disk check on the web interface and mount the partitions in ssh, this may cause the loss of your data!!
Activate Rescue Mode
Log into your manager v3, dedicated server section, then services, Netboot and select the 'rescue-pro mode'.
If possible soft-reboot your machine (in SSH: /sbin/reboot) and carry out a hard reboot only if you don't have any other choice.
You will then receive an email containing the link and the password that will enable you to access your server in 'rescue' mode.
It may also occur that our technicians have already intervened on your server. If they do not diagnosis a hardware fault on the server, they will launch your server in "rescue" mode in order for you to proceed to the necessary verifications/corrections for its reinstallation.
Once the server is in pro rescue mode you will receive an email containing a link and a password in order you to connect to hardware tests. Here is a overview of this interface:
All problems can not be detected by this interface.
For example irregular reboots etc. Do not hesitate to test it and to consult next the technical assistance that can help you to analyse the server.
You might get the following error in 64 % of the RAM test:
your server hasn't reacted for a least 20 seconds. it is probably down you can try to refresh the pageif the server crashed while doing a cpu test. it is possible that the cpu is faulty.
You can click on ok, it is often due to the fact that the test, which execute around 64% is very long.
Rescue in SSH
To get connected
Get connected in ssh to your machine as usual. The only thing that change is the password. You must use the temporary root pass that is sent to you by email after the rescue mode.
angie@amazone:~$ ssh firstname.lastname@example.org
The authenticity of host '213.186.xx.yy (213.186.xx.yy)' can't be established.
RSA key fingerprint is 02:11:f2:db:ad:42:86:de:f3:10:9a:fa:41:2d:09:77.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '213.186.xx.yy' (RSA) to the list of known hosts.
Now you are connected but your files are not accessible. You must "mount" the file system.
Usually, /dev/xda1 is your root partition (/) and /dev/xda2 corresponds to /home.
Devices are such as:
You can also use devfs.
If you don't know which disk you have, or which is its partition table, use the commands: fdisk ou sfdisk. Here is an example with the command and the response you get:
rescue:~# fdisk -l
Disk /dev/hda 40.0 GB, 40020664320 bytes
255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 1305 10482381 83 Linux
/dev/hda2 1306 4800 28073587+ 83 Linux
/dev/hda3 4801 4865 522112+ 82 Linux swap / Solaris
Disk /dev/sda 8254 MB, 8254390272 bytes
16 heads, 32 sectors/track, 31488 cylinders
Units = cylinders of 512 * 512 = 262144 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 31488 8060912 c W95 FAT32 (LBA)
Here the server is equipped with two devices.
We see /dev/hda with * that shows that it's the bootable disk. Next, we can see the usb key.
To mount / of the server, you just need to:
rescue:~# mount /dev/hda1 /mnt/
/home should be on /dev/hda2. We mount it after / with the command mount /dev/hda2 /mnt/home .
/home is not necessarily on /dev/hda2 and it is possible that your data is in /var, for plesk for example. To be sure of the configuration you can mount / and next cat /mnt/etc/fstab.
This file contains the server partitions when it boots on its hard disk.
Here is an example:
rescue:# cat /mnt/etc/fstab
/dev/hda2 /var ext3 defaults,usrquota,grpquota 1 2
/dev/hda3 swap swap defaults 0 0
/dev/devpts /dev/pts devpts gid=5,mode=620 0 0
/dev/shm /dev/shm tmpfs defaults 0 0
/dev/proc /proc proc defaults 0 0
/dev/sys /sys sysfs defaults 0 0
/dev/hda2 is therefore in that case /var et non /home.
You must then mount: mount /dev/hda2 /mnt/var .
For the RPS that are in nfs, you must type in rescue : mount -a.
The nfs will mount itself.
We can now edit files by using the path /mnt/var/.... for example or also /mnt/etc/lilo.conf , but to be able to do certain things you must be in root on the system that it is installed on the disk and that can not be done in the rescue-mode root.
For these operations you must use the command chroot:
rescue:~# chroot /mnt/
We can see above that after chrooting the command response puts me in the / of the server.
Now I can execute the commands on my system.
Some examples of possibilities in rescue are being edited.
We are going to give a small list of manipulations that are often asked to us.
Exit from the Rescue
After the modifications, we must go back to the manager in order to restore in Boot our usual Boot method.
Once the right kernel is selected and validated, we carry out a soft reboot of the machine.
Broadcast message from root (pts/0) (Tue Apr 12 15:56:17 2005):
The system is going down for reboot NOW!
If you follow some basic administrations commands as explained in the manual DedicatedUsefulInfo, you can at any time hand over on your machine and reduce down-time.