BSD host of issues on reboot from fresh install

[MNtinkerer]

Greetings. The title says it all, sort of. I cannot get FreeBSD to boot after reboot. Gives me this error:

[*]
mountroot: waitingMounting from ufs:/dev/ufs/rootfs failed with error 19.


My system specs:

RockchModel: Pine64 RockPro64 v2.1
U-Boot TPL 2020.10 (Jan 07 2021 - 05:00:17)
FreeBSD-13.0-CURRENT-arm64-aarch64-ROCKPRO64-20210107-f2b794e1e90-255641.img.xz (Listed on this page:https://download.freebsd.org/ftp/snapsho...AGES/13.0/ )
Image uncompressed and written to eMMC module using dd

The full boot to kernel panic is posted at https://pastebin.com/BkxGCjsJ

Line 364 is where the error is printed.

The install was fresh and booted fine. The image gives you root with "root" as the password, and "generic" as the hostname. I added 2 users, changed the host name, and rebooted. Got this error several times before trying a fresh install on an SD card, then experiencing the same error on reboot. Reflashed both the SD card and eMMC module a couple of times each, did the above setup, then rebooted with the same result. According to another forum for TrueNAS other's were experiencing this and the issue was their BIOS or the newest version of BSD. You can read more about it there:

https://www.truenas.com/community/thread...-19.13620/

I am entirely new to BSD in any version but would like to start with running a headless FreeBSD on my home lab. I will take a step back and try previous versions but any help in diagnosing this, or manually booting, via the prompts would be appreciated. BSD is way over my head but this just seems like an exciting place to start. Thank you for your attention!


#############################################################################################################

UPDATE

#############################################################################################################


I switched images and found the one posted on December 24th, 2020 works even after reboot. (The image I was using was posted on January 7, 2020. I was confused and thought there was only one RockPro64 image. They have the same beginning and similar ends in the long link.

The working image: FreeBSD-13.0-CURRENT-arm64-aarch64-ROCKPRO64-20201224-3cc0c0d66a0-255241.img.xz

[zer0sig]

Thanks, I'm not doing much with my RockPro64 other than letting it sit there and wait for me to implement something useful, and a FreeBSD based light NAS/media server would be slick. Was going to also use it as a media-friendly desktop but I'm guessing that is probably not very advanced in FreeBSD from my experience, though I wouldn't mind being surprised.

[MNtinkerer]

Thanks, I'm not doing much with my RockPro64 other than letting it sit there and wait for me to implement something useful, and a FreeBSD based light NAS/media server would be slick. Was going to also use it as a media-friendly desktop but I'm guessing that is probably not very advanced in FreeBSD from my experience, though I wouldn't mind being surprised.

Would you be using native BSD tools or adapting Linux tools that are binary compatible? While I was searching for a solution for my original problem I remember reading someone either in the FreeBSD or Pine64 forums had put together a FreeBSD w/desktop OS for the PBP.

For a media file server I am able to stream 1080p from a RockPro64 host using samba with an Ubuntu host from an ayufan image, to several devices simultaneously, something entirely within range of a FreeBSD host. My bottleneck is the HDDs since they are encrypted and configured with RAID6 and through a Marvell chipset on the PCIe to SATA card it is  limited to 30Mbs. Without RAID that jumps up to about 100Mbs, I've never tried it without encrypted disks or using SSD. ZFS benchmarks on other architectures usually performs slower than RAID6 on read times but at 4K quality video one should be ok to feed at least one client, but likely 2 easily. When I migrate to a FreeBSD host I will likely not use encryption for my media files, it is just something I've always done out of habit. As a matter of fact, after reading your reply I started thinking about 4K since we just bought our 1st 4K television and most of our saved video is 720p or 1080p.

[ashleymills]

I've got a rockpro on order. When it arrives I'm going to try and set it up as a FreeBSD NAS and media server. I'll give it a go anyway.

FreeBSD works very well as a desktop machine. The ULE2 scheduler was actually designed with interactivity in mind, and I think it does a better job than the Linux kernel. For example, a stressed system will always context switch to a VT on FreeBSD but a stressed Linux system can completely freeze up. That's my experience of it anyway.

I had a FreeBSD machine connected to my TV for about 10 years until I needed netflix ( you can now run google chrome with the linuxulator easily in 13.0 with an Ubuntu base so I need to revisit this). I might be biased but it always felt like video playback in XBMC and youtube was smoother on the BSD machine compared to Manjaro which I followed up with.

Once ARM becomes Tier 1 on FreeBSD there won't be any need for this continuous image building. Has anyone tried building world on FreeBSD on the rockpro?

[ashleymills]

Running a NAS on FreeBSD will be easy, and the tools will work amazingly.

The desktop is going to be an issue because there isn't any drivers for the Mali GPU right?

[MNtinkerer]

Running a NAS on FreeBSD will be easy, and the tools will work amazingly.

The desktop is going to be an issue because there isn't any drivers for the Mali GPU right?

I hope so. Being completely new to BSD, and thus porting I feel like I just washed ashore on a Greek island with a guidebook to Spain written in Russian, but only able to understand English. To avoid the X-Y Problem I would like to host a Samba server on the FreeBSD version above (13.0 but am ok with porting a previous version if necessary) however when trying to update or install packages the machine throws an error stating there are no packages for my version. I am assuming this means I have to compile my own packages at this time, using a different system, then install them to the target machine, a RockPro64. I was hoping for a shortcut that doesn't involve spinning up a FreeBSD VM on my Debian machine, and trying there. Since FreeBSD 13.0 is the first to support RockPro64 I would like to start there but if I should take a step back and try porting 12.2 to the RockPro64 with the below linked tutorial as a rough guide, I'd be happy to spend the weekend trying. This machine would reside on a home network and be a dedicated Samba server, though I was hoping to use it as a test bed for other local services as I become more familiar with FreeBSD.

Web searches for tutorials have proven fruitless, at least specific to FreeBSD and RockPro64. This tutorial was written at a pace I can at least grasp the concepts of, trust the Bash commands are accurate, and learn from but it is for OpenBSD, and only covers porting the OS, not compiling shell utilities needed to do what I think I need to do. I haven't found anything helpful to discovering/deducing dependencies, organizing, compiling packages. I share the sentiment of this post when reading the Porters Handbook, that is to say the handbook flips between writing to an audience of beginners and making assumptions only the experienced will understand. I am happy to give back to the community once I know what I am doing, but found the Linux from Scratch project friendlier to the beginner, since it linked to topics outside of the scope but necessary to complete the project.

[ashleymills]

>>　I am assuming this means I have to compile my own packages at this time, using a different system, then install them to the target machine, a RockPro64.

Packages will be available for 13.0 for sure, but 13.0 isn't actually released yet.

How did you try and install packages BTW?

Have you tried compiling ports on the rockpro64? Ports is one of the benefits of FreeBSD, all the dependencies are managed for you.

Try this (as root)

Fetch and extract the ports tree (if you already have the ports tree run portsnap fetch update)

Code:

# portsnap fetch extract

Compile portmaster (compiling with portmaster makes dealing with dependencies better)

Code:

# cd /usr/ports/ports-mgmt/portmaster
# make install clean

There might be some dialogs to choose options, defaults are usually fine

Then you can install samba:

Code:

# cd /usr/ports/net/samba413
# portmaster

Sometimes there are tons of options for a port since it has zillions of dependencies, and it can be annoying to go through the dialogs when you want the defaults anyway. You can set BATCH environment variable to ignore setting options:

Code:

# setenv BATCH yes

(using the default shell or export BATCH="yes" if you have install bash)

Be interested to know how long it takes to compile ports directly on the RK3399. I compiled a few ports on a raspberry pi model B and it took a very long time.

Cross compiling for ARM isn't difficult. You can setup poudriere on a VM with FreeBSD (see for example, https://github.com/herrbischoff/cheatshe...6-howto.md) and that will setup a package repository on your VM that you can then use to build the packages on the x86 machine and install to the rockpro64. I'm going to try this now with my raspberry pi model B (my rockpro64 hasn't arrived yet).

Ashley

[MNtinkerer]

~#: pkg install update     pkg update
~#: pkg install upgrade   pkg upgrade
~#: pkg install samba     pkg samba* (whatever version number came up in search)
and so on, had mixed results but do not remember which outputs were related to which commands. 

Have you tried compiling ports on the rockpro64?

Not until your tutorial. I had to first update the machine time (~#: ntpd -g -u) then fetch and install the ports tree which took about 20mins where I am in the United States. 

Be interested to know how long it takes to compile ports directly on the RK3399

If I understand the output from the

Code:

portmaster

command from /usr/ports/net/samba413, with

Code:

setenv batch=yes

then it took about 1.5 hours to run from the portmaster command until the terminal output reached docbook-sgml installed and began working on iso8879. Or 1.5 hours to compile and install 12 ports that are dependencies of samba. Or 12/151 ports, including samba from the previously linked pastebin. I hope that gives you an idea of speed.

I will likely see samba through on the RockPro64, 2GiB ram, w/32GB eMMC module but try the tutorial on cross compiling on my AMD Ryzen 7 3700X machine, hosting Debian Buster (Linux). I also have a RockPro64 with 4GiB of memory, wonder if that makes a difference.

It is worth noting that according to TOP, the CPUs are fluctuating from 12-99% load, higher with the cc command and between 12-29% with python3 showing. It appears to be cycling between CPU0, 1, 2, 3 for the heavy work.

Thank you for taking the time to write your tutorial, it gave me a solid place to start and answered my questions on how dependencies are handled!

[ashleymills]

~#: pkg install update
~#: pkg install upgrade
~#: pkg install samba

pkg install update would try and install a package called "update"

The correct commands are

Code:

# pkg update
# pkg upgrade

But pkg upgrade does an update anyway, so you only need the latter to do upgrades.

I'm surprised the package install didn't work for samba, what's the output of:

# pkg search samba

[MNtinkerer]

~#: pkg install update
~#: pkg install upgrade
~#: pkg install samba

pkg install update would try and install a package called "update"

The correct commands are

Code:

# pkg update
# pkg upgrade

But pkg upgrade does an update anyway, so you only need the latter to do upgrades.

I'm surprised the package install didn't work for samba, what's the output of:

# pkg search samba

My apologies, I don't know why I reported "install" in there...printing out history and the syntax was correct. The system is now giving a different output than before when searching for packages. Before it would throw an error like it couldn't find any or none were available. It wasn't until trying to fetch the port tree that I realized the system clock was set to January 6th, 2021, and that was why the package search wasn't working. Got that fixed then when trying to install sudo (sudo-1.9.5pl), the system gave a version error and prompted to ignore the mismatch and continue [Y/n]. Now when running pkg search samba the printout shows:

p5-Samba-LDAP-0.05_2          Manage a Samba PDC with an LDAP Backend
p5-Samba-SIDhelper-0.0.0_3    Create SIDs based on G/UIDs
samba-nsupdate-9.16.5          nsupdate utility with the GSS-TSIG support
samba411-4.11.15              Free SMB/CIFS and AD/DC server and client for Unix
samba412-4.12.9_1              Free SMB/CIFS and AD/DC server and client for Unix
samba413-4.13.1_1              Free SMB/CIFS and AD/DC server and client for Unix

I believe the problem was the system clock, since I unplug the RockPro64 after poweroff. The one I have in production with an ayufan produced Ubuntu image has sat several days unplugged but seemingly updates the system time as soon as it is back on. Both devices do not have the optional battery pack, but have always had ethernet access to the internet. Will have to set ntpd to run at start up if this is going to continue with a FreeBSD host. The long term fix is to build a custom UPC and leave the NAS on all the time.

BTW, 13.25 hours since running portmaster and we are at:


[1255/5364] /usr/bin/c++ -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/ExecutionEngine/JITLink -I/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/ExecutionEngine/JITLink -Iinclude -I/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  -DNDEBUG -isystem /usr/local/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  -DNDEBUG -isystem /usr/local/include  -fno-exceptions -std=c++14 -MD -MT lib/ExecutionEngine/JITLink/CMakeFiles/LLVMJITLink.dir/JITLinkMemoryManager.cpp.o -MF lib/ExecutionEngine/JITLink/CMakeFiles/LLVMJITLink.dir/JITLinkMemoryManager.cpp.o.d -o lib/ExecutionEngine/JITLink/CMakeFiles/LLVMJITLink.dir/JITLinkMemoryManager.cpp.o -c /usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/ExecutionEngine/JITLink/JITLinkMemoryManager.cpp