# NanoBSD vs thread. Are there alternatives?



## cL0N31 (Aug 25, 2018)

Considering NanoBSD for a desktop os. Is NanoBSD a run from ram thing? How much ram would be recommended?

Main question is, are there alternatives? I'm currently using alpine linux diskless and that thing based on musl and busybox is 'just what the doctor ordered' for a low power machine. Willing to switch to BSD. Is there anything besides NanoBSD, like based on OpenBSD, etc. for example?


----------



## ondra_knezour (Aug 26, 2018)

There is at least mfsbsd and others, targeting mainly routers/networking hardware.


----------



## kpa (Aug 26, 2018)

Specifically NanoBSD is used on resource limited systems like the ALIX boxes and where the old style not so wear resistant compact flash media is used as mass storage. It uses a RAM disk for most operations to avoid writing to the disk too much, a separate configuration slice and two identical slices to facilitate upgrades.

https://www.freebsd.org/doc/en_US.ISO8859-1/articles/nanobsd/index.html


----------



## cL0N31 (Aug 26, 2018)

ondra_knezour, i plan to check those out

kpa, 'avoid writing to the disk too much'. Under what circumstances does it write to the disk? What's a slice in this context?

It sounds very similar to how it's done in alpine. In alpine no writes are done unless requested: the os is meant to always be generic, all the desirable configs can be written in a persistence file, which if found gets read automatically on every boot. Software also gets auto installed on every boot. If the persistence file is absent, the os loads virgin.

Thus said, if NanoBSD turns out to be similar and with a small hardware footprint, it's a no-brainer for me.

Still looking for some info on other BSD flavors in this regard


----------



## Bobi B. (Aug 26, 2018)

nanobsd runs from a read-only root filesystem; only /etc and /var are in RAM, sized whatever you pick when building the image.

If I'm not mistaken mfsbsd makes a RAM disk, decompresses root file system in there and runs completely from RAM.

Why running a desktop from such image? Unless it is a kiosk or you wish to prevent unnecessary writes to the storage media, what would the benefits be?


----------



## kpa (Aug 26, 2018)

Slice = BSD slang for a primary (MBR) partition.


----------



## cL0N31 (Aug 26, 2018)

Bobi B, that sounds like NanoBSD is possibly better: less ram use, as opposed to alpine, where everything runs from ram.

It's definitely not going to be a dev box. First of all, robustness: i run alpine from a removable flash storage, the amount of writes is very important. This also means less power use (perfect for a laptop) since an hdd is no longer needed, no need to buy an ssd. Experiment: ef it up, then just reboot. Portability: plug and play anywhere. Privacy: no persistent logs by default. And i'm sure there's more


----------



## jpierri (Aug 26, 2018)

NanoBSD is perfect to build appliances.
I'm running Asterisk on NanoBSD and the resulting appliance is very robust and works very well.


----------



## cL0N31 (Aug 26, 2018)

jpierri, then you can probably help with this. I got the 11.2 disc1, but can't find the NanoBSD script on it. Hoping it is on dvd1, obviously it'll take a little longer to dl it. Where did you get yours from?


----------



## Bobi B. (Aug 26, 2018)

You have to install sources, in order to build a nanobsd image; then it is in /usr/src/tools/tools/nanobsd/nanobsd.sh. If you haven't installed sources check the documentation on how to do that.


----------



## kpa (Aug 26, 2018)

Use the anonymous method from section 5.3.3. You're not going to get anywhere with the svn+ssh:// method.


----------



## jpierri (Aug 26, 2018)

Also keep in mind that some documentation is a little outdated, as discussed on Thread nanobsd.63418


----------



## cL0N31 (Aug 26, 2018)

Figured it was. It's the Introduction to NanoBSD doc last modified over 4 years ago. The handbook is fine though


----------



## drhowarddrfine (Aug 27, 2018)

kpa said:


> Slice = BSD slang for a primary (MBR) partition.


Slang? No. Just a different definition.


----------



## cL0N31 (Aug 30, 2018)

after nanobsd.sh ran for almost 4 hours i get 
	
	



```
/usr/obj/nanobsd.full/_.mnt: write failed, filesystem is full
```
 and according to this that's normal?


----------



## cL0N31 (Aug 31, 2018)

NANO_MEDIASIZE=3200000, is that 3gig? How is that lightweight?

BSDRP's info is great indeed.

Yes, Poudreire was the kind of a possible alternative i was looking for


----------



## cL0N31 (Aug 31, 2018)

To correct myself, NANO_MEDIASIZE=3200000 does not correspond to 3gig, more like 1.5gig. However it failed again with the same error. Everything default 11.2 release amd64 i was able to make it happy with NANO_MEDIASIZE=4400000. Found out the hard way


----------



## silicium (Aug 31, 2018)

I started using NanoBSD for my home router, then sometimes used a desktop on it, but was not comfortable with volatile /var in RAM when using pkg(), and do not like a writable /etc. I left NanoBSD and did a normal installation with custom /etc/fstab  that mounts read-only almost all partitions except /home, and /var as rw partition on CF card (particularly for /var/db), but other subdirectories that are often written to and can be volatile are mounted on small md() filesystems.


----------



## cL0N31 (Sep 1, 2018)

silicium said:


> I started using NanoBSD for my home router, then sometimes used a desktop on it


If i end up actually using NanoBSD, i'll prolly have regular FreeBSD installed on another machine (VM etc) to make sure the problems i run into apply to either FreeBSD in general or specific to NanoBSD. Yes, the ro slices sound good, but NanoBSD gives more trimming and customization options out of the box. If in need of persistent /var or whatever, why not make it a symlink to non-volatile media?


----------



## cL0N31 (Sep 1, 2018)

I've finally found an hdd to try out the default NanoBSD image. The drive was id'ed as a da0 device by FreeBSD, so i went ahead and ran the dd command just like the 'man nanobsd' suggests. It completed successfully and the corresponding slices now show up under /dev. However when i try to boot from the drive i get nothing but a blank screen and a blinking cursor in the top left corner. Any ideas what can be wrong?


----------



## cL0N31 (Sep 2, 2018)

Phishfry said:


> Did you adjust NANO_DRIVE="ada0" to NANO_DRIVE="da0" in your config?


Ok, I've accidentally left it at the screen, so it turns out that it just sits there on every boot for a minute and then starts booting. Why the wait I wonder?

I've played around and yes, the NANO_DRIVE variable if set incorrectly will not let the os boot showing an error message. If the FreeBSD drive is ada0 and the NanoBSD drive is ada1, then if we compile the default NANO_DRIVE value (NANO_DRIVE=ada0) in, booting NanoBSD (the ada1 drive) will show an error. However if we disable the FreeBSD drive (ada0) and try to boot the NanoBSD drive, it will boot successfully, because the NanoBSD drive becomes ada0 (NANO_DRIVE=ada0).

That's a problem with me because I want portability. I want to be able to stick it in and go, not worrying about how many devices may already be present in the different machines I want to use my NanoBSD image on. Wondering if there's a workaround to this?


----------



## Bobi B. (Sep 2, 2018)

Best don't use device names, but labels (glabel(8)), like /dev/ufs/nanoroot1. This way it wouldn't matter if you wrote your nanobsd image to a USB flash drive or a SSD, for example. UFS label can be set with newfs(8) when creating new UFS filesystem, or with tunefs(8) at a later time. I believe nanobsd script can label filesystems for you; or you can add a custom step to do so and to patch /etc/fstab.


----------



## cL0N31 (Sep 2, 2018)

Bobi B. said:


> Best don't use device names


Looks like there's label support for NanoBSD at least in a BSDRP patch.

Would Poudreire be possibly better in this regard through the efi support?

Can FreeBSD use guid to look for the right drive?


----------



## Bobi B. (Sep 3, 2018)

With GPT you can label partitions, as well (/dev/gpt/...). OTOH GUIDs are more likely to be unique, but are not that convenient, nor readable.


----------



## kpa (Sep 3, 2018)

cL0N31 said:


> Looks like there's label support for NanoBSD at least in a BSDRP patch.
> 
> Would Poudreire be possibly better in this regard through the efi support?
> 
> Can FreeBSD use guid to look for the right drive?



Poudriere is only for building ports, it has nothing to do with the base system configuration.


----------



## cL0N31 (Sep 4, 2018)

kpa said:


> Poudriere is only for building ports, it has nothing to do with the base system configuration.


I referred to the Poudriere image:


> Partition scheme
> 
> The resulting images partition layout will have the same behavior than a nanobsd
> 
> GPT partition with EFI bootloader (nanobsd uses a MBR scheme with BIOS bootloader)


----------



## cL0N31 (Sep 8, 2018)

The NANO_LABEL variable needs to be set in order for the image to be portable in the way I explained earlier in this thread. I was able to completely omit the NANO_DRIVE variable, setting just the NANO_LABEL variable and the system booted right up when I tried the both the regular sata or usb ports. I checked fstab entries, sure enough everything's called by the label passed to the variable.

It was very nice to discover that NanoBSD does that out of the box, instead of having to do custom patching


----------

