NanoBSD vs thread. Are there alternatives?

C

cL0N31

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, 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
 
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?
 
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
 
NanoBSD is perfect to build appliances.
I'm running Asterisk on NanoBSD and the resulting appliance is very robust and works very well.
 
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?
 
Figured it was. It's the Introduction to NanoBSD doc last modified over 4 years ago. The handbook is fine though
 
after nanobsd.sh ran for almost 4 hours i get
Code: 
/usr/obj/nanobsd.full/_.mnt: write failed, filesystem is full
and according to this that's normal?
 
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
 
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
 
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.
 
silicium said:
I started using NanoBSD for my home router, then sometimes used a desktop on it
Click to expand...
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?
 
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?
 
Phishfry said:
Did you adjust NANO_DRIVE="ada0" to NANO_DRIVE="da0" in your config?
Click to expand...
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?
 
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.
 
Bobi B. said:
Best don't use device names
Click to expand...
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?
 
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.
 
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?
Click to expand...

Poudriere is only for building ports, it has nothing to do with the base system configuration.
 
You must log in or register to reply here.
Back
Top