Re: git: 4a864f624a70 - main - vm_pageout: Print a more accurate message to the console before an OOM kill [MFC in time for 13.1?]

[Mark Millard]

On 2022-Feb-26, at 17:10, Mark Millard  wrote:

> On 2022-Jan-15, at 07:55, Mark Johnston  wrote:
> 
>> On Fri, Jan 14, 2022 at 09:38:56PM -0800, Mark Millard wrote:
>>> Thanks. This will allow me to remove part of my personal additions
>>> in this area --and my having to explain the misnomer when trying
>>> to help someone analyze why they end up with OOM activity so they
>>> can figure out what to do about it.
>>> 
>>> There seem to be two separate sources of VM_OOM_SWAPZ. Showing
>>> my personal additions for them (just making them explicit in the
>>> sequence of messages generated):
>>> 
>>> diff --git a/sys/vm/swap_pager.c b/sys/vm/swap_pager.c
>>> index 01cf9233329f..280621ca51be 100644
>>> --- a/sys/vm/swap_pager.c
>>> +++ b/sys/vm/swap_pager.c
>>> @@ -2091,6 +2091,7 @@ swp_pager_meta_build(vm_object_t object, vm_pindex_t 
>>> pindex, daddr_t swapblk)
>>>   0, 1))
>>>   printf("swap blk zone exhausted, "
>>>   "increase kern.maxswzone\n");
>>> +   printf("swp_pager_meta_build: swap blk uma 
>>> zone exhausted\n");
>>>   vm_pageout_oom(VM_OOM_SWAPZ);
>>>   pause("swzonxb", 10);
>>>   } else
>>> @@ -2121,6 +2122,7 @@ swp_pager_meta_build(vm_object_t object, vm_pindex_t 
>>> pindex, daddr_t swapblk)
>>>   0, 1))
>>>   printf("swap pctrie zone exhausted, "
>>>   "increase kern.maxswzone\n");
>>> +   printf("swp_pager_meta_build: swap pctrie 
>>> uma zone exhausted\n");
>>>   vm_pageout_oom(VM_OOM_SWAPZ);
>>>   pause("swzonxp", 10);
>>>   } else
>>> 
>>> Care to comment on the distinctions and why there are two
>>> contexts classified as "out of swap space"? Would either
>>> one show the swap space as (nearly?) all used in, say, top?
>>> Or might one of them still end up looking like a misnomer
>>> from just a top (or whatever) display?
>> 
>> Hmm, those cases should likely be changed from "out of swap space" to
>> "failed to allocate swap metadata" or something like that.
> 
> The above does not seem to have happened yet in main [so: 14].
> 
> Will 13.1 get an MFC of 4a864f624a70 in time, possibly with the
> above change also in place to fully avoid misnomer reporting
> that misleads folks?
> 
> 4a864f624a70 listed:
> 
> MFC after:2 weeks
> 
> but it has been more than a month.
> 
>> . . .
>> 
> 

Thanks for the stable/13 MFC as 13ba1d283676. It
provides a big improvement over the prior messaging
for the OOM kills.



For reference, I do still view:

+   case VM_OOM_SWAPZ:
+   reason = "out of swap space";
+   break;

as using a confusing misnomer ("swap space") for its
message. But, so far as I know, VM_OOM_SWAPZ is a
rarity and  possibly very difficult to produce. If
so, any confusions from the message should also be
rare.

===
Mark Millard
marklmi at yahoo.com

Re: bastille : poudriere not working in jail: jail: jail:_set: Operation not permitted!

[FreeBSD User]

On Mon, 28 Feb 2022 17:11:27 +0100
Michael Gmelin  wrote:

[...]
schnipp
[...]
> > 
> > poudriere jail -l:
> > 
> > # poudriere jail -l
> > JAILNAME VERSION ARCH METHOD TIMESTAMP PATH
> > 123-amd64 12.3-RELEASE amd64
> > url=https://download.freebsd.org/releases/a ... 3-RELEASE/ 2022-02-24
> > 14:14:25 /mnt/poudriere/jails/123-amd64 130-amd64 13.0-RELEASE amd64
> > url=https://download.freebsd.org/releases/a ... 0-RELEASE/ 2022-02-24
> > 14:11:32 /mnt/poudriere/jails/130-amd64
> > 
> > The jail.conf for this specific jail is as follows:
> > 
> > [...]
> > pulverfass-001 {
> > devfs_ruleset = 13;
> > enforce_statfs = 1;
> > exec.clean;
> > exec.consolelog =
> > /mnt/extensions/bastille/logs/pulverfass-001_console.log; exec.start
> > = '/bin/sh /etc/rc'; exec.stop = '/bin/sh /etc/rc.shutdown';
> > host.hostname = X;
> > mount.devfs;
> > mount.fstab = /mnt/extensions/bastille/jails/pulverfass-001/fstab;
> > path = /mnt/extensions/bastille/jails/pulverfass-001/root;
> > securelevel = 0;
> > 
> > vnet;
> > vnet.interface = e0b_bastille4;
> > exec.prestart += "jib addm bastille4 igb0";
> > exec.prestart += "ifconfig e0a_bastille4 description \"vnet host
> > interface for Bastille jail pulverfass-001\""; exec.poststop += "jib
> > destroy bastille4";
> > 
> > allow.mount;
> > allow.mount.fdescfs;
> > allow.mount.devfs;
> > allow.mount.tmpfs;
> > allow.mount.nullfs;
> > allow.mount.procfs;
> > allow.mount.linsysfs;
> > allow.mount.linprocfs;
> > allow.mount.zfs;
> > 
> > allow.chflags;
> > allow.raw_sockets;
> > allow.socket_af;
> > allow.sysvipc;
> > 
> > linux = new;
> > 
> > exec.created += "/sbin/zfs jail ${name} BUNKER00/poudriere";
> > exec.start += "/sbin/zfs mount -a";
> > exec.poststop += "/sbin/zfs unjail BUNKER00/poudriere";
> > 
> > }
> > [...]
> > 
> > Tracking the execution of the build process by issuing
> > 
> > poudriere -x bulk ...
> > 
> > and examin the resulting trace doesn' tgive me any hint, the error
> > reported above immediately occurs when the jail is about to be
> > started:
> > 
> > + set -u +x
> > + jail -c persist 'name=123-amd64-head-default'
> > 'path=/mnt/poudriere/data/.m/ \ 123-amd64-head-default/ref'
> > 'host.hostname=basehost.local.domain' \ 'ip4.addr=127.0.0.1'
> > 'ip6.addr=::1' allow.chflags allow.sysvipc jail: jail_set: Operation
> > not permitted
> > + exit_handler
> > [...]
> > 
> > Searching the net revealed some issues with setting IP4 and IP6 in
> > poudriere, but those findings are dated back to 2017 and 2014 and I
> > guess this is solved right now.
> > 
> > The difference between our manually jail.conf driven setup and the
> > XigmaNAS/bastille based one is, bastille uses jib/netgraph based
> > seutups of the vnet and the ip4/ip6 is setup from rc.conf, while we
> > use epair in the other world and the ip is setup from withing the
> > jail definition in jail.conf.
> > 
> > I'm out of ideas here and after two days of trial and error and
> > trying to understand what's going on lost ... Any hints or tipps?
> > 
> > Thanks in advance,
> > 
> > O. Hartmann  
> 
> Hi Oliver,
> 
> I don't see `children.max` set in any of the configuration you shared
> above.
> 
> Cheers
> Michael
> 

Hello Michael,

bummer! I was so selfconfident because I copied the initial config from a 
working test
and had this attribute already set that I never checked again its existence - 
and started
reorganizing the jail.conf attributes ... 
A fine observation and a full hit: after setting children.max= 128; the 
poudriere jail
started working ... didn't wait for the finish so far.

I'm sorry for the noise - thanks for you eyes ...

Kind regards,

Oliver

Re: bastille : poudriere not working in jail: jail: jail:_set: Operation not permitted!

[Michael Gmelin]

On Mon, 28 Feb 2022 16:15:45 +0100
FreeBSD User  wrote:

> Hello folks,
> 
> we run at least two poudriere build systems on recent CURRENT boxes
> and one of these poudriere build systems is working within a jail -
> setup via FreeBSD's /etc/jail.conf and by misusing the port ezjail
> for copying/deploying our self-compiled jail binary. The poudriere
> jail uses ZFS and is, to make it short, working like a charme.
> 
> Now we try to setup another poudriere, but this time the base is
> XigmaNAS 12.3.0.4/9009, which is based upon 12.X-RELENG, utilizing
> "bastille". Bastille is up to date (in terms od the XigmaNAS plugin).
> 
> Following the setup we used on the native CURRENT "jailed poudriere"
> builder and also following this reference (for those who want to
> check on this)
> 
> https://www.mimar.rs/blog/host-your-own-services-with-freebsd-jails-part-3-poudriere
> 
> which seems quite recent and with the exception, that we use "vnet"
> on all of our systems for jails and so does XigmaNAS.
> 
> Starting a building process via poudriere ends up with
> 
> 
> # poudriere bulk -p head -z default -j 123-amd64 -f
> /usr/local/etc/poudriere.d/zeit4-default.pkglist [00:00:00] Creating
> the reference jail... done [00:00:01] Mounting system devices for
> 123-amd64-head-default [00:00:01] Warning: Using packages from
> previously failed, or uncommitted, build:
> /mnt/poudriere/data/packages/123-amd64-head-default/.building
> [00:00:01] Mounting ports from: /mnt/poudriere/ports/head [00:00:01]
> Mounting packages from:
> /mnt/poudriere/data/packages/123-amd64-head-default [00:00:01]
> Mounting distfiles from: /mnt/poudriere/ports/distfiles [00:00:01]
> Copying /var/db/ports from:
> /usr/local/etc/poudriere.d/head-amd64-head-default-options [00:00:02]
> Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
> /etc/resolv.conf ->
> /mnt/poudriere/data/.m/123-amd64-head-default/ref/etc/resolv.conf
> [00:00:02] Starting jail 123-amd64-head-default jail: jail_set:
> Operation not permitted [00:00:02] Cleaning up [00:00:02] Unmounting
> file systems
> 
> poudriere jail -l:
> 
> # poudriere jail -l
> JAILNAME VERSION ARCH METHOD TIMESTAMP PATH
> 123-amd64 12.3-RELEASE amd64
> url=https://download.freebsd.org/releases/a ... 3-RELEASE/ 2022-02-24
> 14:14:25 /mnt/poudriere/jails/123-amd64 130-amd64 13.0-RELEASE amd64
> url=https://download.freebsd.org/releases/a ... 0-RELEASE/ 2022-02-24
> 14:11:32 /mnt/poudriere/jails/130-amd64
> 
> The jail.conf for this specific jail is as follows:
> 
> [...]
> pulverfass-001 {
> devfs_ruleset = 13;
> enforce_statfs = 1;
> exec.clean;
> exec.consolelog =
> /mnt/extensions/bastille/logs/pulverfass-001_console.log; exec.start
> = '/bin/sh /etc/rc'; exec.stop = '/bin/sh /etc/rc.shutdown';
> host.hostname = X;
> mount.devfs;
> mount.fstab = /mnt/extensions/bastille/jails/pulverfass-001/fstab;
> path = /mnt/extensions/bastille/jails/pulverfass-001/root;
> securelevel = 0;
> 
> vnet;
> vnet.interface = e0b_bastille4;
> exec.prestart += "jib addm bastille4 igb0";
> exec.prestart += "ifconfig e0a_bastille4 description \"vnet host
> interface for Bastille jail pulverfass-001\""; exec.poststop += "jib
> destroy bastille4";
> 
> allow.mount;
> allow.mount.fdescfs;
> allow.mount.devfs;
> allow.mount.tmpfs;
> allow.mount.nullfs;
> allow.mount.procfs;
> allow.mount.linsysfs;
> allow.mount.linprocfs;
> allow.mount.zfs;
> 
> allow.chflags;
> allow.raw_sockets;
> allow.socket_af;
> allow.sysvipc;
> 
> linux = new;
> 
> exec.created += "/sbin/zfs jail ${name} BUNKER00/poudriere";
> exec.start += "/sbin/zfs mount -a";
> exec.poststop += "/sbin/zfs unjail BUNKER00/poudriere";
> 
> }
> [...]
> 
> Tracking the execution of the build process by issuing
> 
> poudriere -x bulk ...
> 
> and examin the resulting trace doesn' tgive me any hint, the error
> reported above immediately occurs when the jail is about to be
> started:
> 
> + set -u +x
> + jail -c persist 'name=123-amd64-head-default'
> 'path=/mnt/poudriere/data/.m/ \ 123-amd64-head-default/ref'
> 'host.hostname=basehost.local.domain' \ 'ip4.addr=127.0.0.1'
> 'ip6.addr=::1' allow.chflags allow.sysvipc jail: jail_set: Operation
> not permitted
> + exit_handler
> [...]
> 
> Searching the net revealed some issues with setting IP4 and IP6 in
> poudriere, but those findings are dated back to 2017 and 2014 and I
> guess this is solved right now.
> 
> The difference between our manually jail.conf driven setup and the
> XigmaNAS/bastille based one is, bastille uses jib/netgraph based
> seutups of the vnet and the ip4/ip6 is setup from rc.conf, while we
> use epair in the other world and the ip is setup from withing the
> jail definition in jail.conf.
> 
> I'm out of ideas here and after two days of trial and error and
> trying to understand what's going on lost ... Any hints or tipps?
> 
> Thanks in advance,
> 
> O. Hartmann

Hi Oliver,

I don't see `children.max` set in any of the configuration you shared
above.

Cheers
Michael

-- 
Michael Gmelin

Re: bastille : poudriere not working in jail: jail: jail:_set: Operation not permitted!

[Mateusz Guzik]

There is a number of places which can return EPERM, to paste an example:

if (gotslevel) {
if (slevel < ppr->pr_securelevel) {
error = EPERM;
goto done_deref_locked;
}
}
if (gotchildmax) {
if (childmax >= ppr->pr_childmax) {
error = EPERM;
goto done_deref_locked;
}
}
if (gotenforce) {
if (enforce < ppr->pr_enforce_statfs) {
error = EPERM;
goto done_deref_locked;
}
}

I see in your config you have  enforce_statfs = 1; , perhaps that's
smaller than what the host has and in that case you would get the
error.

Ultimately, while cumbersome, you can add printf to the code to find
out which case is giving you the error.

The real thing to do here would be implement something like SET_ERROR
from illumos, which would allow to immediately pin point where the
problem is coming from.

On 2/28/22, FreeBSD User  wrote:
> Hello folks,
>
> we run at least two poudriere build systems on recent CURRENT boxes and one
> of these
> poudriere build systems is working within a jail - setup via FreeBSD's
> /etc/jail.conf and
> by misusing the port ezjail for copying/deploying our self-compiled jail
> binary. The
> poudriere jail uses ZFS and is, to make it short, working like a charme.
>
> Now we try to setup another poudriere, but this time the base is XigmaNAS
> 12.3.0.4/9009,
> which is based upon 12.X-RELENG, utilizing "bastille". Bastille is up to
> date (in terms
> od the XigmaNAS plugin).
>
> Following the setup we used on the native CURRENT "jailed poudriere" builder
> and also
> following this reference (for those who want to check on this)
>
> https://www.mimar.rs/blog/host-your-own-services-with-freebsd-jails-part-3-poudriere
>
> which seems quite recent and with the exception, that we use "vnet" on all
> of our systems
> for jails and so does XigmaNAS.
>
> Starting a building process via poudriere ends up with
>
>
> # poudriere bulk -p head -z default -j 123-amd64 -f
> /usr/local/etc/poudriere.d/zeit4-default.pkglist [00:00:00] Creating the
> reference
> jail... done [00:00:01] Mounting system devices for 123-amd64-head-default
> [00:00:01] Warning: Using packages from previously failed, or uncommitted,
> build:
> /mnt/poudriere/data/packages/123-amd64-head-default/.building [00:00:01]
> Mounting ports
> from: /mnt/poudriere/ports/head [00:00:01] Mounting packages from:
> /mnt/poudriere/data/packages/123-amd64-head-default [00:00:01] Mounting
> distfiles from:
> /mnt/poudriere/ports/distfiles [00:00:01] Copying /var/db/ports from:
> /usr/local/etc/poudriere.d/head-amd64-head-default-options [00:00:02]
> Appending to
> make.conf: /usr/local/etc/poudriere.d/make.conf /etc/resolv.conf ->
> /mnt/poudriere/data/.m/123-amd64-head-default/ref/etc/resolv.conf [00:00:02]
> Starting
> jail 123-amd64-head-default jail: jail_set: Operation not permitted
> [00:00:02] Cleaning up
> [00:00:02] Unmounting file systems
>
> poudriere jail -l:
>
> # poudriere jail -l
> JAILNAME VERSION ARCH METHOD TIMESTAMP PATH
> 123-amd64 12.3-RELEASE amd64 url=https://download.freebsd.org/releases/a ...
> 3-RELEASE/
> 2022-02-24 14:14:25 /mnt/poudriere/jails/123-amd64 130-amd64 13.0-RELEASE
> amd64
> url=https://download.freebsd.org/releases/a ... 0-RELEASE/ 2022-02-24
> 14:11:32
> /mnt/poudriere/jails/130-amd64
>
> The jail.conf for this specific jail is as follows:
>
> [...]
> pulverfass-001 {
> devfs_ruleset = 13;
> enforce_statfs = 1;
> exec.clean;
> exec.consolelog = /mnt/extensions/bastille/logs/pulverfass-001_console.log;
> exec.start = '/bin/sh /etc/rc';
> exec.stop = '/bin/sh /etc/rc.shutdown';
> host.hostname = X;
> mount.devfs;
> mount.fstab = /mnt/extensions/bastille/jails/pulverfass-001/fstab;
> path = /mnt/extensions/bastille/jails/pulverfass-001/root;
> securelevel = 0;
>
> vnet;
> vnet.interface = e0b_bastille4;
> exec.prestart += "jib addm bastille4 igb0";
> exec.prestart += "ifconfig e0a_bastille4 description \"vnet host interface
> for Bastille
> jail pulverfass-001\""; exec.poststop += "jib destroy bastille4";
>
> allow.mount;
> allow.mount.fdescfs;
> allow.mount.devfs;
> allow.mount.tmpfs;
> allow.mount.nullfs;
> allow.mount.procfs;
> allow.mount.linsysfs;
> allow.mount.linprocfs;
> allow.mount.zfs;
>
> allow.chflags;
> allow.raw_sockets;
> allow.socket_af;
> allow.sysvipc;
>
> linux = new;
>
> exec.created += "/sbin/zfs jail ${name} BUNKER00/poudriere";
> exec.start += "/sbin/zfs mount -a";
> exec.poststop += "/sbin/zfs unjail BUNKER00/poudriere";
>
> }
> [...]
>
> Tracking the execution of the build process by issuing
>
> poudriere -x bulk ...
>
> and examin the resulting trace doesn' tgive me any hint, the error reported
> above
> immediately occurs when the jail is about to be started:
>
> + set -u +x
> + jail -c persist 'name=123-amd6

bastille : poudriere not working in jail: jail: jail:_set: Operation not permitted!

[FreeBSD User]

Hello folks,

we run at least two poudriere build systems on recent CURRENT boxes and one of 
these
poudriere build systems is working within a jail - setup via FreeBSD's 
/etc/jail.conf and
by misusing the port ezjail for copying/deploying our self-compiled jail 
binary. The
poudriere jail uses ZFS and is, to make it short, working like a charme.

Now we try to setup another poudriere, but this time the base is XigmaNAS 
12.3.0.4/9009,
which is based upon 12.X-RELENG, utilizing "bastille". Bastille is up to date 
(in terms
od the XigmaNAS plugin).

Following the setup we used on the native CURRENT "jailed poudriere" builder 
and also
following this reference (for those who want to check on this)

https://www.mimar.rs/blog/host-your-own-services-with-freebsd-jails-part-3-poudriere

which seems quite recent and with the exception, that we use "vnet" on all of 
our systems
for jails and so does XigmaNAS.

Starting a building process via poudriere ends up with


# poudriere bulk -p head -z default -j 123-amd64 -f
/usr/local/etc/poudriere.d/zeit4-default.pkglist [00:00:00] Creating the 
reference
jail... done [00:00:01] Mounting system devices for 123-amd64-head-default
[00:00:01] Warning: Using packages from previously failed, or uncommitted, 
build:
/mnt/poudriere/data/packages/123-amd64-head-default/.building [00:00:01] 
Mounting ports
from: /mnt/poudriere/ports/head [00:00:01] Mounting packages from:
/mnt/poudriere/data/packages/123-amd64-head-default [00:00:01] Mounting 
distfiles from:
/mnt/poudriere/ports/distfiles [00:00:01] Copying /var/db/ports from:
/usr/local/etc/poudriere.d/head-amd64-head-default-options [00:00:02] Appending 
to
make.conf: /usr/local/etc/poudriere.d/make.conf /etc/resolv.conf ->
/mnt/poudriere/data/.m/123-amd64-head-default/ref/etc/resolv.conf [00:00:02] 
Starting
jail 123-amd64-head-default jail: jail_set: Operation not permitted
[00:00:02] Cleaning up
[00:00:02] Unmounting file systems

poudriere jail -l:

# poudriere jail -l
JAILNAME VERSION ARCH METHOD TIMESTAMP PATH
123-amd64 12.3-RELEASE amd64 url=https://download.freebsd.org/releases/a ... 
3-RELEASE/
2022-02-24 14:14:25 /mnt/poudriere/jails/123-amd64 130-amd64 13.0-RELEASE amd64
url=https://download.freebsd.org/releases/a ... 0-RELEASE/ 2022-02-24 14:11:32
/mnt/poudriere/jails/130-amd64

The jail.conf for this specific jail is as follows:

[...]
pulverfass-001 {
devfs_ruleset = 13;
enforce_statfs = 1;
exec.clean;
exec.consolelog = /mnt/extensions/bastille/logs/pulverfass-001_console.log;
exec.start = '/bin/sh /etc/rc';
exec.stop = '/bin/sh /etc/rc.shutdown';
host.hostname = X;
mount.devfs;
mount.fstab = /mnt/extensions/bastille/jails/pulverfass-001/fstab;
path = /mnt/extensions/bastille/jails/pulverfass-001/root;
securelevel = 0;

vnet;
vnet.interface = e0b_bastille4;
exec.prestart += "jib addm bastille4 igb0";
exec.prestart += "ifconfig e0a_bastille4 description \"vnet host interface for 
Bastille
jail pulverfass-001\""; exec.poststop += "jib destroy bastille4";

allow.mount;
allow.mount.fdescfs;
allow.mount.devfs;
allow.mount.tmpfs;
allow.mount.nullfs;
allow.mount.procfs;
allow.mount.linsysfs;
allow.mount.linprocfs;
allow.mount.zfs;

allow.chflags;
allow.raw_sockets;
allow.socket_af;
allow.sysvipc;

linux = new;

exec.created += "/sbin/zfs jail ${name} BUNKER00/poudriere";
exec.start += "/sbin/zfs mount -a";
exec.poststop += "/sbin/zfs unjail BUNKER00/poudriere";

}
[...]

Tracking the execution of the build process by issuing

poudriere -x bulk ...

and examin the resulting trace doesn' tgive me any hint, the error reported 
above
immediately occurs when the jail is about to be started:

+ set -u +x
+ jail -c persist 'name=123-amd64-head-default' 'path=/mnt/poudriere/data/.m/ \
  123-amd64-head-default/ref' 'host.hostname=basehost.local.domain' \
  'ip4.addr=127.0.0.1' 'ip6.addr=::1' allow.chflags allow.sysvipc
jail: jail_set: Operation not permitted
+ exit_handler
[...]

Searching the net revealed some issues with setting IP4 and IP6 in poudriere, 
but those
findings are dated back to 2017 and 2014 and I guess this is solved right now.

The difference between our manually jail.conf driven setup and the 
XigmaNAS/bastille
based one is, bastille uses jib/netgraph based seutups of the vnet and the 
ip4/ip6 is
setup from rc.conf, while we use epair in the other world and the ip is setup 
from
withing the jail definition in jail.conf.

I'm out of ideas here and after two days of trial and error and trying to 
understand
what's going on lost ... Any hints or tipps?

Thanks in advance,

O. Hartmann

Re: "vidcontrol -i mode" shows no output except header (in search of smaller console font)

[Harry Schmalzbauer]

Am 28.02.2022 um 09:35 schrieb Michael Schuster:
On Mon, Feb 28, 2022 at 9:31 AM Ronald Klop > wrote:


Hi,

Where would this sysctl needed to be documented  for the OP to
find it?



There's many things to consider these days, so hard to find a single 
place I guess...
(and IMHO currently no severe issue, since these days, if defaults don't 
match perfectly, users get too big fonts instead of unreadable small fonts)




IMO vt(4) would have been a good place.


vt(4) is no consumer of the 'screen.font' loader tunable.  In case vt(4) 
uses efifb for output, resolution is unchangeable and 
vidfont(1)/kbdmap(1) refers to a different set of fonts by default as 
loader does.  Of course, there's filesystem boundaries to consider, but 
I don't know the reason why /usr/share/vt/fonts isn't simply a link to 
/boot/fonts/ - both sets are almost identical in size.


Some time ago, I proposed a generic boot/loader.conf file, which I 
created as a starting point to describe the 
BIOS/UEFI|loader|console(vt(4)\sc(4)) relations:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256343

This is only a proposal, and reflects just my own needs/confusion of the 
past, but probably help other too, getting an overview and finding the 
corresponding docs/man pages.

It is quiet large, but I felt it's necessary to also mention KMS/drm.
It's boot/loader description biased, but also contains Serial console 
and Video console specific hints.


-harry

Re: "vidcontrol -i mode" shows no output except header (in search of smaller console font)

[Michael Schuster]

On Mon, Feb 28, 2022 at 9:31 AM Ronald Klop  wrote:

> Hi,
>
> Where would this sysctl needed to be documented  for the OP to find it?
>

IMO vt(4) would have been a good place.

>
> Regards,
> Ronald
>
>
> *Van:* Toomas Soome 
> *Datum:* 28 februari 2022 08:29
> *Aan:* Michael Schuster 
> *CC:* FreeBSD CURRENT 
> *Onderwerp:* Re: "vidcontrol -i mode" shows no output except header (in
> search of smaller console font)
>
>
>
> On 28. Feb 2022, at 08:23, Michael Schuster 
> wrote:
>
> Hi Toomas,
>
>
> On Sun, Feb 27, 2022 at 10:54 PM Toomas Soome  wrote:
>
>>
>>
>> On 27. Feb 2022, at 23:36, Michael Schuster 
>> wrote:
>>
>> Hi all,
>>
>> I'm trying to get a smaller font in my text-consoles (using vt) on my
>> Ryzen 4700 and Vega10 Renoir - based laptop with a fresh install of FreeBSD
>> CURRENT from last week.
>>
>> [...]
>
>
>> UEFI or BIOS setup?
>>
>
> UEFI
>
>
>> With UEFI, sc and hw.vga.textmode has no effect. With UEFI or
>> BIOS+hw.vga.textmode=0, you can set screen.font variable (empty value will
>> cause the values list to be printed), or use loadfont command with your
>> custom font file (created with vtfontcvt).
>>
>
> I added 'screen.font="8x16"' to /boot/loader.conf, worked like a charm
> first time.
>
> Many thanks!
> Michael
>
>
> You are welcome.
>
> rgds,
> toomas
>
>
>
>
>
>

-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

Re: "vidcontrol -i mode" shows no output except header (in search of smaller console font)

[Ronald Klop]

Hi,


Where would this sysctl needed to be documented  for the OP to find it?


Regards,
Ronald




Van: Toomas Soome 
Datum: 28 februari 2022 08:29
Aan: Michael Schuster 
CC: FreeBSD CURRENT 
Onderwerp: Re: "vidcontrol -i mode" shows no output except header (in search of 
smaller console font)








On 28. Feb 2022, at 08:23, Michael Schuster  wrote:

Hi Toomas,


On Sun, Feb 27, 2022 at 10:54 PM Toomas Soome  wrote:





On 27. Feb 2022, at 23:36, Michael Schuster  wrote:

Hi all,

I'm trying to get a smaller font in my text-consoles (using vt) on my Ryzen 4700 and Vega10 Renoir - based laptop with a fresh install of FreeBSD CURRENT from last week. 



__blockquote_end__
[...] 




UEFI or BIOS setup?



UEFI
 
__blockquote_end__


UEFI
 
__blockquote_start__

 With UEFI, sc and hw.vga.textmode has no effect. With UEFI or 
BIOS+hw.vga.textmode=0, you can set screen.font variable (empty value will 
cause the values list to be printed), or use loadfont command with your custom 
font file (created with vtfontcvt).



I added 'screen.font="8x16"' to /boot/loader.conf, worked like a charm first time. 


Many thanks!
Michael


You are welcome.

rgds,
toomas