Why "Install" at all?

gladiola

gladiola

As I've been tinkering from the shell on the install disk, I wonder what's the disadvantage of running from it all the time?

Like, if we can mount a filesystem off of /tmp, kldload modules, and script a jail: then do we need to give up hard drive space for a permanent boot?

It seems like maybe an advanced user could just use disk storage for storage all the time. Is this true? What are the disadvantages of this?

Sorry for such a broad question, but it never occurred to me to try to just totally skip the entire install process before.
 
Good point. I'm also wondering about the FreeBSD updates and security patches. I'm not sure how that will work out. If we follow the general rule that the jail can't be ahead of the host operating system, and the OS was issued in November 2019: then maybe running freebsd-update in a jail won't have the full effect. I don't now.

One of the advantages I was considering was the read and write speed increase off of triple mirrors. Three mirrors of a disk instead of an OS disk with some fractional storage and a mirror pair of storage disks. Capacity would be lower, but speed would be up.

I was looking over the chapters on different kinds of RAIDZ and disk combinations in a book by Jude and Lucas. On an old box that maxes out at three hard disks, it might be the way to get the most out of it. Could maybe add on a RAIDZ-2 of some USB drives. Still have an optical disk or USB port to boot from.
 
You can run your OS from a reasonably big USB thumb drive -- like what NomadBSD does -- if you do not update too often. If your system has plenty of RAM for buffers & caches (& tmpfs(5) for /tmp & /var/{run,tmp}), it will be fast enough for common usage if it's USB 3.x. You shouldn't swap to a USB thumb drive or write to it too often, because it will wear out quickly. But I see no reason not to put swap & data on the HDD & the OS on a thumb drive.
 
Your idea looks like SmartOS, running entirely from RAM, no installation.
 
I just restarted and now I'm on nomadBSD to answer here.
I have the installation done on a 250 GB Samsung external/usb HDD with UFS.

I update as many times as necessary and nomad really behaves as I expected: very good!

Being a FreeBSD pre-configured with OpenBox, obviously zero problems.


nomad@NomadBSD:~% cat /etc/fstab
/dev/label/nomadroot / ufs rw,noatime 1 1
tmpfs /tmp tmpfs rw,mode=1777 0 0
tmpfs /var/log tmpfs rw 0 0
proc /proc procfs rw 0 0

/dev/label/nomadhome /home ufs rw,noatime 1 1

linprocfs /compat/linux/proc linprocfs rw 0 0
linsysfs /compat/linux/sys linsysfs rw 0 0
tmpfs /compat/linux/dev/shm tmpfs rw,mode=1777 0 0



nomad@NomadBSD:~% uname -Ua
FreeBSD NomadBSD 12.1-RELEASE-p6 FreeBSD 12.1-RELEASE-p6 #0 r362945M: Sun Jul 5 15:46:22 UTC 2020 ich@riara.uni.cx:/usr/obj/usr/src/amd64.amd64/sys/NOMADBSD amd64 1201000



nomad@NomadBSD:~% lsblk
da0 0:134 233G MBR - -
<FREE> -:- 512B - - -
da0s1 0:135 40M efi - -
da0s2 0:136 3.9G BSD - -
da0s2a 0:139 3.9G freebsd-ufs label/nomadroot /
da0s3 0:137 229G BSD - -
da0s3a 0:140 229G freebsd-ufs label/nomadhome /home
md0 0:120 2.0G - - -


HTOP.png

↓
with Chromium + Youtube running at full speed.
 
gladiola said:
It seems like maybe an advanced user could just use disk storage for storage all the time. Is this true? What are the disadvantages of this?
Click to expand...
A cheap flash drive like an USB thumb drive will wear out very quickly. The number of writes to the NVRAM is limited. Cheap: less write cycles, expensive: more write cycles. You will have to layout your filesystem carefully (see above), and restrict yourself to updates less often.
 
I think I may try a combination. Swap partitions and zfs on the disks. Boot from install. And a small collection of thumbdrives in RAIDZ-2. Maybe experiment some with that PEF.

So, take the boot from install disk. Manually decrypt and attach disks as needed. Use swapon to lace in some partitions for active swap. Use the array of thumb drives to hold geli keys, geli metadata, and any startup or utility scripts.

Curious about killing and restoring. I'm sure there's no peril there, right. Maybe practice first before loading down those drives.
 
We run most of customer's servers from 16G SATA DOMs, last couple of years, using nanobsd. We build, test and deploy so-called "images" that are easy to install and atomically upgrade/rollback. Using reboot -r one can also "reload" the OS without full reboot (saves few minutes). 4GB USB flash drives are also an option, but some of them tend to drop from the bus every now and then (probably due to powersave? there are couple of threads about that in the forums).
 
gladiola said:
I think I may try a combination. Swap partitions and zfs on the disks. Boot from install. And a small collection of thumbdrives in RAIDZ-2. Maybe experiment some with that PEF.

So, take the boot from install disk. Manually decrypt and attach disks as needed. Use swapon to lace in some partitions for active swap. Use the array of thumb drives to hold geli keys, geli metadata, and any startup or utility scripts.

Curious about killing and restoring. I'm sure there's no peril there, right. Maybe practice first before loading down those drives.
Click to expand...
In general, the OS's root filessystem should be mounted read-only on a thumb drive, so put /var on the HDD. Remount R/W when updating packages or editing configuration. Beware: /var/db/pkg must match the packages installed on /usr/local, but most other subdirectories under /var can be shared between boot environments, except (?) /var/backups. Personally, I would not go with GELI encrytion -- maybe except for swap -- but only encrypt sensitive data with sysutiuls/pefs-kmod.
 
I am quite sure that this would be very much possible. If you tried you would end up with a system layout that is similar to one you'd see in a setup where nothing but a bit of compact flash is available to hold your system. Just in reverse. In the compact flash setup you make sure all unimportant writes get mapped to memory (tmpfs/ramdrive) which would be the default for you. For areas where you care about writes (/etc,...) you layer some writable space over your read only root. The root in your case is already writable but volatile so the solution would be the same. This works very well but it's nothing you setup with one or two lines of shell code. Also this really should be done before services and so on get started. With the installer shell you are probably a bit late for this and would have to (at least) partly redo this which might be a bit tricky.
 
I've got no problem with erasing some hard drives and starting over. I do that all the time anyway. Also, we don't have to get it right on the first try. Thanks to everyone for your advice. I will probably work on this some more this weekend.
 
You must log in or register to reply here.
Back
Top