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.
 
I had this working previously but wanted to make some changes, but unfortunately I get:-

Creating and compressing mfsroot ...makefs: `/var/tmp/mfsbsd/work/mfs' size of 232521728 is larger than the maxsize of 209715200.
Click to expand...

It looks like drm-kmod is taking up a lot of space.

I have:-

MFSROOT_MAXSIZE=4096M
 
I have made a change to add drm-66-kmod instead of drm-kmode but still get maxsize error.

I did have this working before, God knows how....
 
T-Daemon said:
I would grep for the MFSROOT_MAXSIZE. It looks like there is one set to 200m, which overrides the 4096M.

Alternatively git-clone(1) a frech copy of mfsBSD.
Click to expand...
Changing this value helped and I was able build mfsbsd after including the drm-kmod package.

Unfortunately drm-kmod does not load. I get these errors:-


KLD drm.ko: depends on iic - not available or version mismatch
linker_load_file: /boot/modules/drm.ko - unsupported file type
KLD i915kms.ko: depends on drmn - not available or version mismatch
linker_load_file: /boot/modules/i915kms.ko - unsupported file type
Click to expand...

This is very frustrating as I had this working at one point.
 
balanga, I know that you explicitly required drm-kmod but why?
If it's to load a graphical environment, scfb or vesa are enough (albeit at lower resolutions) and as long as you have network available you can later on pull more packages to enable more functionality.
If you get it working great but if its just a rescue image maybe it's complicating stuff.
 
balanga said:
Unfortunately drm-kmod does not load. I get these errors:-
Code: 
 KLD drm.ko: depends on iic - not available or version mismatch
Click to expand...
Obviously the kernel and the drm-kmod kernel module are out of sync. From where did you get the kernel.txz and base.txz? If it is from official RELEASE repositories, then they are outdated.

To prevent this kind of mismatch in the future, make sure the kernel version aligns with the currently available drm-kmod package. The most reliable way to do that is to build fresh kernel.txz and base.txz [1], or don't use distribution sets, install from built source [2].

[1] Assuming /usr/src is a up-to-date releng/15.0 local git repository:
Code: 
# cd /usr/src
# make -j <nr_of_cpus> buildworld buildkernel
# cd release
# make kernel.txz base.txz

The packages can be found under /usr/obj/usr/src/amd64.amd64/release

[2] Assuming /usr/src is a up-to-date releng/15.0 local git repository.
Code: 
#  cd /root_dir_of/mfsBSD

#  make iso CUSTOM=1 BUILDWORLD=1 BUILDKERNEL=1

Documentation:

Code: 
# If you want to build your own kernel and make you own world, you need to set
# -DCUSTOM or CUSTOM=1
#
# To make buildworld use 
# -DCUSTOM -DBUILDWORLD or CUSTOM=1 BUILDWORLD=1
#
# To make buildkernel use
# -DCUSTOM -DBUILDKERNEL or CUSTOM=1 BUILDKERNEL=1
#
# For all of this use
# -DCUSTOM -DBUILDWORLD -DBUILDKERNEL or CUSTOM=1 BUILDKERNEL=1 BUILDWORLD=1

Rich (BB code): 
To use your own but already built world and kernel, `use CUSTOM=1`.

If you want this script to do `make buildworld` and `make buildkernel` for you,
specify the `BUILDWORLD=1` and `BUILDKERNEL=1` variables to `make`, respectively.

## Examples

1. Disk image

  ```bash
  make BASE=/cdrom/usr/freebsd-dist
  make BASE=/cdrom/10.2-RELEASE
  make CUSTOM=1 BUILDWORLD=1 BUILDKERNEL=1
  ```

2. Bootable ISO file:

  ```bash
  make iso BASE=/cdrom/usr/freebsd-dist
  make iso BASE=/cdrom/10.2-RELEASE
  make iso CUSTOM=1 BUILDWORLD=1 BUILDKERNEL=1
 
fahrenheit said:
balanga, I know that you explicitly required drm-kmod but why?
If it's to load a graphical environment, scfb or vesa are enough (albeit at lower resolutions) and as long as you have network available you can later on pull more packages to enable more functionality.
If you get it working great but if its just a rescue image maybe it's complicating stuff.
Click to expand...
I like to have as many lines on the screen as possible. Not sure what you mean by using scfb or vesa, What would I change to enable them?

The problem is that I did manage to create what I wanted not long ago but somehow can't re-create it.
 
You must log in or register to reply here.
Back
Top