# FreeBSB 12 Boot halts on RPi 3



## oitdmser (Jan 5, 2019)

I have a Raspberry Pi 3 (B+ i think). Been using FreeBSD 12 on a 64GB SD card successfully for several days as I work to get bitcoin core and electrum running. Many successful reboots without substantial issues per se, other than power issues related to the attached HDD. For the purpose of troubleshooting I have the external HDD disconnected. Note that boot halts at the same place regardless, right here at `ue0: Ethernet address: XX:XX:XX:XX:XX`. I'm not sure if it loads ethernet successfully then halts trying the next step or if there's something about the network that is making it halt.


I've tried booting into single-user mode but am not having success. I'm told to halt the boot loader as it counts down and type `boot -s` but I'm not sure if I should do that at the first U-Boot loader (the one that pauses for 2 seconds then quickly progresses) or the second boot loader (the one the pauses for 10 seconds). Trying `boot -s` at the `U-Boot>` prompt simply returns the following error:

First boot loader (U-Boot):

Second boot loader:


Notes:
• Boot stops here regardless of whether ethernet cord is plugged in.
• My router is set to always assign the same IP to that MAC address, so I know what the IP should be. Pinging that IP address fails
• I have tried using `boot -s` from the second boot loader when I was experimenting earlier and it simply booted normally, it did not boot into single-user mode.
• I recently edited the /tmp ramdisk size from 50MB to 100MB. I did this on the fly and had no problems at the time.
• Swapping the SD card into a second, identical model, known-good RPi3 results in the same problem, likely ruling out a hardware issue on the RPi.
• I do have NTP running FWIW. I enabled the two NTP options in rc.conf, `ntpd_update=YES`and `ntdpd_sync_on_start=YES`. Is it possible bootup is stalling because ntpd can't get a time because networking isn't up yet?

Questions:

1) What are my next steps to troubleshoot?
2) If I do need to boot to single-user mode, how is that accomplished?


----------



## complexinput (Jan 5, 2019)

1. When it gets stuck at ethernet address, try "Ctrl-T" for more info and "Ctrl-C" to force close what it's stuck on.
2. I could never get hdmi/serial to work so I can't really help you here but I think the boot menu is disabled by default on the RPI.

```
root@raspberry:~ # cat /boot/loader.conf
..
# Disable the beastie menu and color
beastie_disable="YES"
loader_color="NO"
..
```


----------



## acheron (Jan 5, 2019)

It's probably growfs, either wait a large amount of time or remove growfs_enable in rc.conf


----------



## Spartrekus (Jan 5, 2019)

I did not manage to get working the 12.0 rpi freebsd

the one of my testing server is:
$ uname -a
FreeBSD generic 13.0-CURRENT FreeBSD 13.0-CURRENT r342020 GENERIC  arm64

FreeBSD generic 13.0-CURRENT FreeBSD 13.0-CURRENT* r342020 GENERIC  arm64 works very well.*

last pid:  5488;  load averages:  0.05,  0.01,  0.00    up 1+01:32:21  09:03:56
32 processes:  1 running, 31 sleeping
CPU:  0.0% user,  0.0% nice,  1.4% system,  0.0% interrupt, 98.6% idle
Mem: 5848K Active, 574M Inact, 23M Laundry, 161M Wired, 97M Buf, 143M Free
Swap:

if possible, give a try for 13.0, it may likely be working.

Actually; I would be pleased to see 11.2 and 12 work well too on pi.

$ less /etc/rc.conf
hostname="generic"
ifconfig_DEFAULT="DHCP"
sshd_enable="YES"
sendmail_enable="NONE"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"
growfs_enable="YES"
/etc/rc.conf (END)


----------



## oitdmser (Jan 5, 2019)

complexinput said:


> 1. When it gets stuck at ethernet address, try "Ctrl-T" for more info and "Ctrl-C" to force close what it's stuck on.
> 2. I could never get hdmi/serial to work so I can't really help you here but I think the boot menu is disabled by default on the RPI.
> 
> ```
> ...


Both Ctl-T and Ctl-C do nothing when it is frozen, no response. Ctl-Alt-Del is the only combo that works


----------



## oitdmser (Jan 5, 2019)

acheron said:


> It's probably growfs, either wait a large amount of time or remove growfs_enable in rc.conf



This is interesting. As I've mentioned before, I've successfully rebooted multiple times previously. Is there something about growfw that would make it stall, even after it has done it's thing? Unfortunately I don't have a machine that can r/w UFS without a significant amount of work so I can't edit the rc.conf until it boots. How long are we talking here? Hours? Days?


----------



## oitdmser (Jan 5, 2019)

complexinput said:


> 1. When it gets stuck at ethernet address, try "Ctrl-T" for more info and "Ctrl-C" to force close what it's stuck on.
> 2. I could never get hdmi/serial to work so I can't really help you here but I think the boot menu is disabled by default on the RPI.
> 
> ```
> ...


I managed to boot to another drive and edit loader.conf:
`beastie_disable="NO"
loader_color="YES"`

The `beastie_disable="YES"` allowed me to boot to single user mode, the `loader_color="NO"` seems to have enabled more verbosity in the log. It then became apparent it was trying to mount the external USB HDD that I had added to /etc/fstab. Annoying that with beastie disabled it did not give any error. Regardless, I added `noauto` to the fstab entry and rebooted, but it still failed to mount the drive, so I tried commenting out the entire entry for my hdd. This allowed it to boot to a login prompt.


----------



## Phishfry (Jan 5, 2019)

oitdmser said:


> How long are we talking here? Hours? Days?


At most 20 minutes for `growfs` on a large microSD card. That has been my experience.



oitdmser said:


> It then became apparent it was trying to mount the external USB HDD that I had added to /etc/fstab.


Good Catch. There is another post regarding a similar problem on the forum.
https://forums.freebsd.org/threads/...with-usb-pendrive-inserted.68230/#post-407684


----------

