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

[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:

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

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?

 

[tOsYZYny]

Hi - can someone help me understand the FreeBSD boot process better and how I might modify it.

 

[SirDice]

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.

###  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.

 

[tOsYZYny]

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.

 

[SirDice]

once loaded, faster / snappier system

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.

So, if I understand correctly, /boot/root.img is a UFS image of the entire root FS?

Correct.

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)?

That would work. Or build a clean system with make installworld etc. It needs to be a fully functional root filesystem.

Can I compress the UFS image?

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).

Can I use a different FS than UFS?

I suppose so, never tried it. But again, not really useful as ARC is going to cache most of it in memory anyway.

 

[tOsYZYny]

Thanks, food for thought.

 

[bsdcode]

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.

 

[tOsYZYny]

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.

 

[bsdcode]

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).