Maragda: Running Linux from CD
There are three things to do:
Prepare a software installation containing all the packages you want on Maragda; we'll call it source installation.
Distribute the source installation between two big files, ROOT.FS and WHOLE.FS; they both should fit inside an ext2 file system.
Develop a boot mechanism in charge of detecting the CD-ROM drive and locating ROOT.FS on it. Then, it should load ROOT.FS as a RAM disk, preparing it to be the root file system, and finally it should leave the boot process to continue on the root file system.
All the necessary pieces that do the work (mainly shell scripts) are arranged into two working directories:
boot: in charge of developing the boot mechanism
system: contains the tools to create ROOT.FS and WHOLE.FS from the source installation
I should mention that, perhaps, some device files (files under /dev) might not be correct due to the copy from an ext2 file system to a CD file system (iso9660). In this case, you should replace those files by the corresponding /dev files from your system.
Now, let's outline the relevant steps in the building process and describe the purpose of each shell script as well as the main configuration files. Minor details are left out of the explanation; if you decide to build your own Maragda-like system, you should consult doc/developer.html on the CD and carefully read each shell script on the working directories.
Figure 1 shows the main steps to be taken in the boot process.
The target here is to create a bootable floppy disk that will be merged into the CD to make it bootable.
The boot loader for setting up the floppy is syslinux. It can boot a Linux system from a DOS-formatted floppy containing a kernel and an initial RAM disk file (compressed) with the root file system inside.
So, we'll need a kernel along with its loadable modules. (Only the kernel is required now.) I will not explain here how to compile a kernel but will only remark that it should support
framebuffer device
CD-ROM (iso9660 file system)
initial RAM disk
loop-back device
(You can find my kernel configuration on doc/developer.html.)
Now we have to build the initial RAM disk (initrd) holding the root file system for the first-stage boot. The easiest way to obtain one is to borrow it from a floppy rescue disk. But, I follow the “do it yourself” philosophy. The directory boot/initrd is a skeleton of the contents of my RAM disk. The script named Init_initrd fills that directory from scratch, copying files from the source installation. It creates directories, copies a subset of dev-files onto initrd/dev and populates initrd/bin. The size of an initrd must be kept small, so you should leave only the essential binaries on initrd/bin. Then you must run Cp_lib; it will copy the libraries on initrd/lib for the binaries you left before.
When you are finished, run Make_initrd_fs_gz. It will create a file (Minix formated), copying to it the files on boot/initrd and then compress it.
Now you have a kernel and an initial RAM disk. Next, you should generate the bootable floppy with syslinux. The syslinux configuration file, SYSLINUX.CFG, is contained in boot/syslinux_boot_floppy-20MB. The line:
append initrd=initrd.gz ramdisk_size=20480 vga=0x315
instructs the boot loader to load the initial RAM disk file on the floppy and passes two parameters to the kernel to inform it of the size of the RAM disk and the framebuffer video mode. The RAM disk size should be customized to the size of the ROOT.FS used.
Finally, the bootable floppy is created by the Write_syslinux_boot_floppy script. It will also extract a raw image of the floppy to be merged onto the CD.
The most relevant file here is boot/initrd/linuxrc (/linuxrc on the initial RAM disk) because this script is executed at boot up. It performs the main tasks intended for this stage:
It searches for the device holding the files:
/MARAGDA /system/ROOT.FS /system/WHOLE.FS
If that is found, it then states which device will be the new root file system:
mount -n /proc /proc -t proc echo 0x101 > /proc/sys/kernel/real-root-dev (0x101 represents /dev/ram1)
It dumps WHOLE.FS on /dev/ram1.
Finally, it writes on cdrom_dev which device the .FS files were found. This file will be consulted during the second-stage boot.
If everything goes okay, the boot process will continue by executing init, already in the new root file system. The old file system (initrd) will remain mounted under /initrd on the new one.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.
Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.
Sponsored by ActiveState
| Speed Up Your Web Site with Varnish | Jun 19, 2013 |
| Non-Linux FOSS: libnotify, OS X Style | Jun 18, 2013 |
| Containers—Not Virtual Machines—Are the Future Cloud | Jun 17, 2013 |
| Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer | Jun 12, 2013 |
| Weechat, Irssi's Little Brother | Jun 11, 2013 |
| One Tail Just Isn't Enough | Jun 07, 2013 |
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?





4 min 43 sec ago
3 hours 35 min ago
6 hours 29 min ago
6 hours 55 min ago
9 hours 23 min ago
9 hours 57 min ago
9 hours 58 min ago
9 hours 58 min ago
10 hours 59 sec ago
10 hours 2 min ago