Maragda: Running Linux from CD
These files are created by the scripts on the system working directory and the files found there, starting with the source installation.
Cp_root is in charge of creating ROOT.FS, while Cp_whole will build WHOLE.FS. Both scripts use Make_fs to create file systems inside a file.
ROOT.FS should contain files and directories that need to be written and cannot live on a read-only file system. Writing will be possible since ROOT.FS will reside on a RAM disk. It is difficult to find out exactly what is required to be in ROOT.FS. After several attempts, I decided to copy at least the following directories: bin, sbin, lib (including lib/modules), home, var, etc.
For those directories notcopied, symbolic links are created, pointing to where WHOLE.FS will be mounted once Maragda is running (/mnt/whole_fs).
In addition, binaries and libraries are unstripped (symbols removed) to reduce space.
The configuration files for ROOT.FS are kept under system/config. Once ROOT.FS is populated from the source installation, system/config files are written to ROOT.FS overwriting existing files. Typical system/config files are:
the /home/jordi directory
/etc/X11/X and /etc/X11/XF86Config for configuring X
/etc/hosts* and /etc/sysconfig/network-scripts, for setting up network
/etc/passwd, for users' accounts
/etc/rc.d/init.d/* files, to drive the startup process
Especially important is the script system/config/etc/rc.d/rc.sysinit. It is run by init (in the second-stage boot). I patched it to complete the Maragda system. It adds some lines to Maragda's /etc/fstab to reflect where the CD is and, therefore, where WHOLE.FS is. Remember that this was announced by linuxrc (first-stage boot) on the file /initrd/cdrom_dev. Once fstab is completed, rc.sysinit goes on with the “side effect” that WHOLE.FS will be correctly mounted.
Of course, to test your emerging system, you do not need to record a CD. It can be booted easily by means of LILO, arranging files this way:
/system/MARAGDA /system/ROOT.FS /system/WHOLE.FS /boot/bzImage-rd (the kernel) /boot/1INITRD.GZ (the initial RAM disk for the first stage boot)
(System may be a symbolic link to the working directory.) You should add the following entry to /etc/lilo.conf:
image=/boot/bzImage-rd label=maragda initrd=/boot/1INITRD.GZ literal="ramdisk_size=20480" # size of ROOT.FS read-only vga=0x315and run LILO every time you make any change.
As you have already learned, the source installation is a directory containing a complete, installed Linux system. It can be the source for copying the ROOT.FS and WHOLE.FS files or even for installing Linux onto a hard-disk partition or onto a 250MB zip floppy. The script Prepare_install (under the system working directory) sets up a directory to receive RPM packages. Then, you can use Install_rpm to install those packages onto the source-installation directory.
Install_rpm installs packages from the Red Hat's 6.2 distribution CD (or from another place, if you change it). The names of packages to be installed are grouped in files under system/RPM_lists. For instance, base_inst lists the packages for the base-system installation. I created the listing files starting with the file RedHat/base/comps on the Red Hat CD.
If you install the packages in the right order (as it appears on Install_rpm) they should be installed with no problem. Install_rpm also reports which packages were not installed. In the case of base_inst it creates base_inst_not_installed. This is the only group of rpms that poses a problem. But, if you tell Install_rpm to install packages on base_inst_not_installed, finally all packages will be installed.
You may find all the scripts used on http://navel.eugan.upv.es/maragda/doc, including raw CD images of Maragda (and the instructions to record them).
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- Home Automation with Raspberry Pi
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development
- Purism Librem 13 Review