FreeBSD 11.1 on Raspberry PI 2b hangs after 'random: unblocking device'

Koen Martens

Koen Martens

Hi,

I've got a raspberry pi 2b running Freebsd 11.0. Works fine (except keeping world up to date is a pain for a non-tier-1 architecture), but given that 11.0 is EOL I need to upgrade to 11.1. So I built a new image with crochet from branch releng/11.1 in git. However, this image fails to boot properly. Last message it prints is 'random: unblocking device'.

On the 11.0 image, what follows the 'random: unblocking device' message is the smsc driver initialization (network interface). So might this be an issue with the 11.1 version of the smsc driver? I wanted to see if I can boot verbosely ('boot -v'), however uboot doesn't seem to initialize the keyboard so I can't input anything.

I tried getting the raspberry pi 2 image from ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.1/, but that won't even get past uboot. It's a bit hard to see why, because the video is off and the left 10 characters of the output are not visible.

It's been running FreeBSD for the past year, and I really like to continue doing so. But as it is, the maintenance burden of running FreeBSD on a non-tier-1 architecture is no fun anymore. I'm probably going to change it to Linux soon, but perhaps there's a simple thing I can do to get 11.1 to work and keep using FreeBSD. If not, it's gonna be linux because I don't want to run this thing with an EOL os that has a vulnerable openssl library.

Thanks,

Koen
 
Hi folks, thanks for the replies. I have the pi hooked up to a monitor directly, sometimes it does eat the left bit, sometimes it doesn't. I've always had this with pi's on different monitors/tv's, whether it's running FreeBSD or Linux. Technology eh...

Anyway, back to the real problem I had. One thing I didn't mention: i take the image from crochet, then mount that through mdconfig and replace rc.conf, resolv.conf etc and add some other customisations (such as the /usr/local/etc/pkg config to point at my poudriere repo). Oddly enough, the customized image won't boot with the mentioned issue, yet the 'raw' image directly from crochet without any customizations boots fine. So i'm now booting that image and then making the customizations on the live system, instead of mounted through mdconfig. So far so good. Apparently, something I do when customizing the image through mdconfig introduces something bad.

Ps: about growfs, the raspberry2 board config in crochet doesn't have growfs_enable in the default rc.conf, nor do i have it in the rc.conf that i put on it when I customized the image.
 
Thanks again for all the replies. Indeed, I should start using the overlay directory, support for pre-installing packages seems interesting too!

However, now I run into the next hurdle. Since a few days, poudriere is unable to compile the binary packages, with a cryptic error message:

Code: 
[00:00:11] ====>> Error: databases/py-pymysql depends on nonexistent origin 'devel/py-setuptools@py27'; Please contact maintainer of the port to fix this.
[00:00:27] ====>> Error: devel/scons depends on nonexistent origin 'devel/py-setuptools@py27'; Please contact maintainer of the port to fix this.
[00:01:13] ====>> Error: net/samba44 depends on nonexistent origin 'devel/py-iso8601@py27'; Please contact maintainer of the port to fix this.
[00:01:13] ====>> Error: Fatal errors encountered calculating dependencies

UPDATING mentions something about python packages:

Code: 
  Ports using Python via USES=python are now flavored.  All the py3-* ports
  have been removed and folded into their py-* master ports.

  People using Poudriere and binary packages do not have to do anything.

  For other people, to build the Python 3.6 version of, for example,
  databases/py-gdbm, you need to run:

   # make FLAVOR=py36 install

So 'people using Poudriere ... do not have to do anything', so compiling python packages with poudriere is broken now?
 
Koen Martens said:
However, now I run into the next hurdle. Since a few days, poudriere is unable to compile the binary packages, with a cryptic error message:

Code: 
[00:00:11] ====>> Error: databases/py-pymysql depends on nonexistent origin 'devel/py-setuptools@py27'; Please contact maintainer of the port to fix this.
[00:00:27] ====>> Error: devel/scons depends on nonexistent origin 'devel/py-setuptools@py27'; Please contact maintainer of the port to fix this.
[00:01:13] ====>> Error: net/samba44 depends on nonexistent origin 'devel/py-iso8601@py27'; Please contact maintainer of the port to fix this.
[00:01:13] ====>> Error: Fatal errors encountered calculating dependencies

[chomp]

So 'people using Poudriere ... do not have to do anything', so compiling python packages with poudriere is broken now?
Click to expand...

I know nothing about Poudriere, but I fixed my portupgrade errors very similar to yours above by resetting the pkg origin thus:

pkg set -o devel/py27-setuptools:devel/py-setuptools

Without checking, a similar fix for
devel/py-iso8601@py27
Click to expand...
is most likely also available.
 
trev said:
I know nothing about Poudriere, but I fixed my portupgrade errors very similar to yours above by resetting the pkg origin thus:

pkg set -o devel/py27-setuptools:devel/py-setuptools

Without checking, a similar fix for is most likely also available.
Click to expand...

Turns out it was a rather simple fix. By default, pkg installs packages from the quarterly repo which has version 3.1.2 of poudriere. However, the new flavored ports are only supported in 3.2.x, so I installed poudriere from ports and things were ok again. Apparently, I could also have opted to install poudriere from the 'latest' pkg repo, which also carries 3.2.2.
 
With the crochet board /overlay directory you must build the final directory locations.
For example for dns/dnsmasq I create the whole directory structure if it does not exist.
/overlay/usr/local/etc/dnsmasq.conf
This is the same on the NanoBSD /Files directory which serves the same overlay function.
 
Is there any update on this? I have the same problem (hanging after random: unblocking device) with

FreeBSD-11.1-STABLE-arm-armv6-RPI2-20180307-r330605.img
 
Just for completness you are trying with the RaspberryPi 2B Revision 1.1 correct?
There is a RPi2B Revision 1.2 that uses a different CPU.
Check your board to make sure. Its silkscreened on the top.
 
hello,
I've the same problem with some img files (armv6 with shasum) on my RPI 2 b , decline with this new term : "raspbsd" on stable/11 release.
I'm beginner on freebsd and the others distributions like 'linux' don't disturb me for this part of use (RPI).

I used 'unxz" and 'dd' commands for create my microsdcard with two partitions ('fat' and 'ufs').
But "u-boot" is booting nothing : black screen and only red led on my rpi.
Would I edit config.txt on my boot partition for adjust some devices detection like monitor or others configurations ?

Thanks
 
Nigel Horne said:
Is there any update on this? I have the same problem (hanging after random: unblocking device) with

FreeBSD-11.1-STABLE-arm-armv6-RPI2-20180307-r330605.img
Click to expand...

I have the same problem.

And in my case I have a RPI 2 Model B V1.1 and use the img :

FreeBSD-11.1-STABLE-arm-armv6-RPI2-20180412-r332428

And make the same...

Which img use correct with RPI 2 Model B V1.1 :
  • FreeBSD-11.2-PRERELEASE-arm-armv6-RPI-B-20180420-r332802.img
Or This :
  • FreeBSD-11.2-PRERELEASE-arm-armv6-RPI2-20180420-r332802.img

Thanks a lot...
 
Right after the "random: unblocking device" debug message, the kernel looks at USB or other storage to set up a root mount. I found on one Raspberry Pi device, that the USB wasn't working properly due to low voltage. This caused the Pi2 to hang with the "unblocking device" message being the last message displayed. Increasing the power supply voltage to 5.1 volts fixed the issue. I think that I've read about similar results on the Pi forum, when the power supply was noisy. Of course other things could prevent the rootfs from mounting. The Pi has a dedicated SD bus, but low voltage might cause issues with that as well (I don't know at what level).

There are probably timeouts in the kernel (waiting for USB, etc). Since USB was known to be sometimes fiddly on the Pi2, it could be that the timeouts need to be tweaked.
 
Hi.

Thanks a lot.

A trying with power to 5.1 volts and the message is the same.

I dont know where is the problems.

Thanks a lot for all.
 
The USB OTG chip used on one or more of the Raspberry models was known to have issues when high speed and low speed USB devices were mixed and used simultaneously. So, another thing you could try is to unplug all the USB devices that you have plugged into the board, to see if that makes a difference.
 
You must log in or register to reply here.
Back
Top