SystemRescueCd provides several network configuration boot options so that the network interfaces are already configured when the SystemRescueCd boot process is complete. These options allows both dynamic IP configuration (using dodhcp) and static IP configuration (using ethx=ipaddr/cidr, gateway=ipaddr, dns=ipaddr).

With the ethx=ipaddr/cidr option, all the ethernet interfaces of the computer are configured with the same IP address. It’s a good thing for normals desktops connected to a simple LAN. In deed, you may not know which interface will be seen first (eth0) and which one will be the secondary ones (eth1, …). With the ethx=ipaddr/cidr option it does not matter and you can just plug one of these interfaces with a cable.

Anyway on servers connected to several networks the ethx option is not powerful enough. That’s why specific intefaces configuration options have been added in SystemRescueCd-1.0.2-beta5. Now you can use options such as eth0=192.168.10.1/24 eth1=192.168.20.1. That way each network interface will be configured with its own IP address.

You can even mix the generic ethx and the specific eth0/eth1/eth2/… boot options. For instance if you boot with “rescuecd ethx=192.168.10.1/24 eth3=10.211.34.1/16” then eth3 will have its own IP address and all the other interfaces will use the generic 192.168.10.1 IP address.

SystemRescueCd-1.0.2-beta7 introduces the Vnc server. Now the tightvnc package is compiled with the server support. It means a Vnc server can be started on SystemRescueCd so that you can graphical applications (such as GParted) from another computer (the vnc client).

It means you have the ability use the graphical environment remotely. All the programs will be executed on the computer running SystemRescueCd, and the user is working on another computer. There are VNC client for most platforms (Linux, Solaris, Windows, MacOsX, …).

To use this new feature, you can either configure and run the vnc service by hand, or use the new “vncserver=x:password” option (x is the number of displays you want). The password must be between 5 and 8 characters, else the boot option is ignored.

Don’t forget that your network must be configured so that you can connect to your VNC server. You can use either the “dhdhcp” option for dynamic configuration, or “ethx=ipaddr/cidr“, “eth0=ipaddr/cidr“, “eth1=ipaddr/cidr“, …, “gateway=ipaddr/cidr” for static network configuration.

Here are two examples:

• if you start with rescuecd vncserver=2:MyPaSsWd ethx=192.168.124.10 then SystemRescueCd will configure the ethernet interfaces with the static IP address given and start the VNC server. Two VNC displays will be configured (display 0 and display 1). Both are using the same password when you authenticate. By default, the VNC servers listen on the port tcp/5900+displaynr. So in that case the VNC server will listen on both tcp/5900 (display 0) and tcp/5901 (display 1). Since you have two displays, two users can connect to two different graphical sessions using such commands: “vncviewer 192.168.124.10:0” and “vncviewer 192.168.124.10:1“.
• if you just want one vnc session, you just need one display. You can just use rescuecd vncserver=1:MyPaSsWd ethx=192.168.124.10 and you will be able to connect with “vncviewer 192.168.124.10:0“.

SystemRescueCd was ported to unicode (thanks to Melkor for his help). Since SystemRescueCd-1.0.2-beta4, all programs are compiled with the USE=”unicode” that is used by gentoo portage to compile the software. The new default locale is en_US.utf8. It must not be a problem to use special characters in the console under both bash and zsh. Midnight-Commander (mc) is also able to display filenames and file contents with special characters.

About the graphical environment: Unfortunately mrxvt has not been ported to unicode. This is the default terminal application in SystemRescueCd, since it comes with multiple tabs. Since there is no other multi-tabs terminal that does not requires either gnome-libs or kdelibs, we decided to keep it, and mrxvt is started with the LANG=en_US environment variable. The rxvt-unicode terminal (the gentoo package name is x11-terms/rxvt-unicode-8.3) has been added so that a terminal that supports unicode is available.

If you are using script based on an iso8859-1 text file (the old default) you will have to convert your files to unicode using iconv:
iconv -f iso88591 -t utf8 oldfile > newfile

The recent 1.0.1-beta versions are now based on unionfs. The root filesystem of the livecd is the union of two filesystems: first it shows the contents of the read-only squash filesystem stored in sysrcd.dat that contains all the programs. The second filesystem is a writeable tmpfs filesystem that allows to you to store changes. This switch to unionfs gives the users the ability to edit all the files of the root filesystem of the livecd at runtime. It also saves some memory.

To know why it’s an improvement it’s necessary to understand how it worked before. Until SystemRescueCd-1.0.0, the root filesystems was made of two kinds of directories. Most the directories that store programs (/bin, /lib, /usr, /sbin, /opt, …). These read-only directories were just links to subdirectories of /mnt/livecd that is where the squash filesystem is mounted. Thus all these directories were read-only, and it was not possible to add a file or to change anything. The other directories had to be read-write: /root, /etc, /var. Since it was necessary to let the user write in these directories, they were copied into ram at boot time. For instance the /var/lib/clamav directory stores the clamav antivirus definition files. Since these files may be updated they had to be stored in memory and about 10MB were wasted when the users don’t need it.

Now all the files of the livecd can be edited, removed, changed at runtime. This means it’s easier to make simple changes on the livecd at runtime. For instance it lets you edit a script in the system for debugging purposes. You can also install your own scripts or programs at runtime on the livecd. When a file is not changed by the user, it does not use any memory. Thus the clamav virus definition files will not use memory until the user runs the freshclam program that downloads a newer version from the official website. So the unionfs saves memory.

The Xvesa X server has been added to SystemRescueCd-1.0.0. This tiny X server aims to provide a graphical environment when Xorg does not work on a machine because the driver does not work or for any other reason.

In older versions (until SystemRescueCd-0.4.4-beta12), the only thing you could do when startx fails was to boot with the doxdetect or forcevesa boot options enabled. Now you can run use Xvesa as an alternative X server when Xorg fails to start.

Xvesa is a generic X server for Linux on the x86 platform. Xvesa doesn’t know about any particular hardware, and sets the video mode by running the video BIOS in VM86 mode. Xvesa can use both standard VGA BIOS modes and any modes advertised by a VESA BIOS if available. So it should work on any i386 computer running a 32bits kernel.

Of course, since Xvesa is a generic X server, it will not provide a good hardware support, so there will be no hardware acceleration, and you may not have the best video resolutions. So keep in mind Xorg is still the best choice, and use Xvesa only when Xorg fails to start.

Anyway it seems Xvesa does not work when a 64bits kernel is running (rescue64 or altker64). But it does not really matter: you can use the 32bits kernels (rescuecd or altker32) on an amd64/em64t hardware.

To choose which X server to use, you just have to run the wizard command from to console (type wizard and press enter). A menu will show up, and give you three choices:

• run Xorg with its hardware autodetection (it will use the mkxf86config detection if you used the doxdetect boot option)
• run Xvesa with the default display configuration
• run Xvesa using the configuration (resolution and colors level) that you have to select in the list

So you can just type wizard instead of startx when you want to go to the graphical environment.

It’s very important that you don’t boot with the vga=xxx option, else the console will be unusable after you exit from Xvesa. For instance, there will be a problem if you boot with rescuecd vga=5 setkmap=uk.

The most popular way of using SystemRescueCd is from a CDRom drive on a desktop in interactive mode. Recent SystemRescueCd versions also come with the support for network boot via PXE. The network configuration boot options (such as ethx=ip, gateway=ip, dns=ip, dochdp) allow you to automatically configure the network access to SystemRescueCd at boot time. SystemRescueCd automatically starts an ssh server by default and you can define a static root password on the boot command line. That way you can get an ssh console to the server just by booting a customized SystemRescueCd. There is no need to configure anything to get it to work. It can be very useful for Disaster Recovery purposes, I mean to reinstall a backup of your operating system after a crash. You can also use it to make any other administration task on your server.

In other words, you can manage a windows/linux server that is in a datacenter remotely, from your office. There is no need to be in front of the machine to insert a disc, configure a network interface, or set a root password. All you have to do is to prepare a network boot server (one or several servers running the following network services: dhcpd, tftpd, httpd). You can install these three services either on a dedicated physical/vmware server or on a production machine running other services.

There are two interesting ways of using it:

• You can prepare a pxe boot server so that you get an interactive ssh console to administrate/repair your server by hand. You can prefer the serial console that is also supported.
• You can also configure SystemRescueCd in order to run your own autorun scripts to perform automatic tasks (backup, recovery, …)

If you are interested in managing remote machines using SystemRescueCd, you should read the new chapter about it: Manage remote windows/linux servers using SystemRescueCd

Since SystemRescueCd-0.3.0, it was required to have at least an i686 CPU (Pentium-Pro processor or newer) to be able to run SystemRescueCd. This was because the glibc on gentoo required i686 to compile. So SystemRescueCd-0.2.19 was the last version that supports old processors (between i386 and i686).

The support for old x86 32bits processors has been reintroduced in SystemRescueCd-1.0.0. An user reported in the forums that there was no problem anymore with the glibc-2.7 in gentoo, so I recompiled all the packages for i486. And it worked.

So if you want to use SystemRescueCd on a computer using a processor older than i686 (or with a smaller instruction set) you will have to download SystemRescueCd-1.0.0-rc1 or newer.

PXE network booting was a major feature added to SystemRescueCd-0.4.0. To get it to work, you need three network services:

1. dhcp server that sends a dynamic IP address and some parameters
2. tftp server that sends the bootloader and the kernel + ramdisk
3. http server that sends the compressed root filesystem (sysrcd.dat)

Some users complained because three different services were necessary to have a working PXE boot server. Since SystemRescueCd-1.0.0-rc1 it’s possible to download the root filesystem through TFTP. That way you only need two services:

1. dhcp server that sends a dynamic IP address and some parameters
2. tftp server that sends the bootloader and the kernel + ramdisk and the root filesystem (sysrcd.dat)

Anyway it seems that HTTP is faster, and we are sure that the network packets cannot be damaged because it’s based on TCP that is reliable. TFTP is based on UDP.

To switch from http to tftp, you just have to use boottftp=tftp://srvip/path/sysrcd.dat instead of boothttp=http://srvip/path/sysrcd.dat

Be careful, the sysrcd.md5 file must be available at the same place on the TFTP server (eg: tftp://srvip/path/sysrcd.md5)

Autorun has been rewritten in SystemRescueCd-1.0.0 (0.4.4-beta4 and newer). Autorun is the feature that allow you to execute your own scripts when sysresccd starts. The scripts can be copied in sysresccd by doing an customized version. They can also be copied from a partition on your harddisk / usb-key or downloaded from an NFS / SMB server. The new version also let you run scripts located on an HTTP server.

For example, by asking autorun to execute a script located on a web server, you can run an automatic backup of your system. All you have to do is to develop the backup script, make it available on an internal http server like apache, and start systemrescuecd using autorun.

Previously the autorun (implemented in /sbin/autorun) was developed in bash shell, and it was able to execute scripts from the cdrom, the hard disk, or from an nfs/smb file server. The new autorun has been written in python and it also let you execute scripts from a web server. You may read the official autorun chapter in the handbook for more details.

Here is how to use autorun with scripts located on a http server:

• install your script on a web server (eg: http://192.168.1.1/admin/autorun)
• ensure sysresccd has the right automatic network boot options (such as ethx/gateway/dns or dodhcp)
• boot sysresccd with the ar_source=http://192.168.1.1/admin/ boot option.

It’s also important to notice the nfs/smb syntax changed:

• old nfs syntax: ar_source=nfs-srv:/path/to/dir
• new nfs syntax:ar_source=nfs://nfs-srv:/path/to/dir

• old smb syntax: ar_source=//smb-srv:/path/to/dir
• new smb syntax:ar_source=smb://smb-srv:/path/to/dir

Version 1.0.0 will introduce new autorun options:

• ar_ignorefail: continue to execute the scripts chain even if a script failed (returned a non-zero status)
• ar_nodel: do not delete the temporary copy of the autorun scripts located in /var/autorun/tmp after execution
• ar_disable: completely disable autorun, the simple ‘autorun’ script will not be executed

SystemRescueCd-1.0.0 comes with the support of the GPT disklabels (Guid Partition Table). The GPT disklabel is the new generation disklabel that aims to replace the very old msdos disklabel created with the first PCs. The GPT table is the default system on computer with EFI bios such as macintel and on itanium. Anyway you can use the GPT table on your disks on standards PCs (x86 and x86-64).

One limitation of the msdos disklabel is that is supports only 4 primary partitions (sda1 to sda4). The logical volumes (sda5, sda6, …) are just a workaround to have more than 4 partitions on an harddisk since it’s implemented on a linked listed on your disk (if a link is broke, you can lose all the other logical volumes). The msdos disklabels is not able to support disks larger that 2 Tera-bytes (2048 GB). It’s a real issue on servers with a large storage capacity.

The GPT table supports very large disks beyond 2 TB, and the partitions table is not limited to four primary partitions anymore. Of course you can also use GPT on small hard disks.

To use GPT with linux you need:

• A linux kernel with the GPT support (option CONFIG_EFI_PARTITION set to yes)
• A boot loader that supports GPT (grub-0.97 needs a patch)
• Disk tools that supports GPT (GNU-Parted and GParted support it)

The GPT support was already turned on in the kernel, but now SystemRescueCd comes with a patched grub-0.97, so that you can create a new disklabel, create the partitions, copy a linux system, and reinstall the grub boot loader. So you can use the grub files provided on SystemRescueCd in the /lib/grub directory.

If the installation program of your favorite linux distribution don’t let you choose GPT as a disklabel, you can install this distribution somewhere else, copy all the files using tar/gzip and reinstall the grub boot-loader by hand.

Here is how to install the patched grub-0.97 for GPT using SystemRescueCd:

• boot on SystemRescueCd-1.0.0-rc1 or more recent
• type mkdir /mnt/boot
• mount your boot partition (or the / partition of boot is not on a dedicated partition) on /mnt/boot
• copy your kernel to /mnt/boot/vmlinuz-xxxx
• mkdir -p /mnt/boot/grub
• cp /lib/grub/i386-pc/* /mnt/boot/grub/
• edit /mnt/boot/grub/grub.conf
• ln -s grub.conf /mnt/boot/grub/menu.lst
• umount /mnt/boot
• run grub from the shell
• use the grub root and setup commands to reinstall it:
  • root (hd0,0) or the grub name of the partition with the grub files (usually /boot)
  • setup (hd0) or (hd1) to install the boot loader on the second hard disk

Here is a screenshot of GParted with a small GPT hard disk with 6 partitions: