Sitara Linux Training: Init Scripts

Introduction

---

This lab is going to give you a hands on tutorial of how the Linux init scripts work with the sysvinit system as well as how the profile scripts can be used to affect the login process. Each of the following sections below will walk you through an excersize describing the actions that are about to be performed, the key points to take away, and the step-by-step instructions to complete the lab. If you have questions or feedback please e-mail the sdk_feedback@list.ti.com mailing list.

NOTE: In this guide commands to be executed for each step will be marked in BOLD

Lab Configuration

The following are the hardware and software configurations for this lab. The steps in this lab are written against this configuration. The concepts of the lab will apply to other configurations but will need to be adapted accordingly.

Hardware

• AM335x EVM-SK (TMDSSK3358) - Order Now

NOTE

Other target boards can be used but the steps below related to serial and ethernet connections may differ.

• Router connecting AM335x EVM-SK and Linux Host (For Remote Matrix lab)
• USB cable connection between AM335x EVM-SK and Linux Host using the micro-USB connector (J3/USB0)

NOTE

The AM335x EVM uses a standard DB9 connector and serial cable. New Win7 based Host PCs may require a USB-to-Serial cable since newer laptops do not have serial ports.

• 5V power supply (typically provided with the AM335x EVM-SK)

Software

• A Linux host PC configured as per the Linux Host Configuration page
• Sitara Linux SDK installed. This lab assumes the latest Sitara Linux SDK is installed in /home/sitara. If you use a different location please modify the below steps accordingly.
• SD card with Sitara Linux SDK installed.

• For help creating a 2 partition SD card with the SDK conent see the create_sdcard.sh script page

• CCSv5 installed. This lab assumes CCS has been installed in /home/sitara. If you use a different location please modify the below steps accordingly.

• The CCS installer can be downloaded from the [http://www.ti.com/tool/linuxezsdk-sitara] page and if extracted into the same directory as the SDK installer can be installed at the same time as the Sitara Linux SDK using the SDK installer.
  

Adding a Simple Init Script

Description

This lab will add a very simple helloworld style init script to the boot process.

Prerequisites

• A development environment configured for NFS. For help on setting up the development environment and the SDK see Sitara Linux Training: Hands on with the SDK
• USB-to-Serial Adapter configured. The following steps will help you to verify that the adapter has been configured properly:
  1. Connect the USB-to-Serial adapter to the VMWare image using Virtual Machine -> Removable Devices -> Prolific usb-serial controller -> Connect. You may see a warning message from VMWare, answer Yes if prompted.
     • NOTE: If you are running your VMWare image with Windows 7 some USB-to-Serial adapters do not properly work with Windows 7. Make sure that your adapter specifically says that it supports Windows 7. You may also need to install an additional driver for your adapter.
     • In the case of the Trendnet TU-S9 adapter the driver can be downloaded from http://www.trendnet.com/downloads/list_subcategory.asp?SUBTYPE_ID=571.
  2. Once the driver as been installed (if needed) and the adapter has been attached to the virtual machine open a terminal window
  3. In the terminal window do ls /dev/tty*
     • You should see a device listed like /dev/ttyUSB0
  4. To verify that minicom can connect to the adapter perform the following steps from the terminal
     1. minicom -s
     2. Select Serial port setup and press ENTER
     3. If the Serial Device is not already /dev/ttyUSB0 then press A and type the /dev/ttyUSB0, then press ENTER
     4. press ENTER to exit the Serial port setup
     5. Select Exit and press ENTER

     If you see a message like minicom: cannot open /dev/ttyUSB0: No such file or directory then your minicom is not properly configured. Make sure you have:

     • Installed the driver for your adapter
     • Try another port on your laptop

  5. If you have configured your serial adapter correctly you should see output like

Welcome to minicom 2.4 
    OPTIONS: I18n 
Compiled on Jan 25 2010, 06:49:09. 
Port /dev/ttyUSB0 
    Press CTRL-A Z for help on special keys

Key Points

• Where to place the script file
• Creating a symlink to add the script to the boot process

Lab Steps

1. Insert the SD card and boot your board using an NFS file system
2. Login to the root file system using:

   user name: root

   password: <no password>

3. Change directory to the standard initscript directory /etc/init.d

   cd /etc/init.d

4. Open a file for editing called helloworld.sh in the /etc/init.d directory.

   vi helloworld.sh

   NOTE: In all of these labs if you are not familiar with vi or would like to use a graphical editor like emacs you can also edit these files on the NFS share you have mounted. For example if using the SDK defaults you can edit the files in the <SDK INSTALL DIR>/targetNFS/ directory instead.

5. Add the following lines to the helloworld.sh file

   #!/bin/sh

   echo ""

   echo "Hello from Sitara!!!"

   echo ""

6. Give the init script executable permissions so that it can be run

   chmod +x helloworld.sh

7. The init script has been created, but it has not been linked into the list of scripts to run on boot. To do so you will need to create a symlink to the script in the proper run level directory. The default run level is 5 so the symlink will be created there.

   cd /etc/rc5.d

   ln -s ../init.d/helloworld.sh S99helloworld

8. You can now reboot your board using the following command

   init 6

9. On the next boot you should see the output from the init script like the following

   

Adding Start/Stop command

Description

This lab will cover adding start and stop routines to the init script and how the start or stop option is passed to the init script. You will learn how to make the init script perform different operations based on the run-level and script name.

Prerequisites

• None

Key Points

• The start/stop value is provided as the first parameter to the script
• A case statement can be used to handle the different use cases
• The value passed to a K (or Kill) script is stop and the value passed to an S (or Start) script is start

Lab Steps

1. With the board booted you will now modify the helloworld.sh script in /etc/init.d to have start and stop routines.

   vi /etc/init.d/helloworld.sh

2. Add modify the script to match the following

   #!/bin/sh

   case $1 in

   start )

   echo ""

   echo "Hello from Sitara!!!"

   echo ""

    ;;

   stop )

   echo ""

   echo "Goodbye from Sitara :("

   echo ""

    ;;

   * )

   echo "$0: unknown option passed"

    ;;

   esac

3. We already have this script set to execute in run level 5, but now we will add it to the rc6 run level which contains the scripts that will be executed on reboot. In this case we will add the script as a K (or Kill) script.

   cd /etc/rc6.d

   ln -s ../init.d/helloworld.sh K99helloworld

4. Now reboot your EVM using the init 6 command which tells the system to switch to run level 6, which is the reboot run level.

   init 6

5. Watching the output as the system reboots you should see output like

   

6. As the system comes up after the reboot you should also see the following output that you saw in the previous lab.

   

Changing the Order of Script Execution

Key Points

• The number of the script will change its execution position in the boot order.
• In the rc6 (and rc0) run levels the value passed to both K and S scripts is start making these a special case
• Optimizations in the rc script prevent S scripts with the same name as the S script in another run level from running unless proceeded by a K script

Change run-level using Bootargs

Description

Now that we have a simple script that prints hello and goodbye messages it might be nice to make sure that the output from these scripts is not lost as the screen scrolls. For example, in the previous lab the "Goodbye from Sitara :(" was printed and was then followed by additional screen output. In this lab we are going to change the order so that this is one of the last lines printed.

Prerequisites

• None

Key Points

• S scripts in the rc6 (and rc0) run levels are still passed the stop option even though they are S (or Start) scripts
• The order of scripts as listed by ls is the order of execution. Adding a script later in the order changes when the script is run.
• Due to optimizations in the rc script if there is an S script in the previous run level with the same name, and the new run level does not have a K script with that same name, then the S script in the new run level will not be re-run. This is to save time running scripts that have already been run.
  • This optimization does not take into account special cases like run level 6 where an S script is called with a different parameter than in other run levels.

Lab Steps

1. Once the board is booted and you are logged in go to the rc6.d directory and view the order of the init scripts

   cd /etc/rc6.d

   ls

   

2. Currently the helloworld K script is the last K script to be run before the S scripts start running. In this lab we want to change that order such that our goodbye message is the last one the user sees (aside from the rebooting message since of course we can't print a message after the reboot occurs). To do this change the K99helloworld script to S89helloworld, which will put it right before the S90reboot script.

   mv K99helloworld S89helloworld

   

3. Reboot the system using the init 6 command

   init 6

4. What happened to the "Goodbye from Sitara :(" message? This is the result of an rc script optimization. When changing from run level 5, which contains a script S99helloworld, to run level 6, which contains a script called S98helloworld, the rc script does the following
   1. Remove the S## leading characters to get the script name
   2. Check if the previous run level, in this case run level 5, had a script with the same name.
   3. If so then check if the current run level, in this case run level 6, has a K script with the same name.
   4. If not then do not run the S script because it is perceived as a duplicate call to the script
5. Once the board has booted login so that we can modify the script to be run as an S script
6. There are two options to fix this issue. One is to make a dummy K script, or to change the name of the S script. In this lab we will rename the S script from S89helloworld to S89helloworld2

   cd /etc/rc6.d

   mv S89helloworld S89helloworld2

7. Reboot the board using the init 6 command.

   init 6

8. This time you should see the script run right before the reboot command giving output like the following

   

Changing the Default Run Level

Description

Sometimes you may want to boot your system into a different run level than the default, but you do not want to change the default. For example consider the case where you may have a fast boot system with minimal services started. In order to debug the system you may want to start some additional services or go into a development mode. Having a different run level for this would be useful but something you want to boot all the time. In this lab you will learn how to modify the kernel bootargs to set a run level that will override the default value in /etc/inittab

Prerequisites

• Reboot the board and stop at the u-boot prompt

Key Points

• To change the run level simply enter the desired run-level into the bootargs

Lab Steps

1. If you have not already done so reboot the board with the init 6 command and when prompted to Hit any key to stop autoboot press the SPACE key. You screen should look like

   

2. In the default u-boot environment it is possible to add new bootargs by setting the optargs variable. In this case we can add the run level we want to switch to in the optargs. For this lab we will switch to run level 3. Since we did not create links in run level 3 for our init script we should expect to not see "Hello from Sitara!!!" printed during boot.

   setenv optargs 3

   NOTE: The above line adds the number 3 to the bootargs. Do NOT do a saveenv command at this point.

3. Now boot the board using the boot command

   boot

4. In the boot output you will notice the following (You will need to scroll back to see the full output)

   At the beginning of the boot process you can see the bootargs passed to the kernel. Notice how the number 3 is now part of the bootargs.

   

   Later in the boot process when the system transitions from the startup run level to the selected run level you will see that "INIT: Entering runlevel: 3" is printed to the screen

   

   Finally you should notice that the "Hello from Sitara!!!" message was no longer printed. This is because the message is only printed by the init script in run level 5.

5. Since we did not save the optargs that were set, on the next reboot the run level will revert back to 5. If we want to permanently change the run level we can edit the /etc/inittab file and change the line id:5:initdefault: to id:3:initdefault:

   vi /etc/inittab

   Change id:5:initdefault: to id:3:initdefault:

6. Reboot the system with init 6 command

   init 6

7. This time looking at the bootargs you should not see the number 3 listed, but observing the run level that the init process enters should still show you entering run level 3 and you should still not see the "Hello from Sitara!!!" message printed.
8. Go ahead and put the run level back to 5 in the /etc/inittab file so that the file system is back to it's normal mode of operation.

   vi /etc/inittab

   Change id:3:initdefault: to id:5:initdefault:

Adding Login Actions

Description

While init scripts can be useful, sometimes it may be more useful to perform some action when the user logs into the system. These may be actions that you do not want to run all the time, but only when interacting with a user. For this you can use the /etc/profile file or add a script to the /etc/profile.d directory. This lab will walk you through both methods.

Prerequisites

• None

Key Points

• Commands added to the /etc/profile file are executed on login
• More complex operations are easiest to put in a shell script and add to the /etc/profile.d directory
• Init scripts that consume time and are only useful when a user has logged into the system can be moved to the profile scripts to reduce boot time.

Lab Steps

1. Make sure the EVM is booted and logged in
2. Open the /etc/profile file for editing and add the following line to the end

   echo "You have logged in as "`whoami`

   Note that the "whoami" string is surrounded with the backwards tick mark found to the left of the 1 button on a standard US keyboard along with the ~ character.

3. The expected result of this command is that when you login you should see the string "You have logged in as root" printed to your screen. To test this exit from your current login and login again as root.

   exit

   Login as root

Adding Login Actions to /etc/profile.d Scripts

Description

The above example was a simple one for how to add a command to run on login. In this next example we will do something more complex which is to take an existing init script and change it from running at boot time to instead running during login. You have probably noticed the following message during the system boot

***************************************************************                 
***************************************************************                 
NOTICE: This file system contains the followin GPLv3 packages:                  
      binutils-symlinks                                                       
      binutils                                                                
      gdbserver                                                               
                                                                              
If you do not wish to distribute GPLv3 components please remove                 
the above packages prior to distribution.  This can be done using               
the opkg remove command.  i.e.:                                                 
  opkg remove <package>                                                       
Where <package> is the name printed in the list above                           
                                                                               
NOTE: If the package is a dependency of another package you                     
    will be notified of the dependent packages.  You should                   
    use the --force-removal-of-dependent-packages option to                   
    also remove the dependent packages as well                                
***************************************************************                 
***************************************************************  

The above message is from the S99gplv3-notice script in the /etc/rc5.d directory. This script takes time to scan the list of installed packages for GPLv3 licenses and write the list to the screen. In this lab we will modify the init scripts so that this action is performed when we login to the system, rather than spending several seconds on boot waiting for the scan to complete.

Prerequisites

• You should be using and Sitara Linux SDK file system since the script referenced in this lab is only part of that file system.

Key Points

• Script file placed in /etc/profile.d are executed by the /etc/profile script
• These scripts are executed for each login, including network logins

Lab Steps

1. Make sure your EVM is booted and logged in
2. In order to disable the script at boot time we need to remove it from the list of scripts to run for run level 5. Do this with the following command.

   rm /etc/rc5.d/S99gplv3-notice

   NOTE: It would also be a good idea to remove all references to this script in the different run levels such as rc3.d. This excersize is left to the user.

3. Now you can move the script from the /etc/init.d directory to the /etc/profile.d directory.

   mv /etc/init.d/gplv3-notice /etc/profile.d/gplv3-notice.sh

   NOTE: In the above move operation we also renamed the file to end in .sh. This is because the profile script looks for all files in the /etc/profile.d directory ending in .sh to run.

   NOTE: The gplv3-notice script is written without start/stop routines because it performs the same actions no matter what. For an init script with start/stop routines you would need to either

   • Change the script to default to the start or stop operation you wanted
   • Write a wrapper script that goes in /etc/profile.d and calls the script in the /etc/init.d directory passing the appropriate start or stop option

4. At this point we should now have the system configured to run the gplv3-notice.sh script on login. We can check that without doing a full reboot by logging out with exit and logging back in as root

   exit

   root

5. You should see output like the following

   

6. In the above output you see that we now get the GPLv3 content notice at login. You can also see that the other change we added into the /etc/profile script that prints "You have logged in as root" is still executed as well. Now reboot the board so we can verify that the GPLv3 notice script is not run on boot (NOTE: it is still run when the board is shutting down on reboot)

   init 6

7. When the board reboots you should notice that the message was not printed. Go ahead and login to the board as root and you should see the message printed.
8. Lastly, if you have a network connection you can verify that these login changes will happen even when logging in over the network. Obtain your EVMs IP address using the ifconfig command.

   ifconfig

   You should see output like the following which will tell you the IP address of your board.

   

9. From your Linux host you can login over the network using either SSH or Telnet since both protocols are supported in the SDK file system.

   SSH

   ssh root@<ipaddr>

   If prompted select yes to continue connecting. Login with a blank password as usual.

   Telnet

   telnet <ipaddr> and login as root with a blank password as usual.

10. In both cases above you should have seen the same prints as when you login over the serial console.