Pocket linux ��� ���

The Pocket Linux Guide Resource Site

Welcome

This site was created to support readers of the Pocket Linux Guide. It has information about the latest version of the Pocket Linux Guide, the mailing list, troubleshooting forum and downloadable diskette images.

News and Announcements

• 21-APR-2005 — Version 3.1 has been released and is available from The Linux Documentation Project web site.
• 03-NOV-2004 — Kernel config files are now available. Thanks goes out to Paolo Andreoni for providing the files.
• 24-SEP-2004 — A troubleshooting forum is available on SourceForge. Post questions, post solutions.
• 05-JUN-2004 — A new mailing list has been set up for people interested in creating an ultra-small version of pocket linux.
• 19-FEB-2004 — Version 2.1 is available from The Linux Documentation Project.
• 05-FEB-2004 — Web hosting has moved to SourceForge.
• 24-FEB-2003 — A Dutch language version is available. Thanks to Ellen Bokhorst for the translation.
• 10-AUG-2003 — Added Rick Stocker’s «Using GRUB as the boot loader» to the Related Projects section.
• 11-MAY-2003 — Diskette images are available for various chapters.
• 08-MAY-2003 — The mailing list is up and running. If you have not subscribed yet, please do so.

Latest Version

Don’t get stuck with outdated information. The Pocket Linux Guide is often being updated to make building the project as smooth as possible. Be sure to obtain the latest version and check the errata for any last minute corrections.

The latest English language version of the guide can be found at The Linux Documentation Project home page. The direct link to the guide is: http://www.tldp.org/guides.html#pocket.

Mailing List

Got questions about Pocket Linux? Need help troubleshooting? A mailing list for discussions involving Pocket Linux is available at: http://ufo.chicago.il.us/cgi-bin/mailman/listinfo/pocket-linux. Please consider subscribing to the list even if you don’t have any questions. The more people who get involved, the better the experience will be for everyone.

Thanks go out to Tastytronic for hosting the list.

Related Projects

Using GRUB as the boot loader in pocket linux. by Rick Stocker
This document is an alternative to Chapter 2 of the 2.1 and earlier versions Pocket Linux Guide, in that GRUB is the bootloader program rather than LILO.

The GNU/Linux System Architect Toolkit. by David Horton
This project builds upon the Pocket Linux Guide and is for readers interested in creating a more full-featured system.

Additional Projects are also available in a less formal, web forum format.

Want to show off your own project? If you have started a project based on what you have learned in the Pocket Linux Guide and it’s on the web, please send me a link. Or you may want to try the easy to use SourceForge forum to post details about your project. Please share your ideas so that everyone can continue learning.

Kernel Configs & Diskette Images

Kernel config files are available courtesy of Paolo Andreoni. There is a minimal config with just the basics and also a more full-featured config file. Both are for the 2.4.x kernel.

Looking for a downloadable image? The idea behind Pocket Linux is to learn by building it yourself. But let’s face it, sometimes we just get stuck. So to help out with those times when the error is very elusive there are some diskette images available below.

These images are from version 2.1 of the guide and have not been updated to the 3.0 version yet.

These images are ready to be written directly to floppy using either the Linux ‘dd’ command or the win32 ‘rawrite’ utility. Do not decompress the .gz images, write them directly to floppy.

Also pay attention to the fact that some web browsers will interpret these files as text. So if you end up with a window full of strange characters, go back and try «right-click, save target as» or the equivilent.

NOTE:
Source code for the programs used on the diskette images is available from the GNU/Linux System Architect project page listed above.

Feedback

Got an idea to improve the Pocket Linux Guide? Please send feedback concerning the guide and the resource site to the mailing list mentioned above.

Hosting services provided by

This web page was created with

Источник

Pocket Linux

Description

Free Download

Pocket Linux is an almost minimal, one floppy linux system designed to quickly convert PC workstation into a secure linux.

Pocket Linux is an almost minimal, one floppy linux system designed to quickly convert PC workstation into secure linux-based workstation using ssh to connect to remote host (other networking clients are also supported).

It supports bootp for determining host IP and other network parameters (there’s also manual configuration possible, but bootp is recommended).

In addition to workstations equipped with a network card (ethernet or arcnet), you can also use Pocket Linux on a PC equipped with a modem. Modem is automatically detected and then PPP connection is made.

The idea came up some time in 1996 or so. The distribution then was not perfect, but still it shown it was a great idea. It wasn’t maintained for about year or so, until I took it up again in the early January 1998. After a complete rebuild Pocket Linux 2.00 was released. It soon gained a huge number of happy users, whose ideas helped its development.

The aim is to provide a small and efficient workstation that autoconfigures as much as possible and lets securely use the network from almost everywhere.

Current version is a nice attempt and future ones will enhance the automation and support for various network equipment and protocols, becoming a total solution. Future plans also include side projects like one floppy router.

In order to understand some of the config options it’s useful to know something about operations that are done during bootup (in order to automatically configure the network). These are, in order (the later attempts are made if the earlier ones don’t set-up the network): — attempt to setup the network using BOOTP — attempt to reuse previous manual configuration — modem detection — attempt to setup modem conection Most of the config options switches these operations on and off.

Main menu

Configuration options

Manual network card configuration

PPP configuration

Because of permanent configuration that is kept on the floppy you should remember to: — don’t write protect the floppy — don’t remove the floppy from the drive (at least during network configuration)

What’s New in This Release:

� bugfixes in netconf reuse code � disk partitions automounting, swap partitions autoactivating � automatic swap file creation � extended support for NFS mountable /usr � PS/2 mouse support � new startup logo

Источник

Pocket linux ��� ���

/phase2-image bs=1k count=4096 bash# gzip -9

/phase2-image —————————————————————————— 3.3.7. Copy the compressed image to diskette Insert the floppy labeled «root disk» into drive fd0. bash# dd if=

/phase2-image.gz of=/dev/fd0 bs=1k —————————————————————————— 3.4. Implementation Successful implementation of this phase is probably the most difficult part of the Pocket Linux Guide. If you need help getting things to work please visit the Pocket Linux Guide Resource Site to browse the troubleshooting forum and subscribe to the mailing list. —————————————————————————— 3.4.1. System startup Follow these steps to boot: * Restart the PC using the boot disk from the previous chapter. * At the grub> prompt, type kernel (fd0)/boot/vmlinuz init=/bin/sh root=/ dev/fd0 load_ramdisk=1 prompt_ramdisk=1 and press Enter. * Type boot at the grub> prompt and press Enter. * Insert the new, compressed root disk when prompted. The screen output should be similar to the following example: GNU GRUB version 0.95 grub> kernel (fd0)/boot/vmlinuz init=/bin/sh root=/dev/fd0 load_ramdisk=1 prompt_ramdisk=1 [Linux-bzImage, setup=0xc00, size=0xce29b] grub> boot Linux version 2.4.26 .. .. [various kernel messages] .. VFS: Insert root floppy disk to be loaded into RAM disk and press ENTER RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 178k freed # _ —————————————————————————— 3.4.2. Verify results If the implementation was successful, this new root disk should behave exactly like the root disk from the previous chapter. The key difference is that this compressed root disk has much more room to grow and we will put this extra space to good use in the next phase of the project. —————————————————————————— 3.4.3. System shutdown Remove the diskette from fd0 and restart the system using CTRL-ALT-DELETE. —————————————————————————— Chapter 4. Some Basic Utilities 4.1. Analysis In the previous chapter it might seem like we did not accomplish very much. A lot of energy was expended redesigning the root disk, but the functionality is basically the same as in the initial prototype phase. The root disk still does not do very much. But we did make significant improvements when it comes to space savings. In this chapter we will put that extra space to good use and start cramming the root disk with as many utilities as it can hold. The first two root disks we built only had shell built-in commands like echo and pwd. This time it would be nice to have some of the commonly used external commands like cat, ls, mkdir, rm and such on the root disk. Keeping this in mind we can define the goals for this phase as follows: * Retain all of the functionality from the previous root disk. * Add some of the commonly used external commands. —————————————————————————— 4.2. Design 4.2.1. Determining Required Commands The first question that might come to mind is, «How do we know which commands are needed?» It is possible to just start with cat and ls then install other commands as we discover a need for them. But this is terribly inefficient. We need a plan or a blueprint to work from. For this we can turn to the Filesystem Hierarchy Standard (FHS) available from [http://www.pathname.com/ fhs/] http://www.pathname.com/fhs/. The FHS dictates which commands should be present on a Linux system and where they should be placed in the directory structure. —————————————————————————— 4.2.2. Locating Source Code The next logical question is, «Now that we know what we need, where do we get the source code?» One way to find the answer to this question is to check the manpages. We can either search the manpages included with one of the popular GNU/Linux distributions or use one of the manpage search engines listed at [http://www.tldp.org/docs.html#man] http://www.tldp.org/docs.html#man. One thing that should tip us off as to where to find the source code for a particular command is the email address listed for reporting bugs. For example the cat manpage lists bug-textutils@gnu.org. From this email address we can deduce that cat is part of the textutils package from [http://gnu.org] GNU. —————————————————————————— 4.2.3. Leveraging FHS So let’s look at the FHS requirements for the /bin directory. The first few commands in the list are cat, chgrp, chmod, chown and cp. We already know that cat is part of GNU’s textutils. Using the next few commands as keywords in a manpage search we discover that we need GNU’s fileutils package for chmod, chgrp, chown and cp. In fact quite a few of the commands in /bin come from GNU’s fileutils. The date command also comes from a GNU package called sh-utils. So a good way to tackle the problem of finding source code might be to group the commands together by package as shown below. * The BASH shell — echo, false, pwd, sh, true * GNU textutils — cat * GNU fileutils — chgrp, chmod, chown, cp, dd, df, ln, ls, mkdir, mknod, mv, rm, rmdir, sync * GNU sh-utils — date, hostname, stty, su, uname These four packages do not contain all of the commands in the /bin directory, but they do represent of over 70% of them. That should be enough to accomplish our goal of adding some of the commonly used external commands. We can worry about the other commands in later phases of the project. —————————————————————————— 4.2.4. Downloading Source Code To fetch the source code we simply need to connect to [ftp://ftp.gnu.org/gnu] GNU’s FTP site and navigate to the appropriate package directory. When we get to the directory for textutils there are several versions available. There is also a note informing us that the package has been renamed to coreutils. The same message about coreutils appears in the fileutils and sh-utils directories as well. So instead of downloading three separate packages we can get everything in one convenient bundle in the coreutils directory. —————————————————————————— 4.3. Construction Rather than copying files directly to the ramdisk, we can make things easier by setting up a staging area. The staging area will give us room to work without worrying about the space constraints of the ramdisk. It will also provide a way to save our work and make it easier to enhance the rootdisk in later phases of the project. The staging procedure will work like this: 1. Create a directory structure as defined in the FHS. 2. Copy in the files from phase 2’s root disk. 3. Build the new package from source code. 4. Install files into the correct FHS directories. 5. Strip the binaries to save space. 6. Check library dependencies. 7. Copy to the whole directory structure to the ramdisk. 8. Compress the ramdisk and write it out to floppy. —————————————————————————— 4.3.1. Create a staging area bash# mkdir

/staging bash# cd

/staging bash# mkdir bin boot dev etc home lib mnt opt proc root sbin tmp usr var bash# mkdir var/log var/run —————————————————————————— 4.3.2. Copy contents of phase 2 rootdisk bash# dd if=

/phase2-image.gz | gunzip -c > /dev/ram7 bash# mount /dev/ram7 /mnt bash# cp -dpR /mnt/*

/staging bash# umount /dev/ram7 bash# rmdir

/staging/lost+found —————————————————————————— 4.3.3. Install binaries from GNU coreutils Download a recent version of coreutils from [ftp://ftp.gnu.org/gnu/coreutils /] ftp://ftp.gnu.org/gnu/coreutils/ bash# cd /usr/src/coreutils-5.2.1 bash# export CC=»gcc -mcpu=i386″ bash# ./configure —host=i386-pc-linux-gnu bash# make bash# cd src bash# cp cat chgrp chmod chown cp date dd df

/staging/bin bash# cp hostname ln ls mkdir mkfifo mknod

/staging/bin bash# cp mv rm rmdir stty su sync uname

/staging/bin —————————————————————————— 4.3.4. Copy additional libraries Check library requirements by using ldd on some of the new binaries. bash# ldd

/staging/bin/cat bash# ldd

/staging/bin/ls bash# ldd

/staging/bin/su bash# ls

/staging/lib Note the differences in the required libraries, as shown by the ldd command, and the libraries present in the staging area, as shown by the ls command, then copy any missing libraries to the staging area. bash# cp /lib/librt.so.1

/staging/lib bash# cp /lib/libpthread.so.0

/staging/lib bash# cp /lib/libcrypt.so.1

/staging/bin/* bash# strip —strip-unneeded

/staging/lib/* —————————————————————————— 4.3.6. Create a compressed root disk image bash# cd / bash# dd if=/dev/zero of=/dev/ram7 bs=1k count=4096 bash# mke2fs -m0 /dev/ram7 4096 bash# mount /dev/ram7 /mnt bash# cp -dpR

/staging/* /mnt bash# umount /dev/ram7 bash# dd if=/dev/ram7 of=

/phase3-image bs=1k count=4096 bash# gzip -9

/phase3-image Note The process for creating the compressed root disk image will change very little throughout the remaining chapters. Writing a small script to handle this function can be a great time saver. —————————————————————————— 4.3.7. Write the root disk image to floppy Insert the diskette labeled «root disk» into drive fd0. bash# dd if=

/phase3-image.gz of=/dev/fd0 bs=1k —————————————————————————— 4.4. Implementation We will need to have a read-write filesystem in order for some of the commands to work. The kernel’s normal behavior is to mount root as read-only, but we can change this using a kernel option. By passing the kernel the rw option before init=/bin/sh we will get a read-write root filesystem. —————————————————————————— 4.4.1. System startup Follow these steps to get the system running. * Boot the PC from using the GRUB boot disk. * At the grub> prompt, type kernel (fd0)/boot/vmlinuz rw init=/bin/sh root= /dev/fd0 load_ramdisk=1 prompt_ramdisk=1. * Verify that you remembered to add the rw parameter and press Enter. * Type boot and press Enter. * Insert the recently created root disk when prompted. The terminal display should look similar to the example below. GNU GRUB version 0.95 grub> kernel (fd0)/boot/vmlinuz rw init=/bin/sh root=/dev/fd0 load_ramdisk=1 prompt_ramdisk=1 [Linux-bzImage, setup=0xc00, size=0xce29b] grub> boot Linux version 2.4.26 .. .. [various kernel messages] .. VFS: Insert root floppy disk to be loaded into RAM disk and press ENTER RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem) read-write. Freeing unused kernel memory: 178k freed # _ —————————————————————————— 4.4.2. Testing new commands Now that the system is up and running, try using some of the new commands. bash# uname -a bash# ls /etc bash# echo «PocketLinux» > /etc/hostname bash# hostname $(cat /etc/hostname) bash# uname -n bash# mkdir /home/stuff bash# cd /home/stuff If everything goes well the commands like cat, ls and hostname should work now. Even mkdir should work since the root filesystem is mounted read-write. Of course since we are using a ramdisk, any changes will be lost once the PC is reset. —————————————————————————— 4.4.3. System shutdown Remove the diskette from fd0 and restart the system using CTRL-ALT-DELETE. —————————————————————————— Chapter 5. Checking and Mounting Disks 5.1. Analysis In the previous chapter we added many new commands by installing coreutils and as a result the root disk has a lot more functionality. But there are still a few things lacking. One thing that really stands out is that there was no way to mount disks. In order to get a read-write root filesystem we had to resort to passing the rw kernel parameter at the grub> prompt. This is fine for an emergency situation, but a normal system boot process should do things differently. Most GNU/Linux distributions take several steps to mount filesystems. Watching the boot process or digging into the startup scripts on one of the popular Linux distributions reveals the following sequence of events: 1. The kernel automatically mounts the root filesystem as read-only. 2. All local filesystems are checked for errors. 3. If filesystems are clean, root is remounted as read-write. 4. The rest of the local filesystems are mounted. 5. Network filesystems are mounted. So far our Pocket Linux system can do step one and that is it. If we want to have a professional looking boot / root diskset we will have to do better than one out of five. In this phase of the project we will work on steps two and three. Steps four and five can wait. Since this is a diskette-based system, there really are no other filesystems to mount besides root. Taking into account all of the above information, the goals for this phase are defined as follows: * A way to check filesystem integrity. * The ability to mount filesystems. * A script to automate checking and mounting of local filesystems. —————————————————————————— 5.2. Design 5.2.1. Determining necessary utilities. We can use the Filesystem Hierarchy Standard (FHS) document to help find the names of utilities we need and where they reside in the directory structure. The FHS /sbin directory lists fsck and something called fsck.* for checking filesystems. Since we are using a Second Extended (ext2) filesystem the fsck. * becomes fsck.ext2 for our purposes. Mounting filesystems is done using the commands mount and umount in the /bin directory. However, the name of a script to automatically mount local filesystems cannot be found. On most systems this type of script is in the /etc directory, but while FHS does list requirements for /etc, it does not currently make recommendations for startup scripts. Several GNU/Linux distributions use /etc/init.d as the place to hold startup scripts so we will put our filesystem mounting script there. —————————————————————————— 5.2.2. Finding source code In the previous chapter we used manpages to help us find source code. In this chapter we will use a tool called the Linux Software Map (LSM). LSM is a database of GNU/Linux software that tracks such things as package name, author, names of binaries that make up the package and download sites. Using an LSM search engine we can locate packages using command names as keywords. If we search Ibiblio’s Linux Software Map (LSM) at [http://www.ibiblio.org/ pub/Linux/] http://www.ibiblio.org/pub/Linux/ for the keyword «fsck» we get a large number of matches. Since we are using a Second Extended filesystem, called ext2 for short, we can refine the search using «ext2» as a keyword. Supplying both keywords to the LSM search engine comes up with a package called e2fsprogs. Looking at the LSM entry for e2fsprogs we find out that this package contains the utilities e2fsck, mke2fs, dumpe2fs, fsck and more. We also find out that the LSM entry for e2fsprogs has not been updated for a while. There is almost certainly a newer version out there somewhere. Another good Internet resource for source code is SourceForge at [http:// sourceforge.net/] http://sourceforge.net/. Using the keyword «e2fsprogs» in the SourceForge search engine results in a much newer version of e2fsprogs. Finding fsck was quite an adventure, but now we can move on to finding mount and umount. A search on LSM comes up with a number of matches, but most of them point to various versions of a package called util-linux. All we have to do is scroll through and pick the most recent release. The LSM entry for util-linux lists a lot of utilities besides just mount and umount. We should definitely scan through the list to see if any of the other util-linux commands show up in the FHS requirements for /bin and /sbin. Below is a list of packages we have gathered so far and the utilities that match up with FHS. * e2fsprogs — fsck, fsck.ext2 (e2fsck), mkfs.ext2 (mke2fs) * util-linux — dmesg, getty (agetty), kill, login, mount, swapon, umount —————————————————————————— 5.2.3. Automating fsck and mount Now that we have fsck and mount commands we need to come up with a shell script to automate checking and mounting the local filesystems. An easy way to do this would be to write a short, two line script that calls fsck and then mount. But, what if the filesystems are not clean? The system should definitely not try to mount a corrupted filesystem. Therefore we need to devise a way of determining the status of the filesystems before mounting them. The manpage for fsck gives some insight into how this can be accomplished using return codes. Basically, if fsck returns a code of zero or one it means the filesystem is okay and a return code of two or greater means some kind of manual intervention is needed. A simple if-then statement could evaluate the fsck return code to determine whether or not the filesystem should be mounted. For help on writing shell scripts we can turn to the BASH (1) manpage and the Advanced-BASH-Scripting-Guide. Both references are freely available from the Linux Documentation Project web site at [http:// www.tldp.org/] http://www.tldp.org/. —————————————————————————— 5.2.4. File dependencies The last thing to do is to figure out if any other files besides the binaries are needed. We learned about using ldd to check for library dependencies in the last phase of the project and we will use it to check the utilities in this phase too. There are also some other files that fsck and mount will need and the fsck(8) and mount(8) manpages give some insight into what those files are. There is /etc/fstab that lists devices and their mount points, /etc/mtab that keeps track of what is mounted, and a number of /dev files that represent the various disks. We will need to include all of these to have everything work right. —————————————————————————— 5.2.4.1. /etc/fstab The /etc/fstab file is just a simple text file that can be created with any editor. We will need an entry for the root filesystem and for the proc filesystem. Information about the format of this file can be found in the fstab(5) manpage or by looking at the /etc/fstab file on any of the popular GNU/Linux distributions. —————————————————————————— 5.2.4.2. /etc/mtab The /etc/mtab file presents a unique challenge, because it does not contain static information like fstab. The mtab file tracks mounted filesystems and therefore its contents change from time to time. We are particularly interested in the state of mtab when the system first starts up, before any filesystems are mounted. At this point /etc/mtab should be empty so we will need to configure a startup script to create an empty /etc/mtab before any filesystems are mounted. But it is not possible to create any files in the / etc directory because / is read-only at startup. This creates a paradox. We cannot create an empty mtab, because the / filesystem is not mounted as writable and we should not mount any filesystems until we have created an empty mtab. In order to sidestep this problem we need to do the following: 1. Remount / as read-write, but use the -n option so that mount does not attempt to write an entry to /etc/mtab which is read-only at this point. 2. Create an empty /etc/mtab file now that the filesystem is writable. 3. Remount / as read-write again, this time using the -f option so that an entry is written into /etc/mtab, but / is not actually mounted a second time. —————————————————————————— 5.2.4.3. Device files The only thing left to do is to create device files. We will need /dev/ram0, because that is where the root filesystem is located. We also need /dev/fd0 to mount other floppy disks and /dev/null for use by some of the system commands. —————————————————————————— 5.3. Construction 5.3.1. Install utilities from e2fsprogs Download the e2fsprogs source code package from [http://sourceforge.net/ projects/e2fsprogs/] http://sourceforge.net/projects/e2fsprogs/ bash# cd /usr/src/e2fsprogs-1.35 bash# export CC=»gcc -mcpu=i386″ bash# ./configure —host=i386-pc-linux-gnu bash# make bash# cd e2fsck bash# cp e2fsck.shared

/staging/sbin/e2fsck bash# ln -s e2fsck

/staging/sbin/fsck.ext2 bash# cd ../misc bash# cp fsck mke2fs

/staging/sbin bash# ln -s mke2fs

/staging/sbin/mkfs.ext2 —————————————————————————— 5.3.2. Install utilities from util-linux Get the latest util-linux source from [ftp://ftp.win.tue.nl/pub/linux-local/ utils/util-linux/] ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux/ bash# cd /usr/src/util-linux-2.12h Use a text editor to make the following changes to MCONFIG: * Change «CPU=$(shell uname -m)» to «CPU=i386» * Change «HAVE_SHADOW=yes» to «HAVE_SHADOW=no» bash# ./configure bash# make bash# cp disk-utils/mkfs

/staging/sbin bash# cp fdisk/fdisk

/staging/sbin bash# cp login-utils/agetty

/staging/sbin bash# ln -s agetty

/staging/sbin/getty bash# cp login-utils/login

/staging/bin bash# cp misc-utils/kill

/staging/bin bash# cp mount/mount

/staging/bin bash# cp mount/umount

/staging/bin bash# cp mount/swapon

/staging/sbin bash# cp sys-utils/dmesg

/staging/bin/* | more bash# ldd

/staging/sbin/* | more bash# ls

/staging/lib All of the dependencies revealed by the ldd command are for libraries already present in the staging area so there is no need to copy anything new. —————————————————————————— 5.3.4. Strip binaries to save space bash# strip

/staging/bin/* bash# strip

/staging/dev/ram0 b 1 0 bash# mknod

/staging/dev/fd0 b 2 0 bash# mknod

/staging/etc Use an editor like vi, emacs or pico to create the following file and save it as

/staging/etc/fstab. proc /proc proc defaults 0 0 /dev/ram0 / ext2 defaults 1 1 Create an empty mtab file. bash# echo -n >mtab —————————————————————————— 5.3.7. Write a script to check and mount local filesystems Use an editor to create the following shell script and save it as

/staging/ etc/init.d/local_fs: #!/bin/sh # # local_fs — check and mount local filesystems # PATH=/sbin:/bin ; export PATH fsck -ATCp if [ $? -gt 1 ]; then echo «Filesystem errors still exist! Manual intervention required.» /bin/sh else echo «Remounting / as read-write.» mount -n -o remount,rw / echo -n >/etc/mtab mount -f -o remount,rw / echo «Mounting local filesystems.» mount -a -t nonfs,nosmbfs fi # # end of local_fs Set execute permissions on the script. bash# chmod +x local_fs —————————————————————————— 5.3.8. Create a compressed root disk image bash# cd / bash# dd if=/dev/zero of=/dev/ram7 bs=1k count=4096 bash# mke2fs -m0 /dev/ram7 4096 bash# mount /dev/ram7 /mnt bash# cp -dpR

/staging/* /mnt bash# umount /dev/ram7 bash# dd if=/dev/ram7 of=

/phase4-image bs=1k count=4096 bash# gzip -9

/phase4-image —————————————————————————— 5.3.9. Write the root disk image to floppy Insert the diskette labeled «root disk» into drive fd0. bash# dd if=

/phase4-image.gz of=/dev/fd0 bs=1k —————————————————————————— 5.4. Implementation 5.4.1. System startup Start the system using the following procedure: * Boot the PC using the floppy labeled «boot disk». * At the grub> prompt, type the usual kernel and boot commands, but without the rw parameter this time. In other words, type kernel (fd0)/boot/ vmlinuz init=/bin/sh root=/dev/fd0 load_ramdisk=1 prompt_ramdisk=1, press Enter then type boot and press Enter. * Put in the recently created root disk when prompted. The output should resemble the example below: GNU GRUB version 0.95 grub> kernel (fd0)/boot/vmlinuz init=/bin/sh root=/dev/fd0 load_ramdisk=1 prompt_ramdisk=1 [Linux-bzImage, setup=0xc00, size=0xce29b] grub> boot Linux version 2.4.26 .. .. [various kernel messages] .. VFS: Insert root floppy disk to be loaded into RAM disk and press ENTER RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 178k freed # _ —————————————————————————— 5.4.2. Test the local_fs script Run the script by typing the following commands at the shell prompt: bash# PATH=/sbin:/bin:/etc/init.d ; export PATH bash# cat /etc/mtab bash# local_fs bash# cat /etc/mtab bash# df If everything is working properly, then the screen output should look something like the example below. bash# PATH=/sbin:/bin:/etc/init.d ; export PATH bash# cat /etc/mtab bash# local_fs /dev/ram0: clean 74/1024 files 3178/4096 blocks Remounting / as read-write. Mounting local filesystems. bash# cat /etc/mtab /dev/ram0 / ext2 rw 0 0 proc /proc proc rw 0 0 bash# df Filesystem 1k-blocks Used Available Use% Mounted on /dev/ram0 3963 3045 918 77% / —————————————————————————— 5.4.3. Create and mount additional filesystems Procure a blank floppy disk and label it as «home». Remove the root disk floppy and insert the «home» diskette. Type the following commands: bash# mkfs -t ext2 /dev/fd0 bash# fsck /dev/fd0 bash# mount /dev/fd0 /home bash# mkdir /home/floyd bash# cd /home/floyd bash# echo «Goodbye cruel world.» > goodbye.txt bash# cat goodbye.txt —————————————————————————— 5.4.4. System shutdown bash# cd / bash# umount /home Remove the diskette from fd0 and restart the system using CTRL-ALT-DELETE. —————————————————————————— Chapter 6. Automating Startup & Shutdown 6.1. Analysis The root disk from the last chapter is looking pretty good. It has about seventy percent of the commands that the Filesystem Hierarchy Standard (FHS) document requires for the root filesystem. Plus it has commands for checking and mounting filesystems. But even with all of this the root disk is far from perfect. The list below outlines three things that could use some improvement if the Pocket Linux system is to stand up next to the more professional looking distributions. 1. The system currently requires the kernel parameters to be typed at the grub> prompt in order to start properly. On any other GNU/Linux system this is only done in an emergency situation when the system is corrupted. 2. Checking and mounting the root filesystem has to be done manually by running a script at a shell prompt. On most modern operating systems this function is handled automatically as part of the system start-up process. 3. Using CTRL-ALT-DELETE for system shutdown is not very graceful. Filesystems should be unmounted and cached information should be flushed prior to shutdown. Again, this is something that most operating systems handle automatically. Taking the above list into consideration, the goals for this phase are defined as follows: * Kernel loads without manual intervention. * Automated system start-up sequence. * Graceful shutdown capability. —————————————————————————— 6.2. Design 6.2.1. Determining necessary utilities Loading the kernel without manually typing parameters is easy to do if we read the grub info page. According to the section entitled «configuration» all of the commands used for booting can be put in a file called menu.lst and placed in the /boot/grub directory. Note Be sure to type the menu.lst filename correctly with a lowercase L after the dot and not a number one. To automate system start-up we will need an init daemon. We know this because the Bootdisk-HOWTO and From-Powerup-To-BASH-Prompt-HOWTO both make mention of init as the first program to start after the kernel loads. The latter HOWTO also goes into some detail about the /etc/inittab file and the organization of startup scripts. This could be helpful since FHS, the blueprint we have used so far, makes no recommendation for init scripts. We will also need to find the shutdown command to fulfill the second goal of graceful shutdown capability. —————————————————————————— 6.2.2. Obtaining source code Searching the Linux Software Map on Ibiblio for the keyword «init» gives a large number of results. From reading the From-Powerup-To-BASH-Prompt-HOWTO however, we know that most Linux systems use a System V style init daemon. Narrowing the search with the additional key phrase of «System V» gives much better results. The sysvinit package contains init, shutdown, halt and reboot which is everything we need. The version listed in the LSM entry looks to be pretty old, but there is a primary-site URL that will probably lead to the latest version. —————————————————————————— 6.2.3. Checking dependencies The manpage for init mentions a FIFO called /dev/initctl that is required for init to communicate with other programs in the sysvinit package. We will have to create this file for init to function properly. —————————————————————————— 6.2.4. Designing a simple GRUB configuration file. Using a GRUB configuration file is slightly more complex than specifying the bootloader commands manually. There are directives for features like menus, default selections and timeouts that need to be specified in the configuration file as well as the familiar kernel loading command. The info page for GRUB gives much of the necessary information. We may also be able to use the GRUB configuration file on the development system as a template. However, there is some inconsistency between vendors as to the name and location of the file. Regardless of what the path is on the development system it should be /boot/grub/menu.lst on the Pocket Linux System. —————————————————————————— 6.2.5. Outlining start-up scripts Many of the popular GNU/Linux distributions use System V style init scripts. Since we are using a «sysvinit» daemon it makes sense to use System V style scripts as well. The following documents all touch upon the System V style init scripts in some way and will serve as references when building the scripts for this project: * The Debian Policy Manual — available online at [http://www.debian.org/ doc/debian-policy] http://www.debian.org/doc/debian-policy. * The Linux Standard Base specification — downloadable in many formats from [http://www.linuxbase.org/spec/index.shtml] http://www.linuxbase.org /spec/index.shtml. * Essential System Administration, 3rd Edition by Aeleen Frisch — available at libraries, bookstores or directly from O’Reilly Publishing at [http://www.oreilly.com/] http://www.oreilly.com/. After glancing at one or two of the above references we should have a pretty good idea of how the System V style system initialization process works. We should also know what it takes to create System V style init scripts for the Pocket Linux project. Below is a brief list of what needs to be done: * Create an inittab file to call an rc script with a numerical argument giving the runlevel. * Write an rc script that uses the runlevel argument to execute the appropriate «K» and «S» scripts. * Modify the previously built local_fs script to take start and stop arguments. * Create new scripts for shutdown and reboot. * Set up /etc/rcN.d directories and links to scripts in /etc/init.d. As always, the BASH(1) manpage and the Advanced BASH Scripting Guide are very helpful for writing and understanding shell scripts. —————————————————————————— 6.3. Construction There is a lot of typing to do in this section because of all of the start-up scripts that need to be created. Using a mouse to copy the text from this guide and paste it into a text editor can be a great time saving tool. —————————————————————————— 6.3.1. Create a GRUB configuration file Insert and mount the floppy labeled «boot disk». bash# mount /dev/fd0 /mnt bash# cd /mnt/boot/grub Use your favorite text editor to create the following file and save it as / mnt/boot/grub/menu.lst: default 0 timeout 3 title Pocket Linux Boot Disk kernel (fd0)/boot/vmlinuz root=/dev/fd0 load_ramdisk=1 prompt_ramdisk=1 —————————————————————————— 6.3.2. Install sysvinit utilities Download the latest sysvinit source from [ftp://ftp.cistron.nl/pub/people/ miquels/software/] ftp://ftp.cistron.nl/pub/people/miquels/software/ bash# cd /usr/src/sysvinit-2.85/src bash# make CC=»gcc -mcpu=i386″ bash# cp halt init shutdown

/staging/sbin bash# ln -s halt

/staging/sbin/reboot bash# ln -s init

/staging/sbin/telinit bash# mknod

/staging/dev/initctl p Note In the interest of speed we are skipping the steps for checking libraries and stripping binaries. The library requirements for sysvinit are very basic and the Makefile is configured to automatically strip the binaries. —————————————————————————— 6.3.3. Create /etc/inittab file Use a text editor to create the following file and save it as

/staging/etc/ inittab # /etc/inittab — init daemon configuration file # # Default runlevel id:1:initdefault: # # System initialization si:S:sysinit:/etc/init.d/rc S # # Runlevel scripts r0:0:wait:/etc/init.d/rc 0 r1:1:respawn:/bin/sh r2:2:wait:/etc/init.d/rc 2 r3:3:wait:/etc/init.d/rc 3 r4:4:wait:/etc/init.d/rc 4 r5:5:wait:/etc/init.d/rc 5 r6:6:wait:/etc/init.d/rc 6 # # end of /etc/inittab —————————————————————————— 6.3.4. Create /etc/init.d/rc script Use a text editor to create the following file and save it as

/staging/etc/ init.d/rc #!/bin/sh # # /etc/init.d/rc — runlevel change script # PATH=/sbin:/bin SCRIPT_DIR=»/etc/rc$1.d» # # Check that the rcN.d directory really exists. if [ -d $SCRIPT_DIR ]; then # # Execute the kill scripts first. for SCRIPT in $SCRIPT_DIR/K*; do if [ -x $SCRIPT ]; then $SCRIPT stop; fi; done; # # Do the Start scripts last. for SCRIPT in $SCRIPT_DIR/S*; do if [ -x $SCRIPT ]; then $SCRIPT start; fi; done; fi # # end of /etc/init.d/rc Make the file executable. bash# chmod +x

/staging/etc/init.d/rc —————————————————————————— 6.3.5. Modify /etc/init.d/local_fs script A case statement is added to allow the script to either mount or unmount local filesystems depending on the command-line argument given. The original script is contained inside the «start» portion of the case statement. The «stop» portion is new. #!/bin/sh # # local_fs — check and mount local filesystems # PATH=/sbin:/bin ; export PATH case $1 in start) echo «Checking local filesystem integrity.» fsck -ATCp if [ $? -gt 1 ]; then echo «Filesystem errors still exist! Manual intervention required.» /bin/sh else echo «Remounting / as read-write.» mount -n -o remount,rw / echo -n > /etc/mtab mount -f -o remount,rw / echo «Mounting local filesystems.» mount -a -t nonfs,smbfs fi ;; stop) echo «Unmounting local filesystems.» umount -a -r ;; *) echo «usage: $0 start|stop»; ;; esac # # end of local_fs —————————————————————————— 6.3.6. Create a hostname script Use a text editor to create the following script and save it as

/staging/etc /init.d/hostname #!/bin/sh # # hostname — set the system name to the name stored in /etc/hostname # PATH=/sbin:/bin ; export PATH echo «Setting hostname.» if [ -f /etc/hostname ]; then hostname $(cat /etc/hostname) else hostname gnu-linux fi # # end of hostname —————————————————————————— 6.3.7. Create halt & reboot scripts Use a text editor to create

/staging/etc/init.d/halt as shown below. #!/bin/sh # # halt — halt the system # PATH=/sbin:/bin ; export PATH echo «Initiating system halt.» halt # # end of /etc/init.d/halt Create the following script and save it as

/staging/etc/init.d/reboot #!/bin/sh # # reboot — reboot the system # PATH=/sbin:/bin ; export PATH echo «Initiating system reboot.» reboot # # end of /etc/init.d/reboot Flag all script files as executable. bash# chmod +x

/staging/etc bash# mkdir rc0.d rc1.d rc2.d rc3.d rc4.d rc5.d rc6.d rcS.d bash# cd

/staging/etc/rcS.d bash# ln -s ../init.d/local_fs S20local_fs bash# ln -s ../init.d/hostname S30hostname bash# cd

/staging/etc/rc0.d bash# ln -s ../init.d/local_fs K10local_fs bash# ln -s ../init.d/halt K90halt bash# cd

/staging/etc/rc6.d bash# ln -s ../init.d/local_fs K10local_fs bash# ln -s ../init.d/reboot K90reboot —————————————————————————— 6.3.9. Create the root disk image bash# cd / bash# dd if=/dev/zero of=/dev/ram7 bs=1k count=4096 bash# mke2fs -m0 /dev/ram7 4096 bash# mount /dev/ram7 /mnt bash# cp -dpR

/staging/* /mnt bash# umount /dev/ram7 bash# dd if=/dev/ram7 of=

/phase5-image bs=1k bash# gzip -9

/phase5-image —————————————————————————— 6.3.10. Copy the image to diskette Insert the diskette labeled «root disk» into drive fd0. bash# dd if=

/phase5-image.gz of=/dev/fd0 bs=1k —————————————————————————— 6.4. Implementation 6.4.1. System Startup Boot the PC using the floppy labeled «boot disk». Place the recently created root disk in fd0 when prompted. The output should resemble the example below: GNU GRUB version 0.95 Uncompressing Linux. Ok, booting kernel. .. .. [various kernel messages] .. VFS: Insert root floppy to be loaded into RAM disk and press ENTER RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 178k freed Checking local filesystem integrity. /dev/ram0: clean 105/1024 files 2842/4096 blocks Remounting / as read-write. Mounting local filesystems. Setting the hostname. INIT: Entering runlevel: 1 # _ —————————————————————————— 6.4.2. Verify success of startup scripts Use the mount command to check that local filesystems are mounted as read-write. The output should look like the example below. bash# mount /dev/root on / type ext2 (rw) proc on /proc type proc (rw) Check the hostname. bash# uname -n gnu-linux —————————————————————————— 6.4.3. System shutdown Bring the system down gracefully with the shutdown command. bash# shutdown -h now We should see the following output from init and the shutdown scripts: INIT: Switching to runlevel: 0 INIT: Sending processes the TERM signal Terminated INIT: Sending processes the KILL signal Unmounting local filesystems. Initiating system halt. System halted. —————————————————————————— Chapter 7. Enabling Multiple Users 7.1. Analysis Up to now the system has been operating in single-user mode. There is no login process and anyone who boots the system goes straight into a shell with root privileges. Obviously, this is not the normal operating mode for most GNU/Linux distributions. Most systems feature multi-user capability where many users can access the system simultaneously with different privilege levels. These multi-user systems also support virtual consoles so that the keyboard and video display can be multiplexed between several terminal sessions. So in this phase we would like to add the following enhancements to the system: * Enable multi-user capability. * Create multiple, virtual consoles. —————————————————————————— 7.2. Design 7.2.1. The login process The From-Powerup-To-BASH-Prompt-HOWTO does a good job of outlining the steps in the login process. Basically it works like this. 1. The init daemon starts a getty process on the terminal. 2. The getty program displays the contents of /etc/issue and prompts for a user name. 3. When the user name is entered, control is handed off to the login program. 4. The login program asks for a password and verifies the credentials using /etc/passwd, /etc/group and possibly /etc/shadow. 5. If everything is okay the user’s shell is started. —————————————————————————— 7.2.2. Obtaining source code The getty and login programs were already installed as part of the util-linux package so there is no need to download any new source code. —————————————————————————— 7.2.3. Creating support files 7.2.3.1. Device nodes Details about virtual console device files can be found in the Linux kernel source code file called devices.txt in the Documentation directory. We will need to create tty1 through tty6 for each of the virtual consoles as well as tty0 and tty to represent the current virtual console. —————————————————————————— 7.2.3.2. /etc/issue The /etc/issue file is pretty easy to construct. It can contain any text we want displayed on the screen prior to the login prompt. It could be something friendly like «Welcome to Pocket Linux», something menacing like «Authorized users only!» or something informational like «Connected to tty1 at 9600bps». The agetty(8) manpage explains how to display information like tty line and baud rate using escape codes. —————————————————————————— 7.2.3.3. /etc/passwd The format of /etc/passwd can be obtained by reading the passwd(5) manpage. We can easily create a user account by adding a line like «root::0:0: superuser:/root:/bin/sh» to the file. Maintaining passwords will be somewhat challenging because of the system being loaded into ramdisk. Any changes to /etc/passwd will be lost when the system is shutdown. So to make things easy, we will create all users with null passwords. —————————————————————————— 7.2.3.4. /etc/group The structure of /etc/group is available from the group(5) manpage. A line of «root::0:root» would define a group called «root» with no password, a group id of zero and the user root assigned to it as the only member. —————————————————————————— 7.2.3.5. Conventions User and group names and id’s are generally not chosen at random. Most Linux systems have very similar looking /etc/passwd and /etc/group files. Definitions for commonly used user id and group id assignments may be found in one of several places: * The /etc/passwd and /etc/group files on any popular GNU/Linux distribution. * The Debian Policy Manual — available online at [http://www.debian.org/ doc/debian-policy] http://www.debian.org/doc/debian-policy. * The Linux Standard Base specification — downloadable in many formats from [http://www.linuxbase.org/spec/index.shtml] http://www.linuxbase.org /spec/index.shtml. * Essential System Administration, 3rd Edition by Aeleen Frisch — available at libraries, bookstores or directly from O’Reilly Publishing at [http://www.oreilly.com/] http://www.oreilly.com/. —————————————————————————— 7.2.4. Dependencies Running ldd on the login program from util-linux will reveal that it is linked to the libraries libcrypt.so.1, libc.so.6 and ld-linux.so.2. In addition to these libraries there is another, unseen dependency on libnss_files.so.2 and the configuration file /etc/nsswitch.conf. The name service switch library libnss_files.so.2 and nsswitch.conf are required for libc.so.6, and consequently the login program, to access the / etc/passwd file. Without libnss and its configuration file, all logins will mysteriously fail. More information about glibc’s use of the name service switch libraries can be found at [http://www.gnu.org/software/libc/manual/ html_node/Name-Service-Switch.html] http://www.gnu.org/software/libc/manual/ html_node/Name-Service-Switch.html. —————————————————————————— 7.2.5. Assigning ownership and permissions Previously, with the single user system, there was no need to worry about permissions when installing directories, files and device nodes. The shell was effectively operating as root, so everything was accessible. Things become more complex with the addition of multiple user capability. Now we need to make sure that every user has access to what they need and at the same time gets blocked from what they do not need. A good guideline for assigning ownership and permissions would be to give the minimum level of access required. Take the /bin directory as an example. The Filesystem Hierarchy (FHS) document says, «/bin contains commands that may be used by both the system administrator and by users». From that statement we can infer that /bin should have read and execute permission for everyone. On the other hand, the /boot directory contains files for the boot loader. Chances are good that regular users will not need to access anything in the / boot directory. So the minimum level of access would be read permission for the root user and other administrators who are members of the root group. Normal users would have no permissions assigned on the /boot directory. Most of the time we can assign similar permissions to all the commands in a directory, but there are some programs that prove to be exceptions to the rule. The su command is a good example. Other commands in the /bin directory have a minimum requirement of read and execute, but the su command needs to be setuid root in order to run correctly. Since it is a setuid binary, it might not be a good idea to allow just anyone to run it. Ownership of 0:0 (root user, root group) and permissions of rwsr-x— (octal 4750) would be a good fit for su. The same logic can be applied to other directories and files in the root filesystem using the following steps: 1. Assign ownership to the root user and root group. 2. Set the most restrictive permissions possible. 3. Adjust ownership and permissions on an «as needed» basis. —————————————————————————— 7.3. Construction 7.3.1. Verify presence of getty and login bash# ls

/staging/sbin/getty bash# ls

/staging/etc/inittab by changing the default runlevel and adding getty entries as shown below. # /etc/inittab — init daemon configuration file # # Default runlevel id:2:initdefault: # # System initialization si:S:sysinit:/etc/init.d/rc S # # Runlevel scripts r0:0:wait:/etc/init.d/rc 0 r1:1:respawn:/bin/sh r2:2:wait:/etc/init.d/rc 2 r3:3:wait:/etc/init.d/rc 3 r4:4:wait:/etc/init.d/rc 4 r5:5:wait:/etc/init.d/rc 5 r6:6:wait:/etc/init.d/rc 6 # # Spawn virtual terminals 1:235:respawn:/sbin/getty 38400 tty1 linux 2:235:respawn:/sbin/getty 38400 tty2 linux 3:235:respawn:/sbin/getty 38400 tty3 linux 4:235:respawn:/sbin/getty 38400 tty4 linux 5:235:respawn:/sbin/getty 38400 tty5 linux 6:2345:respawn:/sbin/getty 38400 tty6 linux # # end of /etc/inittab —————————————————————————— 7.3.3. Create tty devices bash# cd

/staging/dev bash# mknod

/staging/dev/tty0 c 4 0 bash# mknod

/staging/dev/tty1 c 4 1 bash# mknod

/staging/dev/tty2 c 4 2 bash# mknod

/staging/dev/tty3 c 4 3 bash# mknod

/staging/dev/tty4 c 4 4 bash# mknod

/staging/dev/tty5 c 4 5 bash# mknod

/staging/dev/tty6 c 4 6 bash# mknod

/staging/dev/tty c 5 0 —————————————————————————— 7.3.4. Create support files in /etc 7.3.4.1. /etc/issue Create the file

/staging/etc/issue using the example below or design a customized message. Connected to \l at \b bps. Be sure that «\l» is a lowercase letter L and not the number one. —————————————————————————— 7.3.4.2. /etc/passwd Use a text editor to create a minimal passwd file conforming to the Linux Standards Base (LSB) document. Save the file as

/staging/etc/passwd root::0:0:Super User:/root:/bin/sh bin:x:1:1:Legacy UID:/bin:/bin/false daemon:x:2:2:Legacy UID:/sbin:/bin/false —————————————————————————— 7.3.4.3. /etc/group Use a text editor to create an LSB conforming group file and save it as

/ staging/etc/group root::0:root bin:x:1:root,bin,daemon daemon:x:2:root,bin,daemon —————————————————————————— 7.3.4.4. /etc/nsswitch.conf Create the following file and save it as

/staging/etc/nsswitch.conf passwd: files group: files —————————————————————————— 7.3.5. Copy required libraries bash# cp /lib/libnss_files.so.2

/staging/lib bash# strip —strip-unneeded

/staging/lib/* —————————————————————————— 7.3.6. Set directory and file permissions Set minimal privileges on all files and directories under

/staging. Everything is owned by the root user and the root group. Permissions are read-write for the owner and read-only for the group. Exceptions to the blanket permissions are handled case by case. bash# cd

/staging bash# chown -R 0:0

/staging/* bash# chmod -R 640

/staging/* Set execute permission on all directories. (Note the capital «X») bash# chmod -R +X

/staging/* Files in /bin are read and execute for all, but su is an exception. bash# chmod 755

/staging/bin/* bash# chmod 4750

/staging/bin/su Files in /dev have various permissions. Disk devices should be accessible to administrators only. Other files like /dev/null should have full privileges granted to everyone. bash# chmod 660

/staging/dev/fd0 dev/ram0 bash# chmod 666

/staging/dev/null bash# chmod 622

/staging/dev/console bash# chmod 600

/staging/dev/initctl bash# chmod 622

/staging/dev/tty bash# chmod 622

/staging/dev/tty? The passwd and group files must be world readable. bash# chmod 644

/staging/etc/passwd bash# chmod 644

/staging/etc/group The scripts in /etc/init.d are read and execute for administrators. bash# chmod 750

/staging/etc/init.d/* Libraries need read and execute permissions for everyone. bash# chmod 755

/staging/lib/* Only root should have access to the /root directory. bash# chmod 700

/staging/root Make files in /sbin read and execute for administrators. bash# chmod 750

/staging/sbin/* Temp should be read-write for all with the sticky bit set. bash# chmod 1777

/staging/tmp —————————————————————————— 7.3.7. Create the root disk image bash# cd / bash# dd if=/dev/zero of=/dev/ram7 bs=1k count=4096 bash# mke2fs -m0 /dev/ram7 4096 bash# mount /dev/ram7 /mnt bash# cp -dpR

/staging/* /mnt bash# umount /dev/ram7 bash# dd if=/dev/ram7 of=

/phase6-image bs=1k count=4096 bash# gzip -9

/phase6-image —————————————————————————— 7.3.8. Copy the image to diskette Insert the diskette labeled «root disk» into drive fd0. bash# dd if=

/phase6-image.gz of=/dev/fd0 bs=1k —————————————————————————— 7.4. Implementation 7.4.1. System Startup If everything goes well, the virtual console display should look similar to the following example: Connected to tty1 at 38400 bps. gnu-linux login: —————————————————————————— 7.4.2. Add a new user to the system Log in as root. Create a new, unprivileged user and new group by appending a line to the /etc /passwd and /etc/group files, respectively. Be sure to use a double greater-than (>>) to avoid accidentally overwriting the files. bash# echo «floyd::501:500:User:/home/floyd:/bin/sh» >>/etc/passwd bash# echo «users::500:» >>/etc/group bash# mkdir /home/floyd bash# chown floyd.users /home/floyd bash# chmod 700 /home/floyd —————————————————————————— 7.4.3. Test the new user’s ability to use the system Switch to virtual terminal tty2 by pressing ALT+F2. Log in as floyd. Try the following commands and verify that they work. bash$ pwd bash$ ls -l / bash$ cat /etc/passwd Try the following commands and verify that they do not work. bash$ ls /root bash$ /sbin/shutdown -h now bash$ su — —————————————————————————— 7.4.4. System shutdown Switch back to tty1 where root is logged in. bash# shutdown -h now —————————————————————————— Chapter 8. Filling in the Gaps 8.1. Analysis The root disk has come a long way since its humble beginnings as a statically-linked shell. It now shares many features with the popular, ready-made distributions. For example it has: * Several common utilities like cat, ls and so on. * Startup scripts that automatically check and mount filesystems. * Graceful shutdown capability. * Support for multiple users and virtual terminals. As a final test, we can put the root disk up against the Filesystem Hierarchy Standard (FHS) requirements for the root filesystem. (We will ignore anything in the /usr hierarchy because of space constraints.) Compared to FHS requirement, the only files missing are a few commands in the /bin directory. Specifically, the root disk lacks the following commands: * more * ps * sed In addition to the required commands, it might be nice to include the «ed» editor listed as an option by the FHS. It is not as robust as vi or emacs, but it works and it should fit onto the tiny root filesystem. So in order to finish up this phase of the project, we need to accomplish the following goals: * Add the more, ps and sed commands. * Install the optional ed editor. —————————————————————————— 8.2. Design 8.2.1. more There is a more command that comes with util-linux, but it will not work for this project. The reason is because of library dependencies and space constraints. The util-linux supplied more needs either the libncurses or libtermcap to work and there just is not enough space on the root disk floppy to fit everything in. So, in order to have a more command we will have to get creative. The more command is used to display a file page by page. It’s a little like having a cat command that pauses every twenty-five lines. The basic logic is outlined below. * Read one line of the file. * Display the line on the screen. * If 25 lines have been displayed, pause. * Loop and do it again. Of course there are some details left out like what to do if the screen dimensions are not what we anticipated, but overall it is a fair representation of what more does. Given this simple program logic, it should not be hard to put together a short shell script that emulates the basic functionality of more. The BASH(1) manpage and Adv-BASH-Scripting-Guide will serve as references. —————————————————————————— 8.2.2. More device files The more script will need access to device files that are not on the root disk yet. Specifically more needs to have stdin, stdout and stderr, but while we are at it we should check for any other missing /dev files. The Linux Standard Base requires null, zero and tty to be present in the /dev directory. Files for null and tty already exist from previous phases of the project, but we still need /dev/zero. We can refer to devices.txt in the Linux source code Documentation directory for major and minor numbers. —————————————————————————— 8.2.3. ps, sed & ed These three packages can be found by using the Internet resources we have used before plus one new site. The «sed» and «ed» packages can be found at the same place we found BASH, on the [ftp://ftp.gnu.org] GNU FTP server. The procps package shows up in an Ibiblio LSM search, but it is an old version. In order to find the latest version we can go to the Freshmeat website at [http://freshmeat.net] http://freshmeat.net and search for «procps» in projects. Both «sed» and «ed» packages feature GNU’s familiar configure script and are therefore very easy to build. There is no configure script for «procps» but this does not make things too difficult. We can just read the package’s README file to find out about how to set various configuration options. We can use one of these options to avoid the complexity of using and installing libproc. Setting SHARED=0 makes libproc an integrated part of ps rather than a separate, shared library. —————————————————————————— 8.3. Construction 8.3.1. Write a «more» script Create the following script with a text editor and save it as

/staging/bin/ more.sh #!/bin/sh # # more.sh — emulates the basic functions of the «more» binary without # requiring ncurses or termcap libraries. # # Assume input is coming from STDIN unless a valid file is given as # a command-line argument. if [ -f $1 ]; then INPUT=»$1″ else INPUT=»/dev/stdin» fi # # Set IFS to newline only. See BASH(1) manpage for details on IFS. IFS=$’\n’ # # If terminal dimensions are not already set as shell variables, take # a guess of 80×25. if [ «$COLUMNS» = «» ]; then let COLUMNS=80; fi if [ «$LINES» = «» ]; then let LINES=25; fi # # Initialize line counter variable let LINE_COUNTER=$LINES # # Read the input file one line at a time and display on STDOUT until # the page fills up. Display «Press » message on STDERR and wait # for keypress from STDERR. Continue until the end of the input file. # Any input line greater than $COLUMNS characters in length is wrapped # and counts as multiple lines. # while read -n $COLUMNS LINE_BUFFER; do echo «$LINE_BUFFER» let LINE_COUNTER=$LINE_COUNTER-1 if [ $LINE_COUNTER -le 1 ]; then echo «Press for next page or +C to quit.»>/dev/stderr read /dev/ram1. Now the compressed floppy goes straight into ramdisk, decompressing on the fly. —————————————————————————— A.2.2.2. Root disk support for additional ramdisks We already have kernel support for ramdisks, because we are using a compressed root disk, but we will need to create more ramdisks in /dev. Typically the kernel supports eight ramdisks on /dev/ram0 through /dev/ram7 with ram0 being used for the rootdisk. The devices.txt file included in the Linux source code documentation will be helpful for matching devices to their major and minor numbers. —————————————————————————— A.2.3. Accessing audio files The sample mp3 file that we will be using in our example is small enough to fit on an uncompressed floppy disk so that there is no need to burn a CD. However, serious music lovers may want to have the capability to mount a custom CD-ROM full of tunes and that option will require support for additional hardware. —————————————————————————— A.2.3.1. CD-ROM hardware support Most modern CD-ROM drives will use IDE devices like /dev/hdc or /dev/hdd. To support these CD-ROM drives we will have to configure IDE support in the kernel and create the appropriate device files on the root disk. —————————————————————————— A.2.3.2. CD-ROM filesystem support CD-ROMs have different filesystems than hard disks and floppies. Most CD burning applications use a filesystem called ISO-9660 and have the capability to support Joliet or Rockridge extensions. We will have to include support for these filesystems in the kernel in order to mount CD-ROMs. —————————————————————————— A.2.4. Other required files We will want to have all of mp3blaster’s required libraries and other supporting files available as part of the compressed /usr image so that mp3blaster can run correctly. The familiar ldd command can be used to determine which libraries mp3blaster requires. Any additional libraries can be placed in /usr/lib. Even though some of the libraries may appear in /lib on the development system, they can still go in /usr/lib on the Pocket Linux system. The dynamic linker, ld-linux.so, is smart enough to look in both places when loading libraries. Because mp3blaster uses the curses (or ncurses) screen control library there is one additional file we need. The curses library needs to know the characteristics of the terminal it is controlling and it gets that information from the terminfo database. The terminfo database consists of all the files under the /usr/share/terminfo directory and is very large compared to our available disk space. But, since Pocket Linux only supports the PC console, we only have one terminal type to worry about and therefore need only one file. The piece of the terminfo database we need is the file /usr/ share/terminfo/l/linux, because we are using a «Linux» terminal. For more information about the subject of curses, see John Strang’s book entitled «Programming with Curses» available from O’Reilly publishing. —————————————————————————— A.2.5. Summary of tasks Between sound cards, ramdisks, CD-ROMs and terminfo there is quite a bit to keep track of. So let’s take a moment to organize and summarize the tasks necessary to make the pocket jukebox a reality. * Create a new kernel disk that includes built-in support for audio hardware, IDE devices and CD-ROM filesystems. * Create the appropriate /dev files on the root disk to support audio hardware, additional ramdisks and IDE CD-ROMs. * Install the gunzip utility to enable decompression of the usr image. * Create a startup script to load a compressed image from floppy into a ramdisk and mount the ramdisk on /usr. * Create a compressed floppy that holds the mp3blaster program, its required libraries and terminfo files. —————————————————————————— A.3. Construction A.3.1. Create an enhanced boot disk A.3.1.1. Build a new kernel bash# cd /usr/src/linux bash# make menuconfig Be sure to configure support for the following: * 386 processor * Floppy disk * RAM disk * Second extended (ext2) filesystem * Virtual console * Audio hardware * CD-ROM hardware * ISO-9660 and Joliet filesystems bash# make dep bash# make clean bash# make bzImage —————————————————————————— A.3.1.2. Copy the kernel to diskette Place the boot disk in drive fd0 bash# mount /dev/fd0 /mnt bash# cp /usr/src/linux/arch/i386/boot/bzImage /mnt/boot/vmlinuz —————————————————————————— A.3.1.3. Unmount the boot disk bash# cd / bash# umount /mnt —————————————————————————— A.3.2. Create an enhanced root disk A.3.2.1. Create additional device files A.3.2.1.1. IDE CD-ROM bash# mknod -m640

/staging/dev/hdc b 22 0 bash# mknod -m640

/staging/dev/hdd b 22 64 Optionally create additional IDE devices. —————————————————————————— A.3.2.1.2. Ramdisk bash# mknod -m 640

/staging/dev/ram1 b 1 1 bash# mknod -m 640

/staging/dev/ram2 b 1 2 bash# mknod -m 640

/staging/dev/ram3 b 1 3 bash# mknod -m 640

/staging/dev/ram4 b 1 4 bash# mknod -m 640

/staging/dev/ram5 b 1 5 bash# mknod -m 640

/staging/dev/ram6 b 1 6 bash# mknod -m 640

/staging/dev/dsp c 14 3 bash# mknod -m664

/staging/dev/mixer c 14 0 —————————————————————————— A.3.2.2. Install the gunzip binary bash# cd /usr/src/gzip-1.2.4a bash# export CC=»gcc -mcpu=i386″ bash# ./configure —host=i386-pc-linux-gnu bash# make bash# strip gzip bash# cp gzip

/staging/bin bash# ln -s gzip

/staging/bin/gunzip Don’t forget to verify library requirements, check the ownership and check permissions on the gzip binary. —————————————————————————— A.3.2.3. Write a startup script to mount a compressed floppy Use a text editor to create the following script and save it as

/staging/etc /init.d/usr_image #!/bin/sh # # usr_image — load compressed images from floppy into ramdisk and # mount on /usr. # echo -n «Is there a compressed diskette to load for /usr [y/N]? » read REPLY if [ «$REPLY» = «y» ] || [ «$REPLY» = «Y» ]; then echo -n «Please insert the /usr floppy into fd0 and press .» read REPLY echo «Clearing /dev/ram1.» dd if=/dev/zero of=/dev/ram1 bs=1k count=4096 echo «Loading compressed image from /dev/fd0 into /dev/ram1. » (dd if=/dev/fd0 bs=1k | gunzip -cq) >/dev/ram1 2>/dev/null fsck -fp /dev/ram1 if [ $? -gt 1 ]; then echo «Filesystem errors on /dev/ram1! Manual intervention required.» else echo «Mounting /usr.» mount /dev/ram1 /usr fi fi # # end of usr_image Configure the script to run right after root is mounted. bash# ln -s ../init.d/usr_image

/staging/etc/rcS.d/S21usr_image —————————————————————————— A.3.2.4. Create a compressed root disk bash# cd / bash# dd if=/dev/zero of=/dev/ram7 bs=1k count=4096 bash# mke2fs -m0 /dev/ram7 bash# mount /dev/ram7 /mnt bash# cp -dpR

/staging/* /mnt bash# umount /dev/ram7 bash# dd if=/dev/ram7 of=

/phase8-image bs=1k bash# gzip -9

/phase8-image Insert the diskette labeled «root disk» into drive fd0. bash# dd if=

/phase8-image.gz of=/dev/fd0 bs=1k —————————————————————————— A.3.3. Create a compressed /usr disk for mp3blaster The compressed /usr diskette will be created in using the same process that is used to create the compressed root disk. We will copy files to a staging area, copy the staging area to ramdisk, compress the ramdisk and write it to diskette. —————————————————————————— A.3.3.1. Create a staging area bash# mkdir

/usr-staging bash# cd

/usr-staging bash# mkdir bin lib bash# mkdir -p share/terminfo/l —————————————————————————— A.3.3.2. Install the mp3blaster program Download the latest version of mp3blaster source code from its home at [http: //www.stack.nl/

brama/mp3blaster/. bash# cd

/usr/src/mp3blaster-3.2.0 bash# ./configure bash# make bash# cp src/mp3blaster

/usr-staging/bin —————————————————————————— A.3.3.3. Copy additional libraries and terminfo Use ldd to find out which libraries are needed for mp3blaster. Note The following is an example from the author’s development system. It is possible that different systems may yield slightly different results in terms of library requirements. bash# cd

/usr-staging/lib bash# ldd

/usr-staging/bin/mp3blaster bash# cp /usr/lib/ncurses.so.5.0 . bash# cp /usr/lib/stdc++.so.3 . bash# cp /lib/libm.so.6 . bash# cp /usr/lib/libgcc_s.so.1 . bash# cd

/usr-staging/share/terminfo/l bash# cp /usr/share/terminfo/l/linux . —————————————————————————— A.3.3.4. Make a compressed image and copy it to diskette bash# cd / bash# dd if=/dev/zero of=/dev/ram7 bs=1k count=4096 bash# mke2fs -m0 /dev/ram7 bash# mount /dev/ram7 /mnt bash# cp -dpR

/usr-staging/* /mnt bash# umount /dev/ram7 bash# dd if=/dev/ram7 of=

/mp3blaster-image bs=1k bash# gzip -9

/mp3blaster-image Insert the diskette labeled «mp3blaster» into drive fd0. bash# dd if=

Источник