I got sucessfully the boot-up of angstrom by NFS, but after appears "beaglebone login: ", appears: “nfs: server server.domain.name not responding, still trying” and then kernel panic after few seconds, anyone knows why?
ps.: I try to follow this tutorial: http://www.embeddedhobbyist.com/debian-tips/beaglebone-black/beaglebone-black-network-boot/
Do you have a serial debug cable ? If so pastebin the whole output of the debug console at bootup.
I’ve tried Angstrom over NFS with no luck as well. But when I changed the kernel and made rootfs with busybox, the NFS booted up happily. I think there are some bugs in the Angstrom kernel/rootfs.
I got the message early today, but is the same
U-Boot SPL 2013.04-dirty (Jun 19 2013 - 09:57:14)
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
OMAP SD/MMC: 0
mmc_send_cmd : timeout: No status update
reading u-boot.img
reading u-boot.img
U-Boot 2013.04-dirty (Jun 19 2013 - 09:57:14)
I2C: ready
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: No NAND device found!!!
0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net: not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot: 1 0
U-Boot# setenv ipaddr 192.168.0.21
U-Boot# setenv serverip 192.168.0.17
U-Boot# tftpboot 0x80200000 uImage-3.8.13
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.0.17; our IP address is 192.168.0.21
Filename ‘uImage-3.8.13’.
Load address: 0x80200000
Loading: *#################################################################
I have tried with a Debian rootfs(from armhf) and it works, i think that is a Angstrom problem too…
Thank you!
[ 20.282997] nfs: server 192.168.0.17 not responding, still trying
A few possible problems. hosts.allow is the first that comes to mind. If you have in fact done this step then perhaps something about Angstrom is different. Hence why I suggest in that blog post that you use Debian.
Whatever the cause, the server is not responding to your client. So you need to double check everything, and make sure for a fact that the BBB can access that server, and that NFS share. TFTP is definitely working.
Also would be good to see your uEnv.txt file. From what I am seeing during the uboot process, you’re not using the uEnv.txt environment variables that I have on that page.
Also, there is the possibility that not all NFS drivers are statically compiled into the kernel with Angstrom. This is a requirement. I Have gone though menuconfig when building the kernel for RCN’s Debian, and everything seemed to be in place without having to touch a thing. I can not say this for any stock Angstrom.
I don`t use uEnv.txt, only U-Boot cmd line. I try with others rootfs and it works with Arch too, the same kernel (compiled 3.8.13 from beaglebone git)… I think that is an incompatibility at module initialization or during network configuration after bootup, anyway i will play with custom rootfs for a while.
ps.: i don`t know yet how init.d works but i found a archive in Angstrom /etc/init.d/connman with this:
#!/bin/sh
DAEMON=/usr/sbin/connmand
PIDFILE=/var/run/connmand.pid
DESC=“Connection Manager”
if [ -f /etc/default/connman ] ; then
. /etc/default/connman
fi
set -e
nfsroot=0
exec 9<&0 < /proc/mounts
while read dev mtpt fstype rest; do
if test $mtpt = “/” ; then
case $fstype in
nfs | nfs4)
nfsroot=1
break
;;
*)
;;
esac
fi
done
do_start() {
EXTRA_PARAM=""
if test $nfsroot -eq 0 ; then
$DAEMON $EXTRA_PARAM
fi
}
do_stop() {
start-stop-daemon --stop --name connmand --quiet
}
case “$1” in
start)
echo “Starting $DESC”
do_start
;;
stop)
echo “Stopping $DESC”
do_stop
;;
restart>force-reload)
echo “Restarting $DESC”
do_stop
sleep 1
do_start
;;
*)
echo “Usage: $0 {start|stop|restart|force-reload}” >&2
exit 1
;;
esac
exit 0
maybe this is the problem…
Thank you
Hi Marcel,
Could be as easy as changing
nfsroot=0
to
nfsroot=1
It seems reasonable to me, but I honestly do not know for sure.
Doesn’t work
Summary o rootfs:
Angstrom - disconnect nfs after init
Ubuntu - error to mount nfs
Debian - works
Arch - works
Fedora - disconnect nfs after init
Custom(busybox) - works
So it seems to me that Angstrom, Ubuntu, and fedora all have something in common. All joking aside, assuming all needed NFS modules are compile statically into the kernel. hmmm . . .
Angstrom doesnt use /.etc/network/interfaces the way Debian does ( Angstrom uses connman doesnt it ? ) So I am suspecting ( but also half guessing ) this could be an interface not getting the correct IP after bootup/mounting rootfs. Fedora, i know nothing about, but thought Ubuntu did use /etc/network/interfaces, but I have no used Ubuntu in years ( and it seems to change for the worse with each iteration ). Or, possibly udev related ?
This has to be fixable, and I really would like to think this is not module related unless as stated above it would be because they’re not statically compiled into the kernel. I tried checking my own Angstrom on the eMMC, but could not find the kernel related .config file for 3.8.8 on the eMMC. The only other thing I can think that all 3 may have in common is that they may use a common ABI . . . but yeah thats a bit of a stretch . . .
Doesn't work
Summary o rootfs:
Angstrom - disconnect nfs after init
Ubuntu - error to mount nfs
I do not know your exact test setup as you didn't mention if your
still using an 'initrd', but usually with ubuntu, if you disable the
'initrd' it then works (or did so in a previous version)...
Debian - works
Arch - works
Fedora - disconnect nfs after init
Custom(busybox) - works
Regards,
ubuntu uses "/etc/network/interfaces"... The biggest difference
between ubuntu and debian is the init system.
ubuntu uses upstart, whereas debian uses the classic sysvinit
Regards,
"If your NFS root freezes during boot with a message similar to:
nfs: server 192.168.0.251 not responding, still trying
Then it is possible the network connection used by the NFS connection has been re-configured. On Angstrom, this connection is re-established by the Connection Manager (ConnMan.) To quickly overcome this problem, remove /lib/systemd/system/connman.service from your rootFS."
From Beyondlogic
"If your NFS root freezes during boot with a message similar to:
nfs: server 192.168.0.251 not responding, still trying
Then it is possible the network connection used by the NFS connection has been re-configured. On Angstrom, this connection is re-established by the Connection Manager (ConnMan.) To quickly overcome this problem, remove /lib/systemd/system/connman.service from your rootFS."
From beyondlogic
Wow.
I was dealing with issues trying to boot an NFS exported nfsroot with Angstrom Linux… and was having this exact same issue. It would hang after booting to the login and display:
nfs: server not responding, still trying
removing /lib/systemd/system/conman.service does fix this problem.
I am replying here as this is the only place I saw this mentioned.
So, if you are having trouble booting from barebox into a custom kernel via tftp and attempting to mount the rootfs over nfs using Ångström linux… (either don’t use angstrom or delete the connman.service)
You don’t have to delete connman for NFS to work. Just tell connman to stop managing eth0. This is required when using systemd.
Regards,
John