OPNsense Forum

Archive => 17.1 Legacy Series => Topic started by: SimpleRezo on March 24, 2017, 11:47:14 am

Title: 17.1 on PC engines apu
Post by: SimpleRezo on March 24, 2017, 11:47:14 am
Hi,

I have a problem with the 17.1 version of opnsense on Pc Engines apu1 and apu2
The img file is installed on SDHC 8 and 16gb class 10 cards (tested with many cards)

The problem is that only the first boot works. I can use and configure opnsense normally but if I shutdown or reboot the pc engine, the opnsense doesn't booting anymore.

Using the serial com port, here is what it says on SD boot:
on apu1: "ehci_wait_td error - status=10000d40 USB transmission failed"
on apu2: "Timeout at sdcard_waitw"

For now i was on pfsense and I never meet this problem.

So I tried to install the 16.7 version and the problem not occur, I can even update to 17.1 from it and reboot without problem
Title: Re: 17.1 on PC engines apu
Post by: franco on March 24, 2017, 11:50:22 am
Hi there,

Does the same thing happen with pfSense 2.4? If yes, we're seeing an interesting issue with FreeBSD 11.0 I have no idea how to look into.


Cheers,
Franco
Title: Re: 17.1 on PC engines apu
Post by: SimpleRezo on March 24, 2017, 04:43:55 pm
Hi there,

Does the same thing happen with pfSense 2.4? If yes, we're seeing an interesting issue with FreeBSD 11.0 I have no idea how to look into.


Cheers,
Franco

I have done many test today thanks to your comment, here are the results

pfSense-CE-memstick-2.3.4-DEVELOPMENT-amd64-latest.img => booting
pfSense-CE-memstick-2.4.0-BETA-amd64-latest.img => not booting

FreeBSD-10.3-RELEASE-amd64-memstick.img => booting
FreeBSD-11.0-RELEASE-amd64-memstick.img => not booting

It is therefore very probable that the problem comes from Freebsd 11.0
However I don't understand why opnsense 17.1 can boot once while pfsense 2.4 and freebsd 11 don't boot at all
Title: Re: 17.1 on PC engines apu
Post by: franco on March 24, 2017, 06:02:18 pm
Thanks, interesting! I am not sure either, but this is curiously positive news. I'd suspect the file system manipulation from the controller causes a faulty write which then causes the device to not properly boot anymore.

We could try newer kernels here for FreeBSD 11-STABLE and 12-CURRENT just to see if that makes a difference, but now my priority is to get 17.1.4 and the respective images out, which will take next week and maybe the one after that.


Cheers,
Franco