User:Az990tony/edublog-beta-sw
This software stack is based on This Beta Server hardware built for the Educational Blogger Project .
Devices Available
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)
/dev/cdrom (many operating systems use this)
/dev/dvd (and this)
/dev/dvdrw (and this)
- 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/sdf for the drive itself
/dev/sdf1 (for the VFAT file system usually on it)
- 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)
Configurations include:
- 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.
- JBOD
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.
RAID-1 Considerations:
- 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 (/dev/md0, /dev/md1) or (/dev/dm-0, /dev/dm1)
- 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
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.
- 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.
LVM2 Considerations:
- 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
Disk Layout
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 /rescue <- /dev/md0 -> /dev/sdb1 /dev/sda2 as /boot <- /dev/md1 -> /dev/sdb2 /dev/sda3 as /scratch1 <-independent-> /dev/sdb3 as /scratch2 /dev/sda5 as physical vol <- /dev/md2 -> /dev/sdb5 /dev/sda6 as physical vol <- /dev/md3 -> /dev/sdb6 where: VolGroup00 --- combine /dev/md2 and /dev/md3 LogVol00 -- as / LogVol01 -- as swap
Partition Sizes
The following sizes can be used:
- 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.
- 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.
- 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, and later changed to physical volume space for LVM.
- base -- rest of the disk (120GB of so)
This will be the /dev/sda4 extended partition with /dev/sda5 as the extended partition as physical volume for LVM.
Creating the Disk Partition table
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. SystemRescueCD is also capable of booting in either 64-bit or 32-bit mode, use "boot: rescue64" to boot into 64-bit mode.
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/sda3 582 4229 29302560 83 Linux /dev/sda4 4230 19457 122318910 5 Extended /dev/sda5 4230 4497 2152678+ 82 Linux swap / Solaris /dev/sda6 4498 19457 120246493+ 83 Linux
Note that all of the partitions are of type "83" (native Linux) except /dev/sda5 which is type "82" (Linux swap). You will need to "reboot" for these changes to the partition table to take effect.
To save time, you can configure one drive /dev/sda then copy over the configuration to the second drive as follows:
sfdisk -d /dev/sda | sfdisk /dev/sdb --force
Operating System
The team wants to develop and test the EduBlog software on a variety of platforms. The operating systems considered were:
- 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.
- XS School Server
The XS-163 is the latest level. This is a customized version of Fedora 7 with special settings to run as a school server. Getting this installed into a multi-boot environment will require "squashfs surgery" to change the anaconda-ks.cfg kickstart configuration file.
- 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.
Scaffolding
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.
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=16065
Use "fdisk" to create a simple partition layout, something like:
/dev/sda MBR (boot loader / disk layout ) /dev/sda1 as /boot (choose 500MB) /dev/sda2 as / (choose 30GB) /dev/sda3 as swap (choose 2GB)
Format each partition. In this case "-L" sets the file system label, and "-j" indicates "ext3 file system" format. I will call the boot partition "BOOT", the root partition "FEDORA7" and the swap space "SWAP1".
[root ~]# mke2fs -L BOOT -j /dev/sda1 [root ~]# mke2fs -L FEDORA7 -j /dev/sda2 [root ~]# mkswap -L SWAP1 /dev/sda3
Run the installation from CD. Typically, these have interactive options that allow you to keep the existing partitions and use them "as is". Sometimes, an installation CD will blow away the entire drive and build its own, or blow away the entire drive and let you define new partitions. If this happens, try to use partitions similar to the above.
Squashfs Surgery
In the case of the XS School Server, the CD is designed to run in "batch mode" unattended. This may not be what you want. This can be fixed with some minor "squashfs surgery" as follows:
1. Mount the source, in this case the old-XS-163.iso file. If you have the CD itself, you can unmount the physical CD (/media/OLPC_XS_163) and make the iso file using the "dd" command. Listing out the directory shows there are three items, a subdirectory called isolinux, a file called squashfs.img, and a subdirectory called sysroot.
[root ~]# cd /root [root ~]# umount /media/OLPC_XS_163 [root ~]# dd if=/dev/cdrom of=old-xs163.iso bs=2k [root ~]# mkdir /root/ISO [root ~]# mount -t iso9660 -o loop old-XS-163.iso ISO [root ~]# ls ISO isolinux squashfs.img sysroot
2. Unpack the file system "squashfs.img". This shows an os.img file, and another sysroot subdirectory. Note the -d squashfs-root is the default, but I include here for completeness.
[root ~]# cd /root [root ~]# yum install squashfs-tools (* if you have not yet installed it, now you can) [root ~]# modprobe squashfs (* make sure it is loaded into the system) [root ~]# unsquash -d squashfs-root ISO/squashfs.img [root ~]# ls squashfs-root os.img sysroot
3. This is like peeling layers off an onion. We are now going to mount the os.img as a file system in rw=read/write mode so that we can modify it.
[root ~]# cd /root [root ~]# mkdir LIVE [root ~]# mount -o loop,rw squashfs-root/os.img LIVE [root ~]# ls LIVE bin dev fsroot.olpc lib lost+found mnt proc ... boot etc home library media opt root ...
4. Here you can edit files, install or uninstall RPMs, etc., by using the --root parameter. In my case, I just want to edit the kickstart file with one I made using the "kickstart configurator". You may prefer instead just to edit it with your favorite text editor, such as gedit or vi. If you comment out any lines in the anaconda-ks.cfg, make sure the "#" is in column one, and a space exists in column 2 for each line you want ignored.
[root ~]# cd /root [root ~]# rpm -qa --root /root/LIVE | sort > xs-packages.lst [root ~]# cp LIVE/root/anaconda-ks.cfg /root/anaconda-ks.old [root ~]# gedit LIVE/root/anaconda-ks.cfg [root ~]# rm LIVE/root/*.cfg~ [root ~]# cat LIVE/root/anaconda-ks.cfg # Kickstart file for installing a school server # For now, due to anaconda bug #243374 # # Use text mode install interactive text install interactive # lang en_US.UTF-8 # keyboard us skipx # xconfig --startxonboot # Network information network --device eth0 --bootproto dhcp --hostname schoolserver network --device=eth1 --bootproto=static --gateway=192.168.0.1 --ip=192.168.0.77 -- nameserver=216.39.128.2 --netmask=255.255.255.0 --onboot=on network --device=eth2 --bootproto=dhcp --onboot=on # rootpw --iscrypted $1$Bf0Ag93M$weSucLBipI6jTjtolgZE61 firewall --enabled authconfig --enableshadow --enablemd5 # selinux --permissive selinux --disabled timezone --utc America/New_York # bootloader --location=mbr --driveorder=sda --append="rhgb quiet" bootloader --location=none # The following is the partition information you requested # Note that any partitions you deleted are not expressed # here so unless you clear all partitions first, this is # not guaranteed to work # clearpart --linux --drives=sda # part /boot --fstype ext3 --size=100 --ondisk=sda # part / --fstype ext3 --size=8192 --ondisk=sda # part pv.6 --size=0 --grow --ondisk=sda # volgroup VolGroup00 --pesize=32768 pv.6 # logvol /library --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=200000 --grow # logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=2048 clearpart --none
5. When you are done with the edits, unmount LIVE and re-pack the contents. If you have a new-squash.img from a previous run, delete it first. The mksquashfs process can take a while, so now is a good time to get up and stretch or drink some coffee.
[root ~]# cd /root [root ~]# umount LIVE [root ~]# rm new-squash.img [root ~]# mksquashfs squashfs-root new-squash.img
6. We are now going to create a new folder that contains everything we need to burn a new CD. Note that the "/" (slash) after ISO is very important. The exclude says copy all files except this one file, which we will replace with new-squash.img.
[root ~]# cd /root [root ~]# mkdir BUILD [root ~]# rsync -av --exclude='squash.img' ISO/ BUILD [root ~]# cp new-squashfs.img BUILD/squashfs.img
7. Now we generate the "iso" file itself. Note, the mkisofs command must be run from within the BUILD directory. The final character "." is important, and means all files in the BUILD directory are included in the *.iso image. Make sure that the new ISO has the same "CDLABEL" as the original by specifying the "-V" parameter.
[root ~]# cd /root/BUILD
[root ~]# cat isolinux/isolinux.cfg | grep CDLABEL
(root=CDLABEL=OLPC_XS_163 )
[root ~]# mkisofs -R -l -D -b isolinux/isolinux.bin -c isolinux/boot.catalog
-o /root/new-xs163.iso -allow-leading-dots -input-charset default
-no-emul-boot -boot-load-size 4 -boot-info-table -V "OLPC_XS_163"
8. We can test this "iso" file out with QEMU-KVM virtualization first, so that we don't burn any coasters. This step is optional, but can help reduce wasting blank CD media. First, we verify that our CPU has vmx or svm support, it has svm. Next we load the kvm module specific to the processor time, in this case AMD.
[root ~]# cd /root [root ~]# cat /proc/cpuinfo | grep svm flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy misalignsse ts fid vid ttp tm stc 100mhzsteps [root ~]# modprobe kvm-amd [root ~]# qemu-kvm -m 1024 -cdrom new-xs163.iso
9. Finally, we are ready to burn the ISO to a CD. You can use any graphical program, or use the wodim program.