Other How would I load root image into memory-backed fs and run the system from that?

T

tOsYZYny

I am using tmpfs for /tmp and that made a significant difference in chromium as well as other apps that use it, but would essentially like to use it for /. The logical steps I can think of are:

1. create root image, optional compression
2. extract root image contents into memory backed device mounted
3. let the system mount other filesystems defined in /etc, import zpools etc.

Where would I start for #2? I came across:
www.freebsd.org

Chapter 15. The FreeBSD Booting Process

An introduction to the FreeBSD Booting Process, demonstrates how to customize the FreeBSD boot process, including everything that happens until the FreeBSD kernel has started, probed for devices, and started init
www.freebsd.org www.freebsd.org

I think all I need to do is write a simple enough script, but how do I get the system to run it without blowing up other things?
 
I doubt it's going to make much impact. For the most part the file and process caches already ensure most things are loaded and started from memory anyway. The downside of having your root filesystem on a (in essence) RAM disk is going to make updating rather painful too. So it's a lot of hassle for little to no gain.

That said, for a Live CD image or similar it would make sense. And there are various ways you could achieve this. It's rather hidden away but the possibility of booting from a memory disk has been available for a very long time.
Code: 
###  Initial memory disk settings  ###########################
#mdroot_load="YES"              # The "mdroot" prefix is arbitrary.
#mdroot_type="md_image"         # Create md(4) disk at boot.
#mdroot_name="/boot/root.img"   # Path to a file containing the image.
#rootdev="ufs:/dev/md0"         # Set the root filesystem to md(4) device.
 
Yes, I fully understand making updates painful - I did that in a previous life using Funtoo Linux. Hopefully I would benefit by:
1. having a working snapshot for a system
2. once loaded, faster / snappier system
3. ability to use other disks as I would normally for persistence

I'll need to explore that more.

So, if I understand correctly, /boot/root.img is a UFS image of the entire root FS? So, if I first install to disk, I would then need to make an image of that and dump it to /boot/root.img (or wherever)? Can I compress the UFS image? Can I use a different FS than UFS?

I would still need to read more about those options and how I can manually setup the system outside of the FreeBSD installer.
 
tOsYZYny said:
once loaded, faster / snappier system
Click to expand...
Unlikely due to file and process cache on a 'regular' system. Everything is already cached in memory. It's only the first time when you open something it's loaded from disk.

tOsYZYny said:
So, if I understand correctly, /boot/root.img is a UFS image of the entire root FS?
Click to expand...
Correct.
tOsYZYny said:
So, if I first install to disk, I would then need to make an image of that and dump it to /boot/root.img (or wherever)?
Click to expand...
That would work. Or build a clean system with make installworld etc. It needs to be a fully functional root filesystem.
tOsYZYny said:
Can I compress the UFS image?
Click to expand...
Yes, but as far as I know that's going to make it read-only. Can't find the man page, it's been too long ago. Edit: found it: geom_uzip(4).

tOsYZYny said:
Can I use a different FS than UFS?
Click to expand...
I suppose so, never tried it. But again, not really useful as ARC is going to cache most of it in memory anyway.
 
I actually doubt that mdroot is intended to boot a full FreeBSD system from a memory backed filesystem. I just tested it with 13.0-RELEASE distribution sets base.txz and kernel.txz, which I extracted to an UFS formatted 8GB memory disk, which resulted in a 312MB mkuzip(8)'ed image file. That is way too large, loader.efi responds with efi_check_space: Unable to expand staging area. Increasing the EFI_STAGING_SIZE in /usr/src/stand/efi/loader/copy.c from 64 to 512 didn't help. Now the loader just freezes.

I think it is only intended to boot a stripped down root, which can then bootstrap the real root. GhostBSD does it that way. I wonder how /usr/src/tools/tools/nanobsd does it.
 
Thanks - I ultimately decided to scrap the live system idea since the most important thing to me is to merely be able to have the ability to setup FreeBSD how I like it fairly quickly in a completely automated fashion. For testing that FreeBSD will work on the specific hardware, I boot something like GhostBSD. After that, I customize it using a scripted bsdinstall.
 
After searching a little bit more I have to adjust my previous statement: in theory, mdroot should be able to boot a full FreeBSD system (after increasing EFI_STAGING_SIZE), but there seems to be a bug which causes the loader to freeze when the staging size is larger than 64MB (PR 251866 and PR 255073).
 
bsdcode said:
After searching a little bit more I have to adjust my previous statement: in theory, mdroot should be able to boot a full FreeBSD system (after increasing EFI_STAGING_SIZE), but there seems to be a bug which causes the loader to freeze when the staging size is larger than 64MB (PR 251866 and PR 255073).
Click to expand...
Hmm, I reread this message now for some random reason and I think I misinterpreted the post originally to mean that it isn't possible.

However, I am looking at nanobsd and came across md and diskless. Perhaps it is just a matter of properly configuring nanobsd to:

1. strip down BSD to the essentials
2. copy necessary files into memory disk
3. unmount disk
4. continue booting from memory disk

If anyone is knowledgeable on nanobsd, I would be interested to know if I could run any script of my choosing at boot. If so, then I believe nanobsd expects /cfg to be read-only and /etc to be read-write. Then, if I could merely copy the contents of a root image to /cfg, unmount the root image, and let it resume the boot process, then problem solved.
 
Isn't mfsBSD what you are looking for?

From the description
Rich (BB code): 
This is a set of scripts that generates a bootable image (and/or ISO file), that creates a working minimal installation of
FreeBSD (mfsBSD) ... It is completely loaded into memory.

mfsBSD has an set of default packages configured to build in the image (tools/packages.sample), which can be extended/modified to packages you like to see in the image.

But, depending on the read speed of the media mfsBSD is stored on, I imagine it could take some time to load the image into memory with heavy packages (and their dependencies) installed like chromium.
 
T-Daemon said:
Isn't mfsBSD what you are looking for?

From the description
Rich (BB code): 
This is a set of scripts that generates a bootable image (and/or ISO file), that creates a working minimal installation of
FreeBSD (mfsBSD) ... It is completely loaded into memory.

mfsBSD has an set of default packages configured to build in the image (tools/packages.sample), which can be extended/modified to packages you like to see in the image.

But, depending on the read speed of the media mfsBSD is stored on, I imagine it could take some time to load the image into memory with heavy packages (and their dependencies) installed like chromium.
Click to expand...
Perfect, that sounds exactly what I want to do.

Yes, so I have a comparable system in Linux that is a 6GB zstd compressed squashfs image that takes about 50s to load entirely in memory. I hope I can attain similar results.

The interesting thing with nanobsd is that it sounds like I can make extremely tiny images. If I can also get those loaded entirely into memory, that'd be great. I want to build a small IoT appliance that performs 1 network function, that's it. But as everything in life, I'm sure that 1 thing might turn into more depending on how well that works.
 
From what I can gather, it appears the root image is limited to 50MB in size. To start, I would like to load my entire system into memory, which when compressed is about 6GB in size. My system has 16 GB of ram, so it should be no problem.

Is that possible, or must it be around 50 MB from what I've seen?
 
tOsYZYny said:
From what I can gather, it appears the root image is limited to 50MB in size.
Click to expand...
That is not correct. The default size is set to 120m, but it can be extended as necessary by modifying the mfsroot size variable.

mfsBSD/Makefile
Code: 
MFSROOT_MAXSIZE?=       120m
6GB should be 6000m. I'm not sure if 6G is accepted.

I have experimented with mfsBSD before, it can be highly customized to your needs.
 
Might you have an example of building an image via mfsbsd?

I modified the Makefile and specified the size as indicated above, I see there are a bunch of options I can tweak, but just to start I want to start with something basic.

I am trying:
make iso CUSTOM=1 BUILDWORLD=1 BUILDKERNEL=1
Click to expand...
 
tOsYZYny said:
Might you have an example of building an image via mfsbsd?
Click to expand...
Sure, no problem.

I never tried BUILDWORLD=1, BUILDKERNEL=1, I use packaged distribution files.

On my laptop I update the system from source, as a side usage create memstick and iso images from the built source for VMs. kernel.txz and base.txz are created in this process. I use those distribution files for jails and mfsBSD testing.

It's not necessary to build from source at all. Those base and kernel distribution files can be obtained from a memstick.img, disk.iso, dvd.iso or as packages from FreeBSD remote repositories with the latest patches on STABLE:


For example, on my system are multiple, permanent mfsBSD GIT clones for testing, including a freebsd-dist directory, containing kernel.txz and base.txz. :
Code: 
% ls -F /usr/tmp/Git/mfsBSD
freebsd-dist/   mfsbsd-geli/    mfsbsd-old/     mfsbsd-vanilla/

In the mfsBSD root directory execute
Code: 
# make iso BASE=../freebsd-dist

The built images can be tested attached to virtual machines (.img or .iso on bhyve and VirtualBox, .img as .vmdk or .vdi convertfromraw).

By the way, on that mfsbsd-geli directory I tested for your geli encrypted inner, unencrypted outer system, remote ssh, reboot -r project.


EDIT: Tested CUSTOM=1 (BUILD.md - "To use your own but already built world and kernel, use CUSTOM=1), for some reason this creates a larger image than images created with distribution files.:
Rich (BB code): 
# make iso CUSTOM=1

-rw-r--r--  1 root wheel  249M Apr 28 16:26 mfsbsd-14.2-RELEASE-p3-amd64.iso

# make iso BASE=../freebsd-dist

-rw-r--r--  1 root wheel   76M Apr 28 16:34 mfsbsd-14.2-RELEASE-p3-amd64.iso
 
You must log in or register to reply here.
Back
Top