Great diagram - thanks @bakercp!
Getting a raspberry pi set up to cross-compile and NFS boot using the method described here: github.com/twobitcircus/rpi-build-and-boot
By the way, the IP address on the Raspberry pi is a copy paste error. The raspberry pi’s IP address is
10.0.0.101 in the build-and-boot setup.
thanks for the diagram, that certainly helps. But I’m still stuck in the same place. My directory looks like yours (minus the unzipped openFramworks folder), and the alias has the same info as yours as well.
the Pi is connected to the mac with an ethernet to firebolt adaptor. it’s powered by a mini usb plug and it’s power light is lit up red. there’s an empty 16 SD card in there and a wifi dongle. Still my network preferences look like in my screenshot above, saying ‘Cable Unplugged’. Is there something wrong with the connection, or is the
Error mounting /opt/raspberrypi/boot: image.img: No such file or directory unrelated?
does the raspberry already need to have an image on the card for it to be recognized on the network?
PS. @bakercp let me know if you’re on campus today and I could show you my setup.
sorry, the full error is
Error mounting /opt/raspberrypi/boot: /vagrant/image.img: No such file or directory
should there be an
Yeah, there should be. Try this solution:
Then make sure your virtual machine is stopped (something like
vagrant halt) then do
vagrant provision again …
oh wow that totally worked. thanks!
Yeah, I forgot I had a similar issue …
made one or two steps forward. so now the raspberry has its card, is running and is recognized on the network. I can see it boots off my computer as all its lights are going on only if the ethernet is plugged in. But I still struggle with the concept of where it’s running.
the next step is (and I could see @abrahamavnisan had a similar problem, but couldn’t figure out how you guys handled it):
- Put the card in a Pi, connect it to the hard-wired network, and turn
it on. If this is a fresh card, you’ll be dropped into raspi-config.
- Enable ssh in the advanced options Do not “expand the filesystem.”
- Finish raspi-config and reboot.
where will I be dropped into raspi-config? do I need to hook up the Pi to a screen, or should that happen in a
vagrant ssh shell? Where do I actually access the Pi if it is running on the NFS boot?
vagrant ssh and then try to get to the Pi via
ssh email@example.com I get this:
`ssh: connect to host 10.0.0.101 port 22: Connection refused``
I assume that this happens because I can’t follow Step 2 from the quote above and actually enable ssh on the Pi.
Update: got it running so far (it’s installing openFrameworks at the moment). I connected the Pi to a screen and keyboard and went through the config. To avoid this in the future: would there be a way to run through this from the mac/linux platform without having to connect the Pi to a screen?
Hm … I just followed the instructions and ssh’d into the pi w/ o a screen, etc.
But to run the vagrant setup for the pi, it’s easier to do it all from within the virtual machine.
Because it was a new card, I had to go through the raspi-config and
enable ssh otherwise I got
connection refused when I tried to
ssh firstname.lastname@example.org from my mac. I was only able to go through that setup with a screen.
I just registered to leave this here for the next guy with similar problems. I was following both the guide in the repository and details in this forum and I kept having kernel panics and errors that didn’t let the RPI boot, like:
... smsc95xx 1-1-.1:1.0 eth0: kevent 4 may have been dropped (<--- many like this one) .... devtmpfs: error mounting -2 ... Kernel panic - not syncing: No working init found. Try passing init= option to kernel ... ... ---[ end Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation...
The problem was that I was connecting my Raspberry Pi to my mac via a Thunderbolt ethernet adapter. Every time that I unplugged the RPI to reboot it / change params / reflash the SD / etc., the Thunderbolt ethernet adapter detected that there was no device at the other end so it disconnected. When I plugged the DC connector again, the RPI booted faster than the Thunderbolt ethernet adapter, so it could still not find the boot image in my mac.
The first solution for me was to reboot the RPI using a clip in the “RUN” pads, you can see where they are located here: https://blog.adafruit.com/2014/10/10/making-a-reset-switch-for-your-raspberry-pi-model-b-run-pads-piday-raspberrypi-raspberry_pi/
But later I have found a more elegant solution. You can add a
rootdelay parameter that waits X seconds before mounting the nfs filesystem and gives time to the Thunderbolt ethernet adapter to turn on (found here: http://www.reactivated.net/weblog/archives/2005/11/booting-linux-userland-from-an-external-usb-flash-disk/)
cmdline.txt file ends up being this:
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootdelay=10 rootwait ip=10.0.0.101:10.0.0.1:10.0.0.1:255.255.255.0:rpi:eth0:off root=/dev/nfs rootfstype=nfs nfsroot=10.0.0.1:/opt/raspberrypi/root,udp,vers=3 smsc95xx.turbo_mode=N
Hopefully this will save somebody 2 days flashing SD cards
So you were connected to the a thunderbolt ethernet adapter? Thanks for the report!
Yes! I just edited my post to make it clear
(I don’t know if this is the right place to post this)
Now I see that I cannot connect to the internet from the RPI. How should I do it?
Replying to myself, I had to do this to route all traffic from the RPI to the internet (Found in https://support.hidemyass.com/hc/en-us/articles/202721486-Using-Linux-Virtual-Machine-instead-of-a-router-for-VPN):
In your Ubuntu VM, assuming that
eth1: your RPI connected via ethernet cable
sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward" sudo iptables -A FORWARD -o eth0 -i eth1 -s 192.168.0.0/24 -m conntrack --ctstate NEW -j ACCEPT sudo iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT sudo iptables -A POSTROUTING -t nat -j MASQUERADE sudo iptables-save | sudo tee /etc/iptables.sav
uncomment this line in /etc/sysctl.conf