Update: APU set boot parameter
-
There will be a Problem if I'd like to update pfSense an PCEngines APU Board, because i need the boot parameter
kern.cam.boot_delay=10000What I see, there are 2 possibilities to solve that:
1.) Implement a solution that I can modify the loader.conf after installation.
A checkbox under update settings where you can disable the automatic reboot after update installation. So you can change the boot parameter on the newly upgraded files
2.) Implement the boot parameter in the next nanobsd imagesnot really 3.) implement a new image download nano with sd card :o
-
0.) Create /boot/loader.conf**.local** and move on.
-
^Exactly.
See: https://doc.pfsense.org/index.php/Boot_Troubleshooting#Booting_from_USBSteve
-
Or play with 2.2 snapshots :) - they boot clean from the default install (at least for me)
-
0.) Create /boot/loader.conf**.local** and move on.
That does not work on NanoBSD which I think is what most people are using with that board, including the OP.
My recommendation is still to stop buying cheap cards and just run a full install. Samsung just released a new SD card with MLC flash which should be fine for a full install.
-
That does not work on NanoBSD which I think is what most people are using with that board, including the OP.
Huh? Using it all the time.
$ cat /etc/platform nanobsd $ cat /boot/loader.conf.local hw.ata.ata_dma="1" $ dmesg | grep DMA atapci0: <amd cs5536="" udma100="" controller="">port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 15.2 on pci0 ad0: 1919MB <cf 20110221="" 2gb="">at ata0-master UDMA100</cf></amd>
-
The contents are lost on upgrade with NanoBSD. Does not persist like it does on a full install.
-
The contents are lost on upgrade with NanoBSD. Does not persist like it does on a full install.
Negative.
/etc/rc.firmware
# If /boot/loader.conf.local exists # copy to the other slice. if [ -f /boot/loader.conf.local ]; then cp /boot/loader.conf.local /tmp/$GLABEL_SLICE/boot/loader.conf.local fi
-
Hmm… Must be new. Thanks for the info.
-
My recommendation is still to stop buying cheap cards and just run a full install.
It is not always just an issue of the card reliability. I am actually choosing to using nanoBSD on APU because I like the 2-slice boot option setup - after upgrading, the old version is still on the system and can easily be booted. For remote upgrades, this makes me feel a little better (assuming someone at the remote office can find their way to the console!). And I get easily tempted to upgrade to development/alpha/beta versions when there are good fixes or enhancements that I find useful, so having the fall-back position is very handy when a snapshot turns out to be not so good.
-
My recommendation is still to stop buying cheap cards and just run a full install.
It is not always just an issue of the card reliability. I am actually choosing to using nanoBSD on APU because I like the 2-slice boot option setup - after upgrading, the old version is still on the system and can easily be booted. For remote upgrades, this makes me feel a little better (assuming someone at the remote office can find their way to the console!). And I get easily tempted to upgrade to development/alpha/beta versions when there are good fixes or enhancements that I find useful, so having the fall-back position is very handy when a snapshot turns out to be not so good.
That's a very valid point.
-
I'm actually looking at using ZFS to do this, rather than the 2 slice nano setup.
ZFS let's one keep multiple copies, and provides transparent compression on/off the SD card.
First I have to prove (internally) that it is as reliable.
-
Hmm… Must be new. Thanks for the info.
If 3 years old is 'new' to you, perhaps you should update. :P
-
My recommendation is still to stop buying cheap cards and just run a full install.
It is not always just an issue of the card reliability. I am actually choosing to using nanoBSD on APU because I like the 2-slice boot option setup - after upgrading, the old version is still on the system and can easily be booted. For remote upgrades, this makes me feel a little better (assuming someone at the remote office can find their way to the console!). And I get easily tempted to upgrade to development/alpha/beta versions when there are good fixes or enhancements that I find useful, so having the fall-back position is very handy when a snapshot turns out to be not so good.
I hope you are aware that we don't recommend snapshots for production systems.
-
@gonzopancho:
I'm actually looking at using ZFS to do this
That's gonna absolutely rock with 256MB of RAM… ::)
-
It won't be available for 32-bit builds.
-
@gonzopancho:
It won't be available for 32-bit builds.
Cannot see how's 32bit relevant there. And cannot see how's ZFS useful here beyond pointless marketing fluff.
-
Fortunately, pfSense is not led by the blind.
-
@gonzopancho:
Hmm… Must be new. Thanks for the info.
If 3 years old is 'new' to you, perhaps you should update. :P
Maybe I missed it. I stopped using NanoBSD, mostly because of this issue, back around the 1.2.3->2.0 transition. It was just easier in the long term to buy SLC or high quality MLC flash.
-
Easy enough to miss, Jason.
I happen to agree with you that running a live filesystem makes many things more straight-forward.
As above, I'm investigating running ZFS as a first step to moving on from the nanobsd past and its restrictions.
(There are, and will continue to be a base of people using older, 32-bit systems that likely can't move to ZFS, so it's not like the 'nano'/'embedded' builds
will completely go away.)If it pans out, then likely that a "3.0" version of the pfSense software will run something a lot like 'freebsd-update', rather than the BWOS-like releases of today, and likely also something a bit more modern for a configuration system and GUI than the large mass of PHP that defines the product now. This should help us address some of the security shortcomings in the current codebase.
NO decision has been taken (yet), it's just time to re-think the direction.
-
@gonzopancho:
There are, and will continue to be a base of people using older, 32-bit systems that likely can't move to ZFS, so it's not like the 'nano'/'embedded' builds will completely go away.
That's good to hear, I don't think anything I have running right now would be too happy with ZFS. Also interesting to hear your long term thinking.
Steve
-
@gonzopancho:
My recommendation is still to stop buying cheap cards and just run a full install.
It is not always just an issue of the card reliability. I am actually choosing to using nanoBSD on APU because I like the 2-slice boot option setup - after upgrading, the old version is still on the system and can easily be booted. For remote upgrades, this makes me feel a little better (assuming someone at the remote office can find their way to the console!). And I get easily tempted to upgrade to development/alpha/beta versions when there are good fixes or enhancements that I find useful, so having the fall-back position is very handy when a snapshot turns out to be not so good.
I hope you are aware that we don't recommend snapshots for production systems.
Indeed! And I will add my "don't recommend" to that so that others are not misled.
Don't do it unless you have a real need for something fixed or enhanced in the new version, and you have tested in a good test environment that covers at least the hardware and features you are using, and you keep yourself well aware of the development that is happening in the snapshot stream and test all over again before upgrading to a later snapshot, and other caveats I haven't thought of…
Stuff happens in development, things get re-engineered, versions of underlying utilities change, patches are done to (hopefully) enhance something, the build system itself gets modified. So sometimes a new snap might be missing critical things and not even boot. That is part of the development process.
Always have a plan for how you will revert to something that works. Don't depend on anyone else for support, don't come complaining that the snapshot was a "dud".
Enough said.
-
That does not work on NanoBSD which I think is what most people are using with that board, including the OP.
Huh? Using it all the time.
$ cat /etc/platform nanobsd $ cat /boot/loader.conf.local hw.ata.ata_dma="1" $ dmesg | grep DMA atapci0: <amd cs5536="" udma100="" controller="">port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 15.2 on pci0 ad0: 1919MB <cf 20110221="" 2gb="">at ata0-master UDMA100</cf></amd>Nice, didn't know that too… I'll try that. Thans
-
@gonzopancho:
I'm actually looking at using ZFS to do this, rather than the 2 slice nano setup.
ZFS let's one keep multiple copies, and provides transparent compression on/off the SD card.
First I have to prove (internally) that it is as reliable.
@gonzopancho:
As above, I'm investigating running ZFS as a first step to moving on from the nanobsd past and its restrictions.
If it pans out, then likely that a "3.0" version of the pfSense software will run something a lot like 'freebsd-update', rather than the BWOS-like releases of today, and likely also something a bit more modern for a configuration system and GUI than the large mass of PHP that defines the product now. This should help us address some of the security shortcomings in the current codebase.
NO decision has been taken (yet), it's just time to re-think the direction.
+1 for ZFS
