Raspberry Pi 2

Booted it and managed to run it for a short while before it went into panic, and after that it panics quite frequently. I'll get a screen shot next time. Not very stable currently. Is there any chance to get the 10-STABLE running on the Raspberry Pi 2?
 
Bex: I get a panic after writing something bigger than a few bytes to the SD card. Do you get this panic as well?
Code: 
sdhci_bcm0-slot0:  Controller timeout
sdhci_bcm0-slot0: ============== REGISTER DUMP ==============
sdhci_bcm0-slot0: Sys addr: 0x0067ae00 | Version:  0x00009902
sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt:  0x0000001a
sdhci_bcm0-slot0: Argument: 0x02617d40 | Trn mode: 0x0000193a
sdhci_bcm0-slot0: Present:  0x01ef0106 | Host ctl: 0x00000003
sdhci_bcm0-slot0: Power:    0x0000000f | Blk gap:  0x00000000
sdhci_bcm0-slot0: Wake-up:  0x00000000 | Clock:    0x00000307
sdhci_bcm0-slot0: Timeout:  0x0000000e | Int stat: 0x00000000
sdhci_bcm0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb
sdhci_bcm0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000
sdhci_bcm0-slot0: Caps:     0x00000000 | Max curr: 0x00000001
sdhci_bcm0-slot0: ===========================================
mmcsd0: Error indicated: 1 Timeout
g_vfs_done():mmcsd0s2a[WRITE(offset=20398571520, length=32768)]error = 5
growfs: wtfs: write error: 39840960: Input/output error
mmcsd0: Error indicated: 1 Timeout
g_vfs_done():mmcsd0s2a[READ(offset=65536, length=4096)]error = 5
panic: failed to unsuspend writes on /
cpuid = 1
KDB: enter: panic
[ thread pid 664 tid 100065 ]
Stopped at      $d.7:   ldrb    r15, [r15, r15, ror r15]!
db>
This is on FreeBSD 11.0-CURRENT r282767.

The same SD card works fine under Linux. So I don't think that the card is faulty.
I wonder if putting the root file system on a USB stick for now will be more stable.
 
Today I installed v11.0 for raspberry Pi 2 and it works brilliantly: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0

No errors, kernel panic or anything. It has so far an uptime of 7 hours, and no issues at all.

Wifi dongle (Vilros) was detected, however I had to cp /boot/loader.rc.sample /boot/loader.rc as well as tweak the /boot/loader.conf for the wifi dongle, mine was just:

Code: 
legal.realtek.license_ack=1
if_urtwn_load="YES"

and a reboot aftewards.

So far, wireless works (standard ifconfig and wpa_supplicant setup). SSH works. 2-factor Google authenticator works.

If you have any questions, please let me know.

Cheers from London
Rami


here: /
 
Are you able by any chance to test the sd card in another rpi2? Just to discard any hardware/power supply issue?

(might be that you are already using that rpi2 for other images, so it might not be useful my reply!)


bthomson said:
I tested this image: http://ftp.freebsd.org/pub/FreeBSD/...URRENT-arm-armv6-RPI2-20150509-r282694.img.xz

However, it goes into boot loop for me. Here is the log:

Code: 
Connected
ÿ/-\|/-\|/-syms=[0x4+0x61310\|/+0x4+0x5c6f7-\|]


Hit [Enter] to boot immediately, or any other key for command prompt.



Booting [/boot/kernel/kernel] in 9 seconds...
Booting [/boot/kernel/kernel] in 8 seconds...
Booting [/boot/kernel/kernel] in 7 seconds...
Booting [/boot/kernel/kernel] in 6 seconds...
Booting [/boot/kernel/kernel] in 5 seconds...
Booting [/boot/kernel/kernel] in 4 seconds...
Booting [/boot/kernel/kernel] in 3 seconds...
Booting [/boot/kernel/kernel] in 2 seconds...
Booting [/boot/kernel/kernel] in 1 second...
Booting [/boot/kernel/kernel]...           


Using DTB provided by U-Boot at address 0x100.


/-\|Kernel entry at 0x100100...


Kernel args: (null)


KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2015 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #0 r282694: Sun May 10 04:33:02 UTC 2015
    root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI2 arm
FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225
VT: init without driver.
sema_sysinit
CPU: Cortex A7 rev 5 (Cortex-A core)
Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext
WB disabled EABT branch prediction enabled
LoUU:2 LoC:3 LoUIS:2
Cache level 1:
32KB/64B 4-way data cache WB Read-Alloc Write-Alloc
32KB/32B 2-way instruction cache Read-Alloc
Cache level 2:
512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc
real memory  = 989851648 (943 MB)
avail memory = 958423040 (914 MB)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
random: entropy device infrastructure driver
random: selecting highest priority adaptor <Dummy>
kbd0 at kbdmux0
random: SOFT: yarrow init()
random: selecting highest priority adaptor <Yarrow>
ofwbus0: <Open Firmware Device Tree>
simplebus0: <Flattened device tree simple bus> mem 0x3f000000-0x3fffffff on ofwbus0
bcm28360: <Broadcom bcm2836>
generic_timer0: <ARMv7 Generic Timer> irq 72,73,75,74 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 19200000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 19200000 Hz quality 1000
intc0: <BCM2835 Interrupt Controller> mem 0xb200-0xb3ff on simplebus0
bcmwd0: <BCM2708/2835 Watchdog> mem 0x10001c-0x100027 on simplebus0
gpio0: <BCM2708/2835 GPIO controller> mem 0x200000-0x2000af irq 57,59,58,60 on simplebus0
gpio0: read-only pins: 46,48-53.
gpio0: reserved pins: 48-53.
gpiobus0: <OFW GPIO bus> on gpio0
gpioled0: <GPIO led> at pin(s) 35 on gpiobus0
gpioled1: <GPIO led> at pin(s) 47 on gpiobus0
gpioc0: <GPIO controller> on gpio0
iichb0: <BCM2708/2835 BSC controller> mem 0x205000-0x20501f irq 61 on simplebus0
iicbus0: <OFW I2C bus> on iichb0
iic0: <I2C generic I/O> on iicbus0
iichb1: <BCM2708/2835 BSC controller> mem 0x804000-0x80401f irq 61 on simplebus0
iicbus1: <OFW I2C bus> on iichb1
iic1: <I2C generic I/O> on iicbus1
spi0: <BCM2708/2835 SPI controller> mem 0x204000-0x20401f irq 62 on simplebus0
spibus0: <OFW SPI bus> on spi0
bcm_dma0: <BCM2835 DMA Controller> mem 0x7000-0x7fff,0xe05000-0xe05fff irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0
mbox0: <BCM2835 VideoCore Mailbox> mem 0xb880-0xb8bf irq 1 on simplebus0
sdhci_bcm0: <Broadcom 2708 SDHCI controller> mem 0x300000-0x3000ff irq 70 on simplebus0
mmc0: <MMC/SD bus> on sdhci_bcm0
uart0: <PrimeCell UART (PL011)> mem 0x201000-0x201fff irq 65 on simplebus0
uart0: console (115200,n,8,1)
vchiq0: <BCM2835 VCHIQ> mem 0xb800-0xb84f irq 2 on simplebus0
vchiq0: [GIANT-LOCKED]
vchiq: local ver 6 (min 3), remote ver 6.
pcm0: <VCHQI audio> on vchiq0
bcm283x_dwcotg0: <DWC OTG 2.0 integrated USB controller (bcm283x)> mem 0x980000-0x99ffff irq 17 on simplebus0
usbus0 on bcm283x_dwcotg0
cpulist0: <Open Firmware CPU Group> on ofwbus0
cpu0: <Open Firmware CPU> on cpulist0
bcm2835_cpufreq0: <CPU Frequency Control> on cpu0
cpu1: <Open Firmware CPU> on cpulist0
cpu2: <Open Firmware CPU> on cpulist0
cpu3: <Open Firmware CPU> on cpulist0
fb0: <BCM2835 VT framebuffer driver> on ofwbus0
fbd0 on fb0
VT: initialize with new VT driver "fb".
fb0: 656x416(656x416@0,0) 24bpp
fb0: fbswap: 1, pitch 1968, base 0x3daac000, screen_size 818688
Timecounters tick every 10.000 msec
usbus0: 480Mbps High Speed USB v2.0
ugen0.1: <DWCOTG> at usbus0
uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
mmcsd0: 8GB <SDHC SA08G 1.4 SN 12BE54CE MFG 07/2014 by 2 TM> at mmc0 41.6MHz/4bit/65535-block
bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF
random: unblocking device.
Release APs
Root mount waiting for: usbus0
uhub0: 1 port with 1 removable, self powered
ugen0.2: <vendor 0x0424> at usbus0
uhub1: <vendor 0x0424 product 0x9514, class 9/0, rev 2.00/2.00, addr 2> on usbus0
uhub1: MTT enabled
Root mount waiting for: usbus0



U-Boot 2015.04 (May 10 2015 - 04:08:32)


DRAM:  944 MiB

WARNING: Caches not enabled

RPI 2 Model B

MMC:   bcm2835_sdhci: 0

reading uboot.env


** Unable to read "uboot.env" from mmc0:1 **

Using default environment


In:    serial

Out:   lcd

Err:   lcd

Net:   Net Initialization Skipped

No ethernet found.

Hit any key to stop autoboot:  2 1 0

Booting from: mmc 0 ubldr

reading ubldr

201948 bytes read in 156 ms (1.2 MiB/s)

## Starting application at 0x02000094 ...

Consoles: U-Boot console


Compatible U-Boot API signature found @3ab4a4c8





FreeBSD/armv6 U-Boot loader, Revision 1.2


(root@releng2.nyi.freebsd.org, Sun May 10 04:27:26 UTC 2015)





DRAM: 944MB


Number of U-Boot devices: 1


U-Boot env: loaderdev='mmc 0'


Found U-Boot device: disk


  Checking unit=0 slice=<auto> partition=<auto>... good.


|/-\|/-\|/


-\|/-\|/-\|/-\|/boot/kernel/kernel data=0x578f5c+0xf30a4 /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-syms=[0x4+0x61310\|/+0x4+0x5c6f7-\|]


Hit [Enter] to boot immediately, or any other key for command prompt.



Booting [/boot/kernel/kernel] in 9 seconds...
Booting [/boot/kernel/kernel] in 8 seconds...
Booting [/boot/kernel/kernel] in 7 seconds...
Booting [/boot/kernel/kernel] in 6 seconds...
Booting [/boot/kernel/kernel] in 5 seconds...
Booting [/boot/kernel/kernel] in 4 seconds...
Booting [/boot/kernel/kernel] in 3 seconds...
Booting [/boot/kernel/kernel] in 2 seconds...
Booting [/boot/kernel/kernel] in 1 second...
Booting [/boot/kernel/kernel]...           


Using DTB provided by U-Boot at address 0x100.


/-\|Kernel entry at 0x100100...


Kernel args: (null)


KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2015 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #0 r282694: Sun May 10 04:33:02 UTC 2015
    root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI2 arm
FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225
VT: init without driver.
sema_sysinit
CPU: Cortex A7 rev 5 (Cortex-A core)
Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext
WB disabled EABT branch prediction enabled
LoUU:2 LoC:3 LoUIS:2
Cache level 1:
32KB/64B 4-way data cache WB Read-Alloc Write-Alloc
32KB/32B 2-way instruction cache Read-Alloc
Cache level 2:
512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc
real memory  = 989851648 (943 MB)
avail memory = 958423040 (914 MB)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
random: entropy device infrastructure driver
random: selecting highest priority adaptor <Dummy>
kbd0 at kbdmux0
random: SOFT: yarrow init()
random: selecting highest priority adaptor <Yarrow>
ofwbus0: <Open Firmware Device Tree>
simplebus0: <Flattened device tree simple bus> mem 0x3f000000-0x3fffffff on ofwbus0
bcm28360: <Broadcom bcm2836>
generic_timer0: <ARMv7 Generic Timer> irq 72,73,75,74 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 19200000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 19200000 Hz quality 1000
intc0: <BCM2835 Interrupt Controller> mem 0xb200-0xb3ff on simplebus0
bcmwd0: <BCM2708/2835 Watchdog> mem 0x10001c-0x100027 on simplebus0
gpio0: <BCM2708/2835 GPIO controller> mem 0x200000-0x2000af irq 57,59,58,60 on simplebus0
gpio0: read-only pins: 46,48-53.
gpio0: reserved pins: 48-53.
gpiobus0: <OFW GPIO bus> on gpio0
gpioled0: <GPIO led> at pin(s) 35 on gpiobus0
gpioled1: <GPIO led> at pin(s) 47 on gpiobus0
gpioc0: <GPIO controller> on gpio0
iichb0: <BCM2708/2835 BSC controller> mem 0x205000-0x20501f irq 61 on simplebus0
iicbus0: <OFW I2C bus> on iichb0
iic0: <I2C generic I/O> on iicbus0
iichb1: <BCM2708/2835 BSC controller> mem 0x804000-0x80401f irq 61 on simplebus0
iicbus1: <OFW I2C bus> on iichb1
iic1: <I2C generic I/O> on iicbus1
spi0: <BCM2708/2835 SPI controller> mem 0x204000-0x20401f irq 62 on simplebus0
spibus0: <OFW SPI bus> on spi0
bcm_dma0: <BCM2835 DMA Controller> mem 0x7000-0x7fff,0xe05000-0xe05fff irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0
mbox0: <BCM2835 VideoCore Mailbox> mem 0xb880-0xb8bf irq 1 on simplebus0
sdhci_bcm0: <Broadcom 2708 SDHCI controller> mem 0x300000-0x3000ff irq 70 on simplebus0
mmc0: <MMC/SD bus> on sdhci_bcm0
uart0: <PrimeCell UART (PL011)> mem 0x201000-0x201fff irq 65 on simplebus0
uart0: console (115200,n,8,1)
vchiq0: <BCM2835 VCHIQ> mem 0xb800-0xb84f irq 2 on simplebus0
vchiq0: [GIANT-LOCKED]
vchiq: local ver 6 (min 3), remote ver 6.
pcm0: <VCHQI audio> on vchiq0
bcm283x_dwcotg0: <DWC OTG 2.0 integrated USB controller (bcm283x)> mem 0x980000-0x99ffff irq 17 on simplebus0
usbus0 on bcm283x_dwcotg0
cpulist0: <Open Firmware CPU Group> on ofwbus0
cpu0: <Open Firmware CPU> on cpulist0
bcm2835_cpufreq0: <CPU Frequency Control> on cpu0
cpu1: <Open Firmware CPU> on cpulist0
cpu2: <Open Firmware CPU> on cpulist0
cpu3: <Open Firmware CPU> on cpulist0
fb0: <BCM2835 VT framebuffer driver> on ofwbus0
fbd0 on fb0
VT: initialize with new VT driver "fb".
fb0: 656x416(656x416@0,0) 24bpp
fb0: fbswap: 1, pitch 1968, base 0x3daac000, screen_size 818688
Timecounters tick every 10.000 msec
usbus0: 480Mbps High Speed USB v2.0
ugen0.1: <DWCOTG> at usbus0
uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
mmcsd0: 8GB <SDHC SA08G 1.4 SN 12BE54CE MFG 07/2014 by 2 TM> at mmc0 41.6MHz/4bit/65535-block
bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF
random: unblocking device.
Release APs
Root mount waiting for: usbus0
uhub0: 1 port with 1 removable, self powered
ugen0.2: <vendor 0x0424> at usbus0
uhub1: <vendor 0x0424 product 0x9514, class 9/0, rev 2.00/2.00, addr 2> on usbus0
uhub1: MTT enabled
Root mount waiting for: usbus0



U-Boot 2015.04 (May 10 2015 - 04:08:32)


DRAM:  944 MiB

WARNING: Caches not enabled

RPI 2 Model B
Click to expand...
 
Not sure it's the right place to ask but I'm a recent FreeBSD convert with a few days experience on other hardware and never really had any issues. Been trying to get the Pi 2 version up to just having a desktop and browser, but failing at the first hurdle because 11.0 is telling me that xorg-minimal doesn't exist for it. Any clues..?
 
Jefrey S. said:
Not sure it's the right place to ask but I'm a recent FreeBSD convert with a few days experience on other hardware and never really had any issues. Been trying to get the Pi 2 version up to just having a desktop and browser, but failing at the first hurdle because 11.0 is telling me that xorg-minimal doesn't exist for it. Any clues..?
Click to expand...
Hi,
FreeBSD 11.0-CURRENT for RaspberryPi 2 is still experimental and therefore it does not guarantees 100% functionality.

About x11/xorg-minimal, if you are trying to install it with pkg, it is possible that it is not available from packages, maybe you should try compiling from ports, although it would take some time, given that the CPU is not powerful enough.

If you want to use your RPi2 to browse the internet (or just to have a GUI...), my guess is that Linux is ideal for you (Raspbian, etc.).
 
Totally aware of how experimental it is, and I just happen to prefer FreeBSD where possible and find it an interesting alternative in general. I know it exists for 10.1 on the older Pi so assumed I was likely doing something wrong here. Guess I can dig out my model B 512mb revision and play around with that in the meantime. Perhaps I will have a shot at compiling it. I have four devices at this point running FreeBSD and am very keen on getting it going on the Pi 2 as I enjoy figuring out alt-OS's. There's just a lot of things about FreeBSD that appeal to me, and I think it will make a great companion to the Pi 2 some day. Everyone working on it? Keep at it!
 
I tried running FreeBSD 11-Current on my Raspberry Pi 2 today. The first time I started it up, the Pi was headless. Networking and OpenSSH were running and I could connect to the Pi over the network. I couldn't get logged in though. Tried a bunch of different passwords, including an empty password (just pressed Enter), but could not get logged in remotely.

Later I hooked the Pi up to a monitor and tried booting FreeBSD 11. The Pi shut itself off after about 20 seconds. I tried half a dozen times to boot the Pi with and without any devices attached. It always shut off within 20 seconds and provided no video output.

What I found weird was the first time the Pi obviously booted okay since it was accepting remote login attempts. But all future boot ups crashed in seconds, resulting in the Pi shutting off.

Does FreeBSD's ARM port do anything to change its files or disk layout? Trying to figure out why the OS would only boot once and then crash on each subsequent boot.

Also, am I correct that the password is blank and that it is not possible to login remotely with the default image?
 
Rami said:
Are you able by any chance to test the sd card in another rpi2? Just to discard any hardware/power supply issue?
Click to expand...

Thanks, that solved the problem! Motherboard USB power is enough for RPI1, but not for RPI2!

So it is working splendidly now, thanks to everyone for your hard work! It is very much appreciated.

NewGuy said:
What I found weird was the first time the Pi obviously booted okay since it was accepting remote login attempts. But all future boot ups crashed in seconds, resulting in the Pi shutting off.
Click to expand...

The same thing often happens with the Pi 1 images as well. It is not so reliable just yet, give it time.
 
Last edited:
I recopied my FreeBSD 11-Current image to the microSD card and gave it another try. This time it worked. I realized what probably happened before was FreeBSD turns off the Pi's external light while Raspbian leaves the light on, so it looks like the Pi is powering off. It takes a while for my montor to detect a signal from the Pi when its running FreeBSD too, so the combination of a blank monitor and no light make it seems like the Pi wasn't on-line. So the first time around I probably interrupted the Pi's power while the file system resize was in progress.

Anyway, I got the Pi running, set up an account I can ssh into and things seem to be running smoothly.

At this point the one thing I feel I am missing is ZFS. When the Pi is running Raspbian, I can access my ZFS-managed devices. It seems the FreeBSD 11 image doesn't include a ZFS module or the kernel source code.

Does anyone here know if the FreeBSD ZFS module will build on the Pi? Or if there is a repository where I can download a pre-built ZFS arm module? I'd rather not have to rebuild the kernel from scratch on the Pi.

I'd like to head off any comments about ZFS not working well with the Pi's limited hardware. I've been managing 2TB of data on my Pi using Raspbian and ZFS for a month now without any problems.

Update: I was able to install the zfs module by downloading the FreeBSD source code and compiling the following modules in the sys/modules direcotry: opensolaris, zlib and zfs. Copying the resulting .k* files to the /boot/kernel directory allowed me to load the ZFS module and access my external hard drive that is managed by ZFS.

Further, I have discovered that while I can access this external drive, some copy operations cause my Pi to completely hard crash. For example, I can copy any one file I like, but copying a whole directory (ie cp * /to/destination/) brings down the operating system.

I'm also noticing sometimes files I create on the root partition (formatted with UFS) do not always survive the crash. Perhaps UFS isn't syncing in time to save its data before the crash happens. Still working on this.

Memory consumptionis fairly low, the whole Os, ZFS included, is using around 200MB of RAM.

Second update: I have found I am able to create/move/delete many files at once on either my ZFS volume OR the UFS partition. The crash only happens, it seems, when I try to bulk copy files from one file system to the other, in either direction. I can, for example, unpack the ports tree or copy the kernel source code around to various locations, so long as I stay within the boundaries of the respective file systems.
 
Thanks for your reports, NewGuy! It is good to know that ZFS can be installed, but is unstable for some reason. I hope the crash did not harm your ZFS pool!

I will share some of my observations having run the Pi 2 for an evening... Surprisingly, I found the network I/O performance was actually worse than the Pi 1 unless the device is running in turbo mode, and then it was almost the same (but still a little bit worse).

Unfortunately the performance is much worse than I'd hope, maxing out at less than 10 megabits/s (about 10% of the theoretical maximum of the 10/100 adapter). While trying to figure out the cause I discovered it is probably because unlike Linux, FreeBSD is using PIO mode instead of DMA mode for USB transfers. See the links below for some more info. Since this is not a CPU limitation, the beefier Pi 2 does not improve the situation.

So I was not so impressed with Pi 2 on FreeBSD at this point. Oh well, maybe one day.

http://kernelnomicon.org/?p=275#comment-5394
https://lists.freebsd.org/pipermail/freebsd-arm/2013-July/006012.html
https://lists.freebsd.org/pipermail/freebsd-arm/2013-July/006008.html
 
Last edited:
The crashes do not appear to have harmed my ZFS zpool, thanks for the concern. The pool passed its scrub test.

I found some further interesting quirks with running FreeBSD+Pi+ZFS. Since there aren't any official packages for the ARM architecture, I decided to download the ports tree and install software from there. I ran into these interesting issues:

1. portsnap fetch does not work, portsnap(8) reports the server's meta-data is wrong and refuses to download the ports tree. I checked my portsnap configuration file and it is the same as my portsnap config file on other FreeBSD servers where portsnap works.

2. I downloaded and unpacked a tarball of the ports collection. This tarball unpacked fine on the ZFS volume. I could then go into the ports tree, open Makefiles, cat patches and confirm everything is there. However...

3. When I try to run make in any of the port directories, make reports no target was found. If I then try to open the Makefile, it is empty. ls -l shows the file is still the same size, but vi and cat show an empty file.

4. I was curious to see if this meant ZFS was not writing data properly or not reading data properly where the Makefiles were concerned. I exported my ZFS pool and imported it on another operating system (also running on the Pi). The data is definitely there and readable from Raspbian on the same ZFS volume. so the files which appeared empty in FreeBSD are there and whole and readable in Raspbian.

I'm not quite sure what to make of this. It seems I can create files, many files, and read them on the ZFS volume from FreeBSD. I can read them, I can export/import the pool and read the data from another OS. However, running make on three different ports all resulted in errors of "no target found" and I was unable to read the Makefile from within FreeBSD again. I can read the files fine in Raspbian though.

A zpool scrub shows the pool is fine. I haven't seen anything quite like this before. It seems FreeBSD+ZFS+RPi works about 95%, but data is sometimes corrupted while being read/accessed. Long story short: FreeBSD+ZFS appears to work on the Pi, but I wouldn't trust it.

Update: Wondering if this might be an allocation/versioning issue. Raspbian is probably using an older version of ZFS and it used 512 byte allocations. FreeBSD reports it wants 4096 byte allocations and runs a newer version. Planning to test this idea with another (spare) drive to see if I can duplicate the problem and/or find a solution.
 
Another update: I decided to experiment to see if the system crashes I was experiencing on FreeBSD 11-Current (arm) were due to incompatibilties between the Raspbian ZFS file system and the FreeBSD implmentation.

I grabbed a spare hard drive and plugged it into my Raspberry Pi 2 running Raspbian. I formatted the disk with ZFS and copied a directory tree onto the new ZFS volume. This worked fine and I could access my files, copy them back, etc.

Then I swapped out my Raspbian SD card for my FreeBSD card and booted the same Pi. I imported the new ZFS volume and found I could browse the file system, but copying more than one file at a time to or from the ZFS volume would cause the operating system to immediately crash. In other words, I've reproduced the copying crash using multiple external drives at this point.

My next step was to destroy the Raspbian-created ZFS file system and create a new file system on the same external drive using FreeBSD's implementation of ZFS. The file system was created. Here is where it gets interesting.

With the FreeBSD-created ZFS volume I was able to copy large trees of files to the ZFS volume from my UFS partition. However, when I tried to copy files back _from_ the ZFS volume to my UFS partition, the operating system immediately crashed.

I booted into FreeBSD again and performed another experiment, and this is where it goes from interesting to just plain weird. I copied kernel soruce code onto the ZFS volume. If I go into any directory and run "cat Makefile" I can see the contents of the Makefile. However, if I run "make" then it spits out an error saying there is no target. If I run "cat Makefile" again, there is no data in the Makefile. The command "ls -l" shows the file is still its full, normal size, but I cannot read any data in the file, it appears to contain zero bytes. I thought the file might be truncated, but it's not. If I use
Code: 
zfs umount MyData
zfs mount MyData
and go back into the same source code directory, the Makefile is there and I can read it and edit it. But if I run "make" again the contents of the Makefile disappear until I umount/mount the ZFS pool again.


To sum up, there are three problems here:
1. FreeBSD and Raspbian have slightly incompatible ZFS implementations.
2. Running "make" on source in a ZFS pool temporarily wipes the Makefile. This makes it impossible to build ports or kernel modules or other items from source code in ZFS. Building source using "make" on UFS does work.
3. Copying _to_ a ZFS volume works, but copying from ZFS to UFS causes an immediate and total system failure.

Question 1: Can anyone else reproduce these problems?

Question 2: Which mailing list or component team should I bring this up to? I'm not sure if these issues qualify as Make bugs, ZFS bugs or ARM bugs.
 
Also, am I correct that the password is blank and that it is not possible to login remotely with the default image?
Click to expand...

Hi Newguy, I'm trying to run freebsdFreeBSD on my Raspberry Pi 2. I wrote the image FreeBSD-11.0-CURRENT-arm-armv6-RPI2-20150601-r283896.img to my microsd card, it booted and SSH responded, but I wonder what's the default user name and password?
 
The username is root and the default password is blank. However, root logins are blocked through OpenSSH by default. You need to boot up the Pi with a keyboard and monitor attached and create a new user account before you can login remotely.
 
NewGuy said:
The username is root and the default password is blank. However, root logins are blocked through OpenSSH by default. You need to boot up the Pi with a keyboard and monitor attached and create a new user account before you can login remotely.
Click to expand...
Thanks, now I can login through SSH with an ordinary username.
 
I've gone ahead and put both FreeBSD-11.0-CURRENT-arm-armv6-RPI2-20150601-r283896.img and FreeBSD-11.0-CURRENT-arm-armv6-RPI2-20150618-r284544.img on microSD cards, installed them in my RPi 2, and booted with a monitor and keyboard plugged in. However, both are requiring passwords -- leaving it blank for the root password isn't working, even from console. Is there some other trick or hoop I may be missing?
 
According to arm_create_user() in src/release/tools/arm.subr the logins are:
Code: 
login: root
password: root

login: freebsd
password: freebsd
The 2nd should work over ssh.
 
It's got to be simple.
Headless Pi2.
Burnt the image.
Booted up and ssh'd to box with user/password of "freebsd"/"freebsd".
su -

Won't accept root password of root as above message says.

What am I missing?
 
You must log in or register to reply here.
Back
Top