- 1 Devices Available
- 2 RAID and Logical Volume Manager
- 3 Disk Layout
- 4 Operating System
- 4.1 Scaffolding
- 5 Middleware
- 6 Additional Utilities
Based on the hardware, the following devices are available:
- CD/DVD Burner
/dev/hda (it is in the Primary/Master position on the first EIDE cable, but can be represented on some systems as /dev/cdrom, /dev/dvd, /dev/dvdrw, and /dev/sr0)
- SATA disks
/dev/sda (this is drive 1)
/dev/sdb (this is drive 2)
Note that /dev/sda1, sda2, sda3 and sda4 can be bootable primary partitions. Typically, sda4 is configured as an "extended partition" which allows subsets to be defined as logical partitions sda5, sda6, and so on.
- USB keys or external drives
/dev/sdc for the drive itself /dev/sdc1 (for the VFAT file system usually on it)
Note: depending on when the USB was attached, this could be /dev/sdd1, /dev/sde1 or /dev/sdf1.
- Ethernet Network Interface cards
eth0, eth1 and eth2 seemed to be assigned to the one motherboard connector and two PCI cards differently between operating systems. I will need to track down the MAC addresses to keep them straight.
RAID and Logical Volume Manager
RAID and LVM are supported on most recent Linux distributions and provide some key advantages. However, they can also be difficult to work with and require knowledge in particular commands to handle properly.
Redundant Array of Inexpensive Disks (RAID)
- RAID 0
Stripes data across for better performance. Two 160GB drives would look like a fast 320GB drive, but if you lose any one drive, you have lost everything
- RAID 1
Mirrors the data across drives. Multiple copies means you have better protection, so if you lose any one drive, the rest of the system can still run. Two 160GB drives would look like a single 160GB drive. Performance is the same or slightly slower than a single drive.
- RAID 5
Stripes with parity for added protection. One drive's worth is set aside for parity, so three 160GB drives would hold 320GB of data; four 160GB drives would hold 480GB of data. Since we have only two drives, this option does not apply to us. Performance is faster for read, but can be slower for writes, depending on how the parity methods are implemented.
- RAID 10
Striped and Mirrored. Sometimes referred to as RAID 0+1 or RAID 1+0, this combines RAID 1 with RAID 0. Data is striped across disk 1 and disk 2, disk 3 is a mirror of disk 1 stripe, and disk 4 is mirror of disk 2 stripe. Thus four 160GB drives holds 320GB of data. If you lose any one drive, the mirrored copy is still available, so the system will be able to continue to run. Performance is same or slightly slower than a 2-drive RAID 0 configuration.
This just strings together a bunch of different sized disks sequentially. A 160GB drive, 320GB and 500GB drive could be combined into 980GB.
JBOD stands for "Just a Bunch of Disks", a term meaning there is no RAID for protection or performance improvement. This refers to deployments where each disk drive is independent.
- Can mirror the entire drive ( /dev/sda <--> /dev/sdb ) or individual same-sized partitions ( /dev/sda1 <--> /dev/sdb1 )
- Can mirror swap space. This appears to be preferred best practice over just having swap space on separate disks.
- Mirrored drives appear as:
- Software RAID (/dev/md0, /dev/md1)
- or, Hardware-assisted BIOS "fakeraid" (/dev/dm-0, /dev/dm1) which is not supported on the hardware I have for this project
- In general, a mirrored partition can be used wherever a native partition can be used
- Can be used as physical volumes for Logical Volume Manager
- /boot directory can be on RAID1, but not be on RAID0, RAID5, RAID10 or any other RAID configuration.
RAID rebuild: In the event a disk fails in RAID-1 mode, the single surviving drive can be used to continue operations. When a new replacement drive is available, the following procedures can be used to rebuild.
Place the surviving drive as "drive 1", remove the bad drive from the system.
- boot up
- indicate that drive 2 has failed
Place the new drive as "drive 2"
- boot up
- copy over the disk layout from "drive 1" using "sfdisk" utility
- copy over the MBR from "drive 1" using "dd" utility
- add the new partitions to /dev/md0, /dev/md1, etc. (the data will be copied over)
Logical Volume Manager (LVM2)
Logical Volume Manager allows a level of storage virtualization between the physical hardware and the operating system and applications. There are two formats, LVM (older) and LVM2 (newer). We will use LVM2.
- Physical Volumes
A physical volume (pv) can be an entire disk drive (/dev/sda), partition (/dev/sda1), or RAID mirror (/dev/md0)
- Volume Groups
A volume group (vg) combines the space capacity of one or more physical volumes. A physical volume can only be part of a single volume group. A volume group can host one or more logical volumes.
- Logical Extents
The volume group is divided into fixed-size pieces called "logical extents" or LE. These are typically 32MB in size.
- Logical Volume
A logical volume is a "virtual drive" that appears like a device or partition to the operating system. A logical volume can be the entire space of a single volume group, or a subset of a single volume group. Logical volumes can be increased or decreased in size, and can be moved as needed onto or away from specific physical volumes. A logical volume is one or more logical extents, so the smallest Logical Volume is one LE (typicallly 32MB). A logical extent can only be part of one logical volume.
- A volume group can contain physical volumes of different sizes
- Linux cannot boot from a Logical Volume, this can be solved by having a separate /boot directory that is not part of the Logical Volume, and the rest of root (/) in the logical volume.
- Logical volumes cannot be resized using the "gparted" tool
- Linux swap space can be defined onto logical volume
Most Linux systems only require the following:
- A Master Boot Record (MBR) that contains the boot loader and disk layout
- A root directory (/)
- The root directory can be split up into subdirectories for /boot, /var, /home on separate partitions
- swap space (typically as big or bigger than installed RAM)
Possible Disk Layout configurations
Several disk layouts are possible. Depending on the Operating System installation procedure, you may have to install in JBOD, RAID or LVM, and then migrate to be a full RAID+LVM configuration.
1. Simple JBOD (no RAID, no LVM)
/dev/sda /dev/sdb MBR (boot loader / disk layout ) MBR (disk layout only) /dev/sda1 as /boot /dev/sdb1 for extra space /dev/sda5 as / /dev/sda6 as swap
2. RAID (no LVM)
/dev/sda /dev/sdb MBR1 (boot loader/layout) <-independent-> MBR2 (boot loader/layout) /dev/sda1 as /boot <- /dev/md0 -> /dev/sdb1 /dev/sda5 as / <- /dev/md1 -> /dev/sdb5 /dev/sda6 as swap <- /dev/md2 -> /dev/sdb6
2. LVM (no RAID)
/dev/sda /dev/sdb MBR (boot loader / disk layout ) MBR (disk layout only) /dev/sda1 as /boot /dev/sdb1 as physical volume /dev/sda5 as physical volume where: VolGroup00 --- combines /dev/sda5 and /dev/sdb1 LogVol00 -- as / LogVol01 -- as swap
3. RAID (no LVM)
/dev/sda /dev/sdb MBR1 (boot loader/layout) <-independent-> MBR2 (boot loader/layout) /dev/sda1 as /boot <- /dev/md0 -> /dev/sdb1 /dev/sda5 as / <- /dev/md1 -> /dev/sdb5 /dev/sda6 as swap <- /dev/md2 -> /dev/sdb6
4. RAID and LVM
/dev/sda /dev/sdb MBR1 (boot loader/layout) <-independent-> MBR2 (boot loader/layout) /dev/sda1 as /boot <- /dev/md0 -> /dev/sdb1 /dev/sda5 as physical vol <- /dev/md1 -> /dev/sdb5 where: VolGroup00 --- /dev/md1 LogVol00 -- as / LogVol01 -- as swap
5. RAID and LVM with rescue partition
/dev/sda /dev/sdb MBR1 (boot loader/layout) <-independent-> MBR2 (boot loader/layout) /dev/sda1 as /boot <- /dev/md0 -> /dev/sdb1 /dev/sda2 as /rescue <- /dev/md1 -> /dev/sdb2 /dev/sda5 as physical vol <- /dev/md2 -> /dev/sdb5 where: VolGroup00 --- /dev/md2 LogVol00 -- as / LogVol01 -- as swap
6. RAID and LVM with rescue and scratch partitions
/dev/sda /dev/sdb MBR1 (boot loader/layout) <-independent-> MBR2 (boot loader/layout) /dev/sda1 as /boot <- /dev/md0 -> /dev/sdb1 /dev/sda1 as /rescue <- /dev/md1 -> /dev/sdb2 /dev/sda3 as /scratch1 <-independent-> /dev/sdb3 as /scratch2 /dev/sda5 as swap <-independent-> /dev/sdb5 /dev/sda6 as physical vol <- /dev/md2 -> /dev/sdb6 /dev/sda7 as physical vol <- /dev/md3 -> /dev/sdb6 where: VolGroup00 --- combine /dev/md2 and /dev/md3 LogVol00 -- as / LogVol01 -- as swap
The following sizes can be used:
- boot -- 680 MB
This could fit on a single CD for recovery purposes. /boot will contain /boot/grub boot loader, and can contain alternative kernels to select from during the boot process. Most OS only need 100MB, so this should be plenty.
- rescue -- 4GB
This would be enough to have a basic operating system with software utilities, and include manuals, ISO images of CDs, and so on. This could fit on a single DVD or several CDs for recovery purposes.
- scratch -- 30GB each
This can be used to download ISO files, store "partimage" backups, and so on. These are not RAID protected, so if you lose a disk drive, these files will not be mirrored on the other drive.
- swap -- 2GB
This can be swap during the initial installs.
- base1, base2, base3 -- rest of the disk (40GB of so each)
This will be the /dev/sda4 extended partition carved into smaller logical partitions that can be defined as physical volumes or RAID-1 mirrored pairs.
Initial Drive Format
For some reason, with fresh disks that have no format or partition, most 32-bit LiveCD were unable to boot. To solve this, I booted a 64-bit AMD64-based LiveCD (Fedora 8 in my case), created the partitions and then could use a 32-bit LiveCD for the rest of the install.
[[ http://sysresccd.org/Main_Page | SysRescCD 1.0.3 ]] is also capable of booting in either 64-bit or 32-bit mode, use "boot: rescue64" to boot into 64-bit mode. If you received the disk drive from someone else, and are concerned about remnants of any past data or operating systems, you can use the following command to clobber all data with random data. At 35 MB/sec, this would take about 90 minutes for each 160GB drive.
dd if=/dev/urandom of=/dev/sda
Boot from the "SysRescCD" and use "fdisk" to configure /dev/sda. The final layout should look something like this:
Disk /dev/sda: 160.0 GB, 160041885696 bytes 255 heads, 63 sectors/track, 19457 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x000a0a65 _ _ Device Boot Start End Blocks Id System /dev/sda1 * 1 80 642568+ 83 Linux /dev/sda2 81 581 4024282+ 83 Linux /dev/sda4 4230 19457 122318910 5 Extended /dev/sda5 4230 4497 2152678+ 82 Linux swap / Solaris
Note that all of the partitions are of type "83" (native Linux) except /dev/sda5 which is type "82" (Linux swap).
The team wants to develop and test the EduBlog software on a variety of platforms. The operating systems considered were:
- XS School Server
We're using the XS-163 (the latest level at this time). This is a customized version of Fedora 7 with special settings to run as a school server. The CD runs unattended, works when there is only a single SATA drive installed, and wipes away any previous partition table to form a new partition table.
- Fedora 7
The XS School Server is based on Fedora 7, so if we are unable to get the XS installation kickstart file to support the disk layout, we felt a backup plan was to install Fedora 7 natively. Fedora 7 could also be used graphically by Glen on premises to help with problem determination.
- Debian 4.0-r3 Etch
Ceibal (OLPC Uruguay) has chosen to use Debian 4.0-r3 Etch instead for their projects. It was a stretch goal to see if we could set up a "dual-boot" or "multi-boot" environment that would support XS-Debian, Fedora-Debian, or XS-Fedora-Debian configurations.
- System Rescue
While not a complete Operating System to run EduBlog or perform development work, we might need to have an independent OS for administration or maintenance. Many utilities work best on data that is not currently active in use. This could be done with a LiveCD or as a separate partition on the disk drive.
[[ http://sysresccd.org/Main_Page | SysRescCD 1.0.3 ]] supports sshd so that with the right network setup, someone could effect software repairs remotely. It has a variety of utilities, including "partimage" that can be used to backup individual partitions or logical volumes. Installing on hard disk is a matter of copying just seven files over to /sysrcd directory on a primary or mirrored partition, but not in a Logical Volume. "GRUB" as the boot loader can be updated to run this at reboot.
A simple technique to build a complicated configuration is known as "scaffolding", borrowing from the concept of building a large house, apartment or office structure.
Here is the basic sequence:
- Prepare the first OS (XS-163 School Server)
- Prepare the second OS (Fedora 7)
- Prepare the third OS (Debian 4 Etch)
- Re-define partition tables with no LVM2 or RAID
- Assemble the individual OS images into a "multi-boot" environment
- Connect the second SATA drive
- Create RAID pairs of each partition you want protected
- Devine LVM2 pv, vg and lv and move data into the appropriate logical volume
This will show you how to prepare partition images for each OS you want. This involves wiping the system clean, installing the OS when only one single drive is attached, and then backing the appropriate files to external media using "partimage" utility.
Step 1. Wipe the System clean
For each OS, wipe the system clean. The following command will zero out the first cylinder of your hard disk eliminating the master boot record and partition table.
[root ~]# dd if=/dev/zero of=/dev/sda bs=512 count=16
Step 2. Install from CD
Run the installation from CD. The XS-163 will carve up the disk as follows:
/dev/sda1 /boot -- 100MB /dev/sda2 / -- (root) 8GB (8192MB) /dev/sda5 pv -- physical volume for LVM2, rest of disk VolGroup00 -- volume group on physical volume LogVol00 /library LogVol01 swap
If you are installing Fedora 7, Debian 4, etc. wipe out all partitions, and choose "create custom setup" and define the following simple setup. The rest of the drive capacity will be unused, but it is important to make the initial /(root) directory as small as possible.
/dev/sda1 /boot -- 200MB /dev/sda2 / -- (root) 8GB (8192MB) /dev/sda3 swap
Step 3. Capture initial list of application packages
Before you change anything or install any packages, do the following, which will document all of the base RPM packages on your XS163 or Fedora 7 system. That way you can compare any new packages that were installed afterwards and see the differences using diff command. For Debian 4, use the apt-get utility instead.
[root ~]# cd /root [root ~]# mkdir /boot/details [root ~]# rpm -qa | sort > /boot/details/rpm-xs163.txt
Step 4. Create partition images
We will now backup this OS image. These partition images will then be used to re-assemble the final system. We can use this procedure for Backup-and-Restore-Using-SysRescueCD.
Here is what you end up with:
For each OS you will have:
- master.mbr -- this is the Master Boot Record (first 446 bytes of each disk)
- sfdisk-d.txt -- this is the disk layout, human-and-computer readable
- grubmenu.txt -- this has the initial boot parameters (/boot/grub/menu.lst --> grub.conf)
- etcfstab.txt -- this is the list of mount points (/etc/fstab file)
- sda1boot.img.000 -- this is partition image of the /boot directory
- sda2base.img.000 -- this is first piece of the partition image of the / (root) directory
- sda2base.img.001 -- (the files are 692MB each, small enough so they can be burned onto CDrom, uploaded to an FTP site, sent over using "yousendit.com", or fit on a FAT32 file system.)
Re-Define the Partion Tables
We'll choose a configuration similar to the left half of "6. RAID and LVM with rescue and scratch partitions" list above in the section Possible_Disk_Layout_configurations.
/dev/sda MBR1 (boot loader/layout) /dev/sda1 as /boot /dev/sda1 as /rescue (/ for Debian 4) /dev/sda3 as /scratch1 /dev/sda4 as extended partition holding sda5..sda10 _ /dev/sda5 as / (for fedora 7) /dev/sda6 as / (for XS 163) /dev/sda7 as swap /dev/sda8 as physical vol /dev/sda9 as physical vol /dev/sda10 as physical vol
The /boot will contain the kernel images of all the operating systems, as well as the multi-boot /boot/grub directory. This will allow you to choose the different OS from a menu.
I chose 4GB to hold a set of rescue files, and then later decided to install Debian 4, it fits in 4GB! I create three equal-sized 10GB partitions, one for scratch (temp) space, one for the root directory of Fedora 7, and one for root directory of XS 163 School Server. Finally, I divided the rest of the volume into three 40GB pieces which can be used for physical volumes of an LVM Volume Group.
Here is what the start/end cylinder counts look like using "sfdisk -l /dev/sda":
Disk /dev/sda: 19457 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 _ Device Boot Start End #cyls #blocks Id System /dev/sda1 * 0+ 79 80- 642568+ 83 Linux /dev/sda2 80 638 559 4490167+ 83 Linux /dev/sda3 639 1839 1201 9647032+ 83 Linux /dev/sda4 1840 19456 17617 141508552+ 5 Extended /dev/sda5 1840+ 3040 1201- 9647001 83 Linux /dev/sda6 3041+ 4241 1201- 9647001 83 Linux /dev/sda7 4242+ 4498 257- 2064321 82 Linux swap / Solaris /dev/sda8 4499+ 9484 4986- 40050013+ 8e Linux LVM /dev/sda9 9485+ 14470 4986- 40050013+ 8e Linux LVM /dev/sda10 14471+ 19456 4986- 40050013+ 8e Linux LVM
Since there is so much work setting this up, it might be good to save it to a file. This can be done using the following command:
[root ~]# sfdisk -d /dev/sda > sfdisk-d.txt
This is what the file looks like. Not that "size" is counting in terms of 512 byte sectors. So /dev/sda1 is 512 * 1285137 or 657990144 bytes (658 MB).
# partition table of /dev/sda unit: sectors /dev/sda1 : start= 63, size= 1285137, Id=83, bootable /dev/sda2 : start= 1285200, size= 8980335, Id=83 /dev/sda3 : start= 10265535, size= 19294065, Id=83 /dev/sda4 : start= 29559600, size=283017105, Id= 5 /dev/sda5 : start= 29559663, size= 19294002, Id=83 /dev/sda6 : start= 48853728, size= 19294002, Id=83 /dev/sda7 : start= 68147793, size= 4128642, Id=82 /dev/sda8 : start= 72276498, size= 80100027, Id=8e /dev/sda9 : start=152376588, size= 80100027, Id=8e /dev/sda10: start=232476678, size= 80100027, Id=8e
To restore, just change the ">" (send to) into "<" (read from) character. You can cut and paste the above and try it yourself. Note, this will clobber any previous partition table and all data may be lost.
[root ~]# sfdisk -d /dev/sda < sfdisk-d.txt
Assemble the Images into multi-boot
All three of the Linux operating systems support the "GRUB" boot loader. Of these, I liked the graphics on Fedora 7, so I will choose to use that as the base.
Let's boot from the SysRescueCD 1.0.3 CD. I have all my partition images on an external USB drive, but this can work with CD or DVD as well.
Step 1. Restore Fedora 7
We will use sda1 for /boot, and sda5 for / (root). Use partimage to restore each partition. Note that if you have several in a series, you just need to specify the *.000 version, and it will pick up the others automatically.
[root ~]# mount /dev/sdc1 /mnt/backup [root ~]# cd /mnt/backup/fedora7 [root fedora7]# dd if=master.mbr of=/dev/sda bs=446 count=1 [root fedora7]# partimage -e -b restore /dev/sda1 sda1_boot.img.000 [root fedora7]# partimage -e -b restore /dev/sda5 sda2_base.img.000
We will need to edit a few files. As a precaution, I always make a bacukp copy (*.bak) of any file that I am editing with "vi", in case I type something wrong and accidently save it.
[root ~]# cd /mnt/backup/fedora7 [root fedora7]# mkdir /mnt/fedora [root fedora7]# mount /dev/sda5 /mnt/fedora [root fedora7]# mount /dev/sda1 /mnt/fedora/boot [root fedora7]# cd /mnt/fedora/boot/grub [root grub]# cp menu.lst menu.bak [root grub]# vi menu.lst [root grub]# cd /mnt/fedora/etc [root etc]# cp fstab fstab.bak [root etc]# vi /mnt/fedora/etc/fstab [root etc]# cp mtab mtab.bak [root etc]# vi /mnt/fedora/etc/mtab
For menu.lst (which is just a symbolic link to grub.conf, by the way), I changed the following:
- timeout value to "15" seconds
- put a "#" in front of "hiddenmenu" (so that I could see the menu)
- changed to "root=/dev/sda5"
- added "panic=30" (optional)
- If you get a kernel panic, it probably means there is a mismatch between menu.lst, fstab or mtab files. Make sure you change all three before rebooting your system. The "panic=30" allows the system to reboot after 30 seconds of a kernel panic, giving you enough time to insert your rescue CD to fix the problem.
- Without "panic=30" the kernel panic will just sit there, and you then have to press the power button for 5 seconds to shut the system down, then hit the power button again, and then on
my system I have to hit "f1" to confirm that my system was turned off in that manner, or "Del" to go into the BIOS setup program.
- Added "# 0-Fedora" as a comment to remind me that "default=0" will select it.(optional)
Note that the default=0 means that the first stanza will be selected if you do nothing for the timeout value (15 seconds). On the menu, you will see the 15 seconds count down to 0, and the default highlighted. Your file will look something like this:
# /boot/grub/menu.lst --> grub.conf generated by anaconda #boot=/dev/sda # default=0 timeout=15 splashimage=(hd0,0)/grub/splash.xpm.gz #hiddenmenu # 0-Fedora7 title Fedora 7 Core (2.6.21-1.3194.fc7) root (hd0,0) kernel /vmlinuz-2.6.21-1.3194.fc7 ro root=/dev/sda5 panic=30 initrd /initrd-2.6.21-1.3194.fc7.img
The /etc/fstab file will look something like this. sda5, sda1, and sda7 are the root, boot, and swap locations. If you have anything that says LABEL= change it to the appropriate /dev/sda* device.
# /etc/fstab /dev/sda5 / ext3 defaults 1 1 /dev/sda1 /boot ext3 defaults 1 2 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /dev/sda7 swap swap defaults 0 0
The /etc/mtab might also need to be updated to match the fstab.
Since we moved the root directory location, we may want to re-install grub. This will refresh the appropriate files into /mnt/fedora/boot/grub (which is actually on /dev/sda1), but will not over-write any menu.lst, grub.conf, or spash.xpm.gz files you already have.
[root fedora7]# mkdir /mnt/fedora [root fedora7]# mount /dev/sda5 /mnt/fedora [root fedora7]# mount /dev/sda1 /mnt/fedora/boot [root fedora7]# grub-install --root-directory=/mnt/fedora --no-floppy
We can now unmount the USB drive, use "sync" to make sure the USB drive can be detached, and reboot with no CD in the CD tray.
[root fedora7]# cd /root [root ~]# umount /mnt/fedora [root ~]# sync [root ~]# eject [root ~]# reboot
If all goes well, you should have a running Fedora system again.
Step 2. Restore Debian
For the second OS, we cannot restore "/boot" over the existing one, so we redirect this to /dev/sda3 which is our scratch space.
[root ~]# mount /dev/sdc1 /mnt/backup [root debian4]# cd /mnt/backup/debian4 [root debian4]# partimage -e -b restore /dev/sda3 sda1_boot.img.000 [root debian4]# partimage -e -b restore /dev/sda2 sda2_base.img.000
Now we need to copy parts of the sratch space over into the /boot directory. The easiest way I have found to do this is to use "vi" on two files, position your cursor on the stanza you want to carry over from scratch, "5yy" will put those five lines in memory, "Esc:n" will switch to the next file, and then position the cursor to where you want, and use "p" to paste from memory.
[root ~]# cd /mnt/backup/debian4 [root debian4]# mkdir /mnt/debian /mnt/scratch [root debian4]# mount /dev/sda5 /mnt/debian [root debian4]# mount /dev/sda3 /mnt/debian/boot [root debian4]# mount /dev/sda1 /mnt/scratch [root debian4]# cd /mnt/debian/boot/grub [root grub]# cp menu.lst menu.bak [root grub]# vi /mnt/scratch/menu.lst menu.lst
You're merged menu.lst will look something like this. Note that the kernel levels are different, and that the Debian stanza has "root=/dev/sda2" instead of what Fedora has.
# /boot/grub/menu.lst --> grub.conf generated by anaconda #boot=/dev/sda # default=0 timeout=15 splashimage=(hd0,0)/grub/splash.xpm.gz #hiddenmenu # 0-Fedora7 title Fedora 7 Core (2.6.21-1.3194.fc7) root (hd0,0) kernel /vmlinuz-2.6.21-1.3194.fc7 ro root=/dev/sda5 panic=30 initrd /initrd-2.6.21-1.3194.fc7.img # 1-Debian4 title Debian GNU/Linux, kernel 2.6.18-6-486 root (hd0,0) kernel /vmlinuz-2.6.18-6-486 root=/dev/sda2 ro panic=30 initrd /initrd.img-2.6.18-6-486
You will also have to edit the fstab and mtab files, as we did for Fedora. The /boot will be /dev/sda1, the / (root) will be /dev/sda2, and the swap is /dev/sda7. Reboot and make sure that you can launch either operating system successfully.
Step 3. Restore XS163 School Server
We can add as many operating systems as we like using this approach. For XS163, we will only restore the /boot and /(root) directories. We will reuse /dev/sda3 as scratch space, and restore the root directory into /dev/sda6. We can restore or re-create the /library partition later.
[root ~]# mount /dev/sdc1 /mnt/backup [root ~]# cd /mnt/backup/xs163 [root xs163]# partimage -e -b restore /dev/sda3 sda1_boot.img.000 [root xs163]# partimage -e -b restore /dev/sda6 sda2_base.img.000
Carry over the stanza to the existing /boot/grub/menu.lst, so that you now will have three stanzas in your menu.list, #0-Fedora, #1-Debian, and #2-XS163. Here is the stanza for the XS school server (XS-163 level).
# 2-XS163 title XS163 School Server (220.127.116.11-21.fc7) root (hd0,0) kernel /vmlinuz-18.104.22.168-21.fc7 ro root=/dev/sda6 panic=30 initrd /initrd-22.214.171.124-21.fc7.img
Edit /etc/fstab, and /etc/mtab as we did with fedora and debian above.