Solved mfsBSD with high res

Phishfry said:
My images takes approximately 120 seconds at the MFSBOOT stage. It must uncompress MFSROOT file to memory.
I am messing with microSD cards to boot MFSROOT and really slow processor.
Click to expand...
A slow processor is indeed not ideal to uncompress gziped archives, especially when they are large ( 1+ GB).

Is this related to

https://forums.freebsd.org/threads/minimal-xorg-minimal.101242

Phishfry said:
I was wondering if I could build a non-compressed MFS archive just for testing.I am pretty sure gzip is why my image is so slow to load.
Click to expand...
Isn't nanoBSD an option for your project?
 
I prefer Poudriere once you setup the whole thing. You can do USB/UFS, ZFS and so many image types that it is a no brainier.
Patched source code branches so easily integrated...

I never liked NanoBSD ping pong partitions. Sizing disk images was a pain just like Poudriere.

I like the general structure of a tool I can use for building custom images with custom packages so easily.
That it is just a series of scripts I can modify to spit out ARM images to my liking is divine.
 
balanga said:
our leading authority on nanoBSD in these forums.
Click to expand...
I can't say I agree with that. I have learned from the masters here. I have no more experience than you do.
Plus you gotta try. It may not work but you won't know unless you try.

I would like to put my knowledge to better use. My FreeBSD Access Point build using NanoBSD was my only real longterm deployment.
 
Phishfry said:
I can't say I agree with that. I have learned from the masters here. I have no more experience than you do.
Plus you gotta try. It may not work but you won't know unless you try.

I would like to put my knowledge to better use. My FreeBSD Access Point build using NanoBSD was my only real longterm deployment.
Click to expand...
I never actually got that working....
 
SharmSuraj said:
mfsBSD is intended to be a lightweight rescue/install RAM environment. The drivers for DRM/KMS graphics rely on certain versions of a kernel and hardware support, meaning they’re suboptimal in any given mfsBSD configuration. Typically, end-users prefer framebuffer or console mode operation instead.
In such high-resolution or GUI environments, it’s always better to install FreeBSD as usual and load drm-kmod after booting.
Click to expand...
The intention is to provide a lightweight rescue environment and having as much information on the screen as possible is very useful and I'm very pleased with the result.

I'm not entirely clear what framebuffer or console mode operation means or how to specify which to use.
 
SharmSuraj said:
The drivers for DRM/KMS graphics rely on certain versions of a kernel and hardware support, meaning they’re suboptimal in any given mfsBSD configuration.
Click to expand...
Additional information on the use case; I suspect balanga is using Ventoy (mentioned in other forum threads of his), a mfsBSD rescue disk is relative small (+- 100M).

A separate, custom mfsBSD image can be created for each graphics card brand (Intel, AMD, Nvidia), copied to the Ventoy disk, and booted as needed.
 
You must log in or register to reply here.
Back
Top