Beaglebone Black init scripts, default gateway,and ntpdate

Beaglebone Black Running init scripts

So, this afternoon I found a nifty tidbit of information on the Beagleboard google groups, and was eager to try it out. Namely a single $optargs parameter to disable hdmi on the Beaglebone black during bootup. This was great I thought, because our project has use for those pins, but no use for hdmi at all. Feeling good about myself, I went ahead and made the changes to uEnv.txt, and issued the ominous shutdown now -r command ( Yes, I actually do cringe every time I make changes to uEnv.txt, and then reboot ).

Needless to say, I was greeted by oblivion once again . . . and to make matters worse for the next hour no matter what changes I made to the uEnv.txt boot file. Nothing worked. After a few reboots and observing the output of the serial debug console, I came to the conclusion that dhcp for some reason was no longer working on our network. Finally realizing that dhcp was no longer an option, and that I would have to find a way to take care of the name resolution issues that had plagued me previously. That is to say, I had to manually upon reboot add a route to our gateway to the internet on our LAN. Do not ask me why as I am not a network expert, but when given a static ip during the booting process, uboot ( uEnv.txt ), and Debian ( /etc/network/interfaces ) do not play very nicely on our network.

The cause.

uEnv.txt:

bootdelay=1
ipaddr=192.168.0.3
serverip=192.168.0.2
static_ip=192.168.0.3:192.168.0.2:182.168.0.1:255.255.255.0:arm
rootpath=/home/william/rootfs,rsize=8192,wsize=8192
console=ttyO0,9600n8
optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
loadtftp=tftpboot 0x80200000 /boot/uImage; tftpboot 0x815f0000 /boot/am335x-boneblack.dtb
netargs=setenv bootargs console=${console} ${optargs} root=/dev/nfs nfsroot=${serverip}:${rootpath},vers=3 rw ip=${static_ip}
uenvcmd=setenv autoload no; run loadtftp; run netargs; bootm 0x80200000 – 0x815f0000

/etc/network/interfaces

# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp

On the nfs server – /etc/exports

/home/william/rootfs 192.168.0.0/24(rw,sync,no_root_squash,no_subtree_check)

Again, I am not an expert when it comes to networks, but I do know more than enough to get myself out of trouble, usually. The problem here is that this had been working for a few days now. In case this is not already obvious, the gateway’s ip was 192.168.0.1, the nfs servers ip was 192.168.0.2, and the Beaglebone Black’s ip was 192.168.0.3. These ip addresses are actually fictitious, but close enough for an explanation. Anyhow, the problem I was noticing went like this: The Beagelbone Black would pull in the kernel using ipaddr and serverip. Once the kernel finished loading, the rootfs would start loading up to the point where I would have to assume /etc/network/interfaces loaded( because the dhcp “server” was not giving an ip ). Then, everything would stop. Beagelbone Black forever stuck in limbo. Once this sunk in I decided to go ahead and change /etc/network/interfaces to reflect a static IP as such:

# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.0.3
netmask 255.255.255.0
gateway 192.168.0.1

So with that out of the way, the Beaglebone Black booted right up just fine. With that problem solved I was yet again faced with another. Pings outside of our LAN were coming back Destination unreachable. Issuing the command:

/sbin/route add default gw 192.168.0.1 dev eth0

Brought back my name resolution.

The fix( hack ? ) Killing two birds with one stone.

It had been a while since I had written, and used an init script. So no big surprise here I was back to yet another google session trying to figure out why what I knew wasn’t working. As it turns out, since Debian Squeeze, there is a new method for writing, and “installing” init scripts. To make this a short(er) story let me just go ahead and gives steps and an example of what I had to do.

Create some file, and edit it accordingly. In my case test

touch /etc/init.d/test && nano /etc/init.d/test

And in the file we put . . .

#! /bin/sh

### BEGIN INIT INFO
# Provides: test
# Required-Start: $all
# Required-Stop: $all
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Short script description
# Description: Longer script description.
### END INIT INFO
case “$1” in
start)
/sbin/route add default gw 192.168.0.1 dev eth0
/usr/sbin/ntpdate pool.ntp.org
;;
stop)
#no-op
;;
*)
#no-op
;;
esac

exit 0

Then we must make the file executable, so we issue the command:

chmod +x /etc/init.d/test

Followed by the new method of installing the service. Do note the first command tests the file, and the second command actually installs the file as a service.

insserv -n /etc/init.d/test
insserv /etc/init.d/test

Viola ! Now we have our default gateway to our router setup at boot. As an added bonus, I’ve added the ntpdate command pointing to a standard ntp server so no more out of sync times. Do also note that the comments at the head of the file under #! /bin/sh are necessary. For more information you can read about it here. For these commands to take effect the system needs to be rebooted. However these command can be entered manually if there is no need for an immediate reboot, and these commands will persist the next time you do. As always, for additional information google is your best friend. Hopefully this blogpost will come in useful for some of you as well. For any further questions, or comments. Feel free to leave a comment below.

Beaglebone Black init scripts, default gateway,and ntpdate
Tagged on:

One thought on “Beaglebone Black init scripts, default gateway,and ntpdate

  • July 2, 2013 at 12:17 pm
    Permalink

    So, after getting this all working and setup, it seems I had the gatewayip set to 182.* . . . which would of course fail to find a gateway if it is on 192.168.0.0 . . . Needless to say, I am a little embarrassed about this, but no one is perfect, which definitely includes me. So dhcp should infarct work on our network again once I correct this, but honestly I am in no big hurry to fix it. As this setup is only to help facilitate what I consider a proper development environment. Read: Having the ability to easily and non destructively change the rootfs, and kernel when I wish.

    In either case, I think this exercise was still something useful to know. At least for myself. YMMV

Comments are closed.