Best way to deploy FreeBSD in SDCard on a single card computer.

Hello.
I have some questions concerning the best way to deploy FreeBSD OS in SDCard on Single board computer like (RaspberryPI, OrangePI, .... ).
1. How to guarantee the recover of the system while crashing ( I mean, when for exemple, the electricity is cut ( in our countrie it happen) ) without intervention.
When booting, it control the FS consistency and do cleaning, then booting normally.
2. Are SDcards sow robust in our days, so the processes wan read/write many times? I read somewhere that SDCard have a limit concerning write on them before they can be unusable.
In my case, I want to deploy a webserver and remote VPN, regarding all these, What can you advise me ?
Is there any tutorial to point me to?
Thank you.
 
I don't think SD cards are known for reliability and performance, so for running a web server you want something better - unless just an experiment/hobby project.
 
I don't think SD cards are known for reliability and performance, so for running a web server you want something better - unless just an experiment/hobby project.
Sur, but what if doing a minimal writes to SD Card ( desactivating logs, serving static files (not big files)), no great trafic on and maybe if possible, load the OS in memory ?
 
I mean, when for exemple, the electricity is cut ( in our countrie it happen)
Add a small battery pack? Just enough juice to keep it going for small outages and gracefully shut it down if the power's out for a longer period.

Are SDcards sow robust in our days, so the processes wan read/write many times?
I'd say they've gotten worse. Especially the cheap Chinese knockoff ones.
 
Is there any way to store OS in SDCard ans load it in memory (mfs).
You can set this up. But it's going to use quite a lot of memory depending on the size of filesystem of course. And most Pis don't have much memory to begin with. You still need some free memory to actually run the processes.
 
I have been struggling with the same question on RPi and other Arm platforms with no storage options.

Many Arm platforms require a microSD-Card with u-boot on it to start up.
But you can install the OS on other devices such as attached USB Disks.

So, Is the microSD card better for the OS than an external USB Disk.
I say yes if you buy Industrial micro SD cards. SLC cards are even better.
Not very fast but reliable.

Apacer and Swissbit are two industrial brands cards I use.
My feeling is that your Arm platform is only as strong as the weakest link.

Of course we have diskless and NanoBSD to consider for ultimate control of disk writes.
 
Is there any way to store OS in SDCard ans load it in memory (mfs). If yes, could you point me to a tutorial, how to do it, or give me an entry point to this.

Here is some NanoBSD advice I can offer:

There is a special directory in the source tree under NanoBSD just for embedded.
/usr/src/tools/tools/nanobsd/embedded/
There is a README with instructions included. rpi3.cfg is included.
May need to check that the Rpi3 u-boot port is named the same. It may need adjustment in the config file.

There is some breakage here and there are two NanoBSD script changes that are required
You will need to search forums or PR's for the solutions. Simple changes to the nanobsd scripts.
I won't beat around the bush. The /embedded directory work is WIP.
It helps to be familiar with NanoBSD. But regardless it is a very good method for using microSD on Arm.
The problem is it helps to have a running install so you know what your setup looks like.
Than you convert it into a NanoBSD config with custom files. Complete with users and packages.
All that takes time. There is no quick setup guide.
But first you must crawl before you walk so you build and customize and repeat 100 times.
 
If you just want to relieve pressure on disk writes this site has a good section on using Memory disks.

Mounting the root file system​

You can skip the whole ACLS bit. It does show the directories in /var to load to MD.
 
The problem with sending /var/log/ to MD is you lose all logs on reboot or power event.

With a web server logs provide a security function and you might want to do something with that information.
Maybe make a script that writes logfile back to disk with a rc.shutdown.local.
If this is an internal web server you can disregard.
 
No need for me to logs,
What I want is doing minimum config in the system and run it. I do not need any log.
I plane to put
/var/log
# and
/var/run

in tmpfs by adding entries in
#fstab
runfs /var/run tmpfs rw,mode=1777,size=1M 0 0
logfs /var/log tmpfs rw,mode=1777,size=1M 0 0
disactivate syslogd in
#/etc/rc.conf
syslogd_enable="NO"

So, what to you think ?
Is there any option to do to eliminate logs ?
 
Is there any option to do to eliminate logs ?
You don't want that all around.
dmesg can really be useful.

Think of the cost. Its only a small amount of memory if on a MD.
1 Meg that you are showing is probably too small. Go to 8M.
Even with BBB with 512M RAM that is a tiny sliver.
 
Thanks Phishfry
Really I do not no logs on it, Just a web, vpn server to run after making the right config for that, ( I want really to have 0 log )
Even the dmsg.boot do not need it ( need it in the first start to just adjust what i need ).
So, Is there any other tricks to do ?

PS: I'll adjust the values to 10Meg
 
Hello. I practically disabled all uneeded logs for me, and for some, I put them in tmpfs file system.
Is there any way to disactivate the
  1. /var/log/utx.log
  2. /var/log/squidGuard.log
Thank you.

for squidGuad, I tried so many forms
logdir /var/log/squidGuard # default configuration ( works but unwanted )
logdir /dev/null # do not work ( squidGuard enter emergency mode)
logdir /var/log/squidGnull # unexistent folder ( squidGuard enter emergency mode)
logdir # do not work also.
 
Did a quick browse of responses and OP really needs to consider the wisdom in NOT using uSD cards as volatile/writable system disk on the embedded system. That's not the best-practice way.

The best practice is to create a kernel/ramdisk image that loads and runs out of RAM, and try to avoid using uSD at all for random adhoc writes. The uSD has a very fragile controller on the media itself and very frequently spike or power loss during an chip update will render the chip unusable.

For pure embedded systems that have such, onboard flash memory is the better alternative for volatile data storage, even if it is slow access like qspi.
 
Back
Top