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.

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“.

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

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.

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.

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

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.

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)

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

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: