TuxScreen on SourceForge TuxScreen CVS search the Wiki
Browsing -> Wiki -> Main -> [pivot_root_to_debian-ARM]
edit, info, topics, orphans, hubs and nodes, or recent changes in the Wiki create a new user or login

TomW - June 17, 2002

For those of you not familiar (heh) with what Debian-ARM is about: Debian has put together a fairly complete distribution of linux that will run on an ARM system. The distro is currently supported by the ARM community and runs the 2.2 kernel. Don't dispair, the Tux 2.4 kernel runs reasonably well under debian-ARM.

This outlines the implementation of pivot_root on a Tux that has an IDE drive available. Following this guide will give you a Tux installation that will: load the kernel & ramfs from the Flash, bring up the IDE drive, pivot_root to the operating system (/etc/init.d/rc) of the drive. Although I would rather have the entire system behave as if the Flash memory was an initrd.img (minimal boot followed by loading the "real" kernel from the IDE), I haven't been able to take time to figure that out yet. Perhaps you have the solution? ;-)

Building the nfs image

First step is to get pivot_root working with nfs. This is not necessary, but can be valuable when you screw your IDE image and need to regain control of the system boot process so you can correct the mistake on the IDE image.

* Get the base2_2.tgz ARM tarball from debian, I got mine from: http://ftp.debian.org/debian/dists/potato/main/disks-arm/current/base2_2.tgz This is a 15Meg file so it will take a while to download (YMMV).

* On the workstation, create an nfs volume and unpack the base2_2.tgz there:

1. edit .rhosts & exports to allow the Tux to access the nfs volume
2. become root user (su)
3. cd into that volume space on the nfs server and 'tar zxpf base2_2.tgz'.
You must be root to do this, make sure that you specify the 'p' flag otherwise
you will change permissions of the files within the image!!!
4. delete the file sbin/unconfigured.sh from the image, otherwise it will ask
for floppies when the Tux boots from the nfs image.
5. create directory under /mnt as initrd so pivot_root can place the Flash image
there when pivoting (mkdir mnt/initrd).
6. create a linuxrc file in the root of the image directory, make it executable:
echo "pivotroot succeeded!"
exec /sbin/init

* On the Tux:

1. make sure that your ethernet card is properly recognized by the cardmgr on boot.
2. Change the nfs section of the linuxrc so that it reads as follows.
# do we have an ethernet card?
if ifconfig eth0 | grep -q -i hwaddr ; then
 echo found eth0
 ifconfig eth0 up
 /bin/mount -o nolock /mnt
 if test -x /mnt/linuxrc ; then
 # if it is executable then we should pivot_root to it
  /bin/umount /proc
  cd /mnt/
  /sbin/pivot_root /mnt /mnt/mnt/initrd && exec /linuxrc
  /bin/mount -t proc proc /proc
 if /bin/mount | grep -q "on /mnt type" ; then
  /bin/umount /mnt

Of course, change the IP address to what you use for your workstation ( and the Tux (, also the nfs volume name as well (/home/tom/Debian/nfs_root). No, that reference to /mnt/mnt/initrd is not a typo, not if you think about it. Pivot_root needs to place the existing filesystem somewhere when it mounts the new one, so we stick it where we can get at it when running the new root filesystem (eventually /mnt/initrd).

Now test the thing to make sure it works by rebooting the Tux, it should mount the root filesystem from the nfs volume. Once you have verified this, remove the executable permission from the linuxrc of the nfs root image (chmod -x linuxrc), this will now allow you to boot the Flash file system. Note: while the nfs filesystem is mounted, look in /mnt/initrd, the contents of the Flash filesystem is there! You can edit your linuxrc & other files while it is mounted under /mnt/initrd. No, I haven't figured out how to update the kernel image that way.

Root filesystem on IDE.

The root filesystem on IDE is a bit more involved, not much, than we did for the nfs.

* On the Tux:

1. Make sure that you can mount the root volume of the drive on
the Tux, e.g. mount /dev/hda1 /mnt
2. populate the drive volumes with the contents of the nfs image.
3. Edit the contents of the drive's /etc/fstab to reflect how the filesystem is
constructed, my /etc/fstab is:
/dev/hda1	/		reiserfs	defaults	1 1
/dev/hda5	/tmp		reiserfs	defaults	1 2
/dev/hda6	/var		reiserfs	defaults	1 2
/dev/hda7	/usr		reiserfs	defaults	1 2
/dev/hda8	/home		reiserfs	defaults	1 2
/dev/hda2	swap		swap	defaults	0 0
none		/proc		proc	defaults	0 0
none		/dev/pts	devpts	defaults	0 0
other:/OldOS/Window/ /opt nfs nolock 0 0
4. Edit the section of the Tux linuxrc to something like mine:
# do we have /linuxrc on hda1?
if test -b /dev/hda1 ; then
 # we have a /dev/hda1 block device
 /bin/mount -t reiserfs /dev/hda1 /mnt
 if test -x /mnt/linuxrc ; then
  /bin/umount /proc
  cd /mnt/
  /sbin/pivot_root /mnt /mnt/mnt/initrd && exec /linuxrc
  /bin/mount -t proc proc /proc
 if /bin/mount | grep -q "on /mnt type" ; then
  /bin/umount /mnt
5. put the same linuxrc as you used within the nfs image in the root of IDE
filesystem and make it executable.

Just a few notes here. I constructed a set of reiserfs volumes by mounting the IDE drive onto my workstation and using the tools from there. I haven't been able to successfully create a set of reiserfs tools that will run on the Tux (uClibc or libc). After creating the volumes, I copied the data from the nfs image onto the new drive while it was mounted to the Tux and I had the nfs volume also mounted onto the Tux. You may elect to use ext2, althought I cannot imagine why(!), the very nature of the Tux is such that it would suffer from sudden power failures / resets. If you choose to use the reiserfs, then compile that into your Tux kernel.

Wrapping it all up.

Once you have the basic systems in place (nfs & IDE), you will need to work at getting the /dev directory squared away. There is no /dev/ttySA0, or /dev/ucb1x00-ts devices within the debian system, you will need to put then there. Simply copy these devices from /mnt/initrd/boot/var/device over to the debian /dev directory.

I still don't know why we don't use the customized mkromfs that is used by uClinux and get rid of that screwy /dev@ thing... Probably so that we continue to do things "as they are done" type of deal. sigh

BradColbert - August 9, 2002

The debian 2.2 root package moved to:


Hope that helps.

SourceForge Content of these pages are owned and copyrighted by the poster. SourceForge