Re: FreeBSD 13.0-BETA2 Now Available

[Jason Tubnor]

On Sat, 13 Feb 2021 at 09:52, Glen Barber  wrote:

> The second BETA build of the 13.0-RELEASE release cycle is now available.
>
>
> === Upgrading ===
>
> The freebsd-update(8) utility supports binary upgrades of amd64, i386
> and aarch64 systems running earlier FreeBSD releases.  Systems running
> earlier FreeBSD releases can upgrade as follows:
>
> # freebsd-update upgrade -r 13.0-BETA2
>
> During this process, freebsd-update(8) may ask the user to help by
> merging some configuration files or by confirming that the automatically
> performed merging was done correctly.
>
> # freebsd-update install
>
> The system must be rebooted with the newly installed kernel before
> continuing.
>
> # shutdown -r now
>
> After rebooting, freebsd-update needs to be run again to install the new
> userland components:
>
> # freebsd-update install
>

If your host is only trunked to VLANs and not on a PVID, this step will not
work if you are upgrading from 11.4 or 12.2.  After reboot, ifconfig will
not be able to configure network interfaces for VLAN tagging.  It appears
to be set correctly after reboot but packets will not be tagged thus
dropped on the switch.  Once the above freebsd-update install has
completed, ifconfig will work correctly and the host will have network
access again.

Workaround:

1. Using IPMI/LOM access, login as root and issue freebsd-update install
(not desirable for non-IPMI access on a remote host)
2. Allowing sufficient time for a reboot, put a future cron job in place
that executes freebsd-update install && shutdown -r now


> It is recommended to rebuild and install all applications if possible,
> especially if upgrading from an earlier FreeBSD release, for example,
> FreeBSD 11.x.  Alternatively, the user can install misc/compat11x and
> other compatibility libraries, afterwards the system must be rebooted
> into the new userland:
>
> # shutdown -r now
>
> Finally, after rebooting, freebsd-update needs to be run again to remove
> stale files:
>
> # freebsd-update install
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: loader/boot fonts are painfully small (again)

[Walter von Entferndt]

Why not add the option to in/decrease the font size with the +/- keys to 
the boot menu?  And/or PgUP/Down or Up/Down arrow.  Last resort: 9 & 0 
are the last unused numbers in the boot menu.
-- 
=|o)  "Stell' Dir vor es geht und keiner kriegt's hin." (Wolfgang Neuss)


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg vs uname troubles after upgrade to 14 (lld not rebuilt issue? (X_)LINKER_FREEBSD_VERSION still 13 based?)

[Mark Millard via freebsd-current]

On 2021-Feb-16, at 15:37, Mark Millard  wrote:

> On 2021-Feb-16, at 11:49, Brandon Bergren  wrote:
> 
>> It looks like there were recently some fixes to release.sh, that just got 
>> backported to 13. I wonder if the problem is the packages themselves being 
>> misbuilt.
>> 
>> https://cgit.freebsd.org/src/commit/release?h=releng/13.0=4689ab1eab624d1a551a5a8f109383ea18eeba20
> 
> release/release.sh and release/tools/arm.subr are not used
> for self-building ports as far as I know. Steve Kargl's
> example was: self-built pkg, then portmaster, then used
> portmaster to build the rest of his ports, and not in/for
> an arm context. release/release.sh would have to contribute
> as a side effect of its prior use in some way for that
> sequence, if I understand right.
> 
>> 
>> On Tue, Feb 16, 2021, at 12:20 PM, Mark Millard wrote:
>>> There are other reports of a:
>>> 
>>> pkg: Warning: Major OS version upgrade detected.  Running "pkg 
>>> bootstrap -f" recommended

I think that I found something that might contribute, shown
here for my META_MODE build context . . .

Builds that do nor force being from scratch tend to:

make[1]: "/usr/fbsd/mm-src/Makefile.inc1" line 339: SYSTEM_COMPILER: Determined 
that CC=cc matches the source tree.  Not bootstrapping a cross-compiler.
make[1]: "/usr/fbsd/mm-src/Makefile.inc1" line 344: SYSTEM_LINKER: Determined 
that LD=ld matches the source tree.  Not bootstrapping a cross-linker.

But in my build environment, after upgrading to 14 and
doing multiple updates as 14 has progressed, I find:

# ld -v
LLD 11.0.1 (FreeBSD llvmorg-11.0.1-0-g43ff75f2c3fe-137) (compatible with 
GNU linkers)

Note the "137". This goes along with:

# Meta data file 
/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/toolchain-metadata.mk.meta
CMD @: > toolchain-metadata.mk
CMD @echo ".info Using cached toolchain metadata from build at $(hostname) on 
$(date)"  > toolchain-metadata.mk
CMD @echo "_LOADED_TOOLCHAIN_METADATA=t" >> toolchain-metadata.mk
CMD @echo "COMPILER_VERSION=110001" >> toolchain-metadata.mk
CMD @echo "X_COMPILER_VERSION=110001" >> toolchain-metadata.mk
CMD @echo "COMPILER_TYPE=clang" >> toolchain-metadata.mk
CMD @echo "X_COMPILER_TYPE=clang" >> toolchain-metadata.mk
CMD @echo "COMPILER_FEATURES=c++11 c++14 c++17 retpoline init-all" >> 
toolchain-metadata.mk
CMD @echo "X_COMPILER_FEATURES=c++11 c++14 c++17 retpoline init-all" >> 
toolchain-metadata.mk
CMD @echo "COMPILER_FREEBSD_VERSION=140" >> toolchain-metadata.mk
CMD @echo "X_COMPILER_FREEBSD_VERSION=140" >> toolchain-metadata.mk
CMD @echo "COMPILER_RESOURCE_DIR=/usr/lib/clang/11.0.1" >> toolchain-metadata.mk
CMD @echo "X_COMPILER_RESOURCE_DIR=/usr/lib/clang/11.0.1" >> 
toolchain-metadata.mk
CMD @echo "LINKER_VERSION=110001" >> toolchain-metadata.mk
CMD @echo "X_LINKER_VERSION=110001" >> toolchain-metadata.mk
CMD @echo "LINKER_FEATURES= build-id ifunc retpoline ifunc-noplt" >> 
toolchain-metadata.mk
CMD @echo "X_LINKER_FEATURES= build-id ifunc retpoline ifunc-noplt" >> 
toolchain-metadata.mk
CMD @echo "LINKER_TYPE=lld" >> toolchain-metadata.mk
CMD @echo "X_LINKER_TYPE=lld" >> toolchain-metadata.mk
CMD @echo "LINKER_FREEBSD_VERSION=137" >> toolchain-metadata.mk
CMD @echo "X_LINKER_FREEBSD_VERSION=137" >> toolchain-metadata.mk
CMD @echo ".export COMPILER_VERSION  COMPILER_TYPE  COMPILER_FEATURES  
COMPILER_FREEBSD_VERSION  COMPILER_RESOURCE_DIR  LINKER_VERSION  
LINKER_FEATURES  LINKER_TYPE  LINKER_FREEBSD_VERSION" >> toolchain-metadata.mk
CMD @echo ".export X_COMPILER_VERSION X_COMPILER_TYPE X_COMPILER_FEATURES 
X_COMPILER_FREEBSD_VERSION X_COMPILER_RESOURCE_DIR X_LINKER_VERSION 
X_LINKER_FEATURES X_LINKER_TYPE X_LINKER_FREEBSD_VERSION" >> 
toolchain-metadata.mk
CWD /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64
TARGET toolchain-metadata.mk
-- command output --
. . .

So (X_)COMPILER_FREEBSD_VERSION were updated to be 14 based
but (X_)LINKER_FREEBSD_VERSION still are based on 13: not
automatically updated.

I do not know what the various consequences might be but
sticking at a 13 based figure seems odd.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: "grep -rI ... /" vs. processing of /dev/ : should "--exclude-dir /dev" be required in order to avoid /dev/?

[Kyle Evans]

On Tue, Feb 16, 2021 at 7:23 PM Mark Millard via freebsd-current
 wrote:
>
> I historically on occasion have done something like:
>
> # grep -rI ... /
>
> in order to find all instances of a text, including
> in build trees and such. I now find that I need to
> do something more like (using a more specific
> example):
>
> # grep -rI --exclude-dir /dev '#define.*__FreeBSD_version'
>
> otherwise the grep ends up reading from the tty and waits
> for it. Top shows, for example,
>
> 13470 root 220  12848Ki2692Ki ttyin   11   0:00   0.00% grep 
> -rI #define.*__FreeBSD_version /
>
> Is this expected? Should I have always been using
> "--exclude-dir /dev"? What lead to the behavior
> change?
>

I can't seem to find any evidence that gnugrep in base handled this
any differently. Experimentation seems to reveal that modern gnugrep
will skip devices unless they're explicitly named for searching
(unless supplied a different --devices option), which does feel like a
good idea.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

"grep -rI ... /" vs. processing of /dev/ : should "--exclude-dir /dev" be required in order to avoid /dev/?

[Mark Millard via freebsd-current]

I historically on occasion have done something like:

# grep -rI ... /

in order to find all instances of a text, including
in build trees and such. I now find that I need to
do something more like (using a more specific
example):

# grep -rI --exclude-dir /dev '#define.*__FreeBSD_version'

otherwise the grep ends up reading from the tty and waits
for it. Top shows, for example,

13470 root 220  12848Ki2692Ki ttyin   11   0:00   0.00% grep 
-rI #define.*__FreeBSD_version /

Is this expected? Should I have always been using
"--exclude-dir /dev"? What lead to the behavior
change?

(FYI: The activity is normally as root.)

I'll note that I also got a couple of other messages
first:

grep: /dev/log: Operation not supported
grep: /dev/reroot/reroot: Operation not supported by device

I do not remember getting these in the past.

The issue happens with or without the -I part of the
grep command.


The context for the above is based on main 3acea07c1873 ,
or, in more detail,

# ~/fbsd-based-on-what-freebsd-main.sh
merge-base: 3acea07c1873b1e4042f4a4fa8668745ee59f15b
merge-base: CommitDate: 2021-02-08 19:15:21 +
c1845d00f818 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git 
context.
3acea07c1873 (pure-src) Restore the augmented strlen commentary
FreeBSD FBSDFHUGE 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n244686-c1845d00f818 
GENERIC-NODBG  amd64 amd64 144 144

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Is stand/kshim/bsd_kernel.h 's __FreeBSD_version supposed to track main's 13->14 change?

[Mark Millard via freebsd-current]

stand/kshim/bsd_kernel.h has its own define of __FreeBSD_version and
seems to have last had it changed in the main branch as shown below.
Is it as it should be for main 14? It does seem to have skipped
being updated for HEAD 12.

Last change . . .

author  Hans Petter Selasky   2020-11-18 13:22:22 
+
committer   Hans Petter Selasky   2020-11-18 
13:22:22 +
commit  a2dd1caade2f9cb829261a42812431781c685d46 (patch)
tree466a86138a99f5f6c73c54cd531dbdb9884678c0 /stand/kshim/bsd_kernel.h
parent  ac8c4a61af5007487eabf882e969dd9768549078 (diff)
downloadsrc-a2dd1caade2f9cb829261a42812431781c685d46.tar.gz
src-a2dd1caade2f9cb829261a42812431781c685d46.zip

Fix build of USB bootloader code by adding checks for _STANDALONE being defined.
Currently the USB bootloader code is not part of buildworld.

MFC after:  1 week
Sponsored by:   Mellanox Technologies // NVIDIA Networking

Notes

Notes:
svn path=/head/; revision=367787

Diffstat (limited to 'stand/kshim/bsd_kernel.h')
-rw-r--r--  stand/kshim/bsd_kernel.h7   
1 files changed, 5 insertions, 2 deletions
diff --git a/stand/kshim/bsd_kernel.h b/stand/kshim/bsd_kernel.h
index 4dfe307fef0c..89d87121c63e 100644
--- a/stand/kshim/bsd_kernel.h
+++ b/stand/kshim/bsd_kernel.h
@@ -27,9 +27,12 @@
 #ifndef _BSD_KERNEL_H_
 #define_BSD_KERNEL_H_
 
-#define_KERNEL
+#if !defined(_STANDALONE)
+#error "_STANDALONE is not defined!"
+#endif
+
 #undef __FreeBSD_version
-#define__FreeBSD_version 110
+#define__FreeBSD_version 130
 
 #include 
 #include 


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg vs uname troubles after upgrade to 14

[Mark Millard via freebsd-current]

On 2021-Feb-16, at 11:49, Brandon Bergren  wrote:

> It looks like there were recently some fixes to release.sh, that just got 
> backported to 13. I wonder if the problem is the packages themselves being 
> misbuilt.
> 
> https://cgit.freebsd.org/src/commit/release?h=releng/13.0=4689ab1eab624d1a551a5a8f109383ea18eeba20

release/release.sh and release/tools/arm.subr are not used
for self-building ports as far as I know. Steve Kargl's
example was: self-built pkg, then portmaster, then used
portmaster to build the rest of his ports, and not in/for
an arm context. release/release.sh would have to contribute
as a side effect of its prior use in some way for that
sequence, if I understand right.

> 
> On Tue, Feb 16, 2021, at 12:20 PM, Mark Millard wrote:
>> There are other reports of a:
>> 
>> pkg: Warning: Major OS version upgrade detected.  Running "pkg 
>> bootstrap -f" recommended

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: condition seqc_in_modify(_vp->v_seqc) not met at zfs_acl.c:1147 (zfs_acl_chown_setattr)

[Mateusz Guzik]

I think for future proofing it would be best if all vnodes going there
had seqc marked, thus I think this should do the trick:

diff --git a/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
b/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
index d5f0da9ecd4b..8172916c4329 100644
--- a/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
+++ b/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c
@@ -2756,7 +2756,9 @@ zfs_setattr(znode_t *zp, vattr_t *vap, int
flags, cred_t *cr)
err = zfs_acl_chown_setattr(zp);
ASSERT(err == 0);
if (attrzp) {
+   vn_seqc_write_begin(ZTOV(attrzp));
err = zfs_acl_chown_setattr(attrzp);
+   vn_seqc_write_end(ZTOV(attrzp));
ASSERT(err == 0);
}
}

I don't see other calls to the routine.

On 2/16/21, Andriy Gapon  wrote:
> On 15/02/2021 11:45, Andriy Gapon wrote:
>> On 15/02/2021 10:22, Andriy Gapon wrote:
>>>
>>> I've got this panic once when copying a couple of files.
>>> The system is stable/13 as of 1996360d7338d, a custom kernel
>>> configuration, but
>>> no local source code modifications.
>>>
>>> Unread portion of the kernel message buffer:
>>> VNASSERT failed: ({ seqc_t __seqc = (_vp->v_seqc);
>>> __builtin_expect((__seqc &
>>> 1), 0); }) not true at
>>> /usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_acl.c:1147
>>> (zfs_acl_chown_setattr)
>>> 0xf8013e4e85b8: type VDIR
>>> usecount 1, writecount 0, refcount 1 seqc users 0 mountedhere 0
>>> hold count flags ()
>>> flags ()
>>> lock type zfs: EXCL by thread 0xfe01dd1cd560 (pid 30747,
>>> kdeinit5, tid
>>> 159911)
>>> panic: condition seqc_in_modify(_vp->v_seqc) not met at
>>> /usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_acl.c:1147
>>> (zfs_acl_chown_setattr)
>>>
>>> Any ideas, suggestions, hints?
>>> Thanks!
>>>
>> ...
>>> #4  0x8036fd21 in zfs_acl_chown_setattr (zp=0xf801ccd203b0)
>>> at
>>> /usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_acl.c:1147
>>> #5  0x8037e52d in zfs_setattr (zp=0xf8024b04f760,
>>> vap=vap@entry=0xfe029a36c870, flags=flags@entry=0,
>>> cr=, cr@entry=0xf8003ecedc00)
>>> at
>>> /usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:2758
>>
>> So, this is actually the second zfs_acl_chown_setattr call here:
>> err = zfs_acl_chown_setattr(zp);
>> ASSERT(err == 0);
>> if (attrzp) {
>> err = zfs_acl_chown_setattr(attrzp);
>> ASSERT(err == 0);
>> }
>>
>> I am not sure if the assertion is actually applicable to attrzp (extended
>> attributes "directory").
>> At least I do not see any seq calls for it.
>>
>
> So, I think that the problem should be reproducible by simply chown-ing a
> file
> with an extended attribute.  The kernel should be compiled with both
> DEBUG_VFS_LOCKS and INVARIANTS.
>
> --
> Andriy Gapon
>


-- 
Mateusz Guzik 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: condition seqc_in_modify(_vp->v_seqc) not met at zfs_acl.c:1147 (zfs_acl_chown_setattr)

[Andriy Gapon]

On 15/02/2021 11:45, Andriy Gapon wrote:
> On 15/02/2021 10:22, Andriy Gapon wrote:
>>
>> I've got this panic once when copying a couple of files.
>> The system is stable/13 as of 1996360d7338d, a custom kernel configuration, 
>> but
>> no local source code modifications.
>>
>> Unread portion of the kernel message buffer:
>> VNASSERT failed: ({ seqc_t __seqc = (_vp->v_seqc); __builtin_expect((__seqc &
>> 1), 0); }) not true at
>> /usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_acl.c:1147
>> (zfs_acl_chown_setattr)
>> 0xf8013e4e85b8: type VDIR
>> usecount 1, writecount 0, refcount 1 seqc users 0 mountedhere 0
>> hold count flags ()
>> flags ()
>> lock type zfs: EXCL by thread 0xfe01dd1cd560 (pid 30747, kdeinit5, 
>> tid
>> 159911)
>> panic: condition seqc_in_modify(_vp->v_seqc) not met at
>> /usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_acl.c:1147
>> (zfs_acl_chown_setattr)
>>
>> Any ideas, suggestions, hints?
>> Thanks!
>>
> ...
>> #4  0x8036fd21 in zfs_acl_chown_setattr (zp=0xf801ccd203b0)
>> at 
>> /usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_acl.c:1147
>> #5  0x8037e52d in zfs_setattr (zp=0xf8024b04f760,
>> vap=vap@entry=0xfe029a36c870, flags=flags@entry=0,
>> cr=, cr@entry=0xf8003ecedc00)
>> at
>> /usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:2758
> 
> So, this is actually the second zfs_acl_chown_setattr call here:
> err = zfs_acl_chown_setattr(zp);
> ASSERT(err == 0);
> if (attrzp) {
> err = zfs_acl_chown_setattr(attrzp);
> ASSERT(err == 0);
> }
> 
> I am not sure if the assertion is actually applicable to attrzp (extended
> attributes "directory").
> At least I do not see any seq calls for it.
> 

So, I think that the problem should be reproducible by simply chown-ing a file
with an extended attribute.  The kernel should be compiled with both
DEBUG_VFS_LOCKS and INVARIANTS.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg vs uname troubles after upgrade to 14

[Brandon Bergren]

It looks like there were recently some fixes to release.sh, that just got 
backported to 13. I wonder if the problem is the packages themselves being 
misbuilt.

https://cgit.freebsd.org/src/commit/release?h=releng/13.0=4689ab1eab624d1a551a5a8f109383ea18eeba20


On Tue, Feb 16, 2021, at 12:20 PM, Mark Millard wrote:
> There are other reports of a:
> 
> pkg: Warning: Major OS version upgrade detected.  Running "pkg 
> bootstrap -f" recommended

-- 
  Brandon Bergren
  bdra...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg vs uname troubles after upgrade to 14

[Mark Millard via freebsd-current]

Brandon Bergren bdragon at FreeBSD.org wrote on
Tue Feb 16 17:29:45 UTC 2021 :

> On Tue, Feb 16, 2021, at 10:38 AM, Ronald Klop wrote:
> > I normally compile WITHOUT_CLEAN. What is the shortcut to recompile 
> > uname with the proper version nr and not having to recompiling clang? 
> > Cleaning and rebuilding only uname does not help.
> 
> Uh, I would drop into a buildenv with "make buildenv" and do the build there 
> to ensure it's using the toolchain from your world build.
> 
> the kernel version and the base system version are not the same thing. pkg 
> attempts to install binaries compatible with the base system.
> 
> Are you *sure* you did installworld after rebooting into the new kernel? For 
> that matter, are you *sure* you have the correct branch checked out in the 
> first place? Because it's acting as if you are on the wrong branch.

There are other reports of a:

pkg: Warning: Major OS version upgrade detected.  Running "pkg bootstrap -f" 
recommended

problem. The ones that I'm aware of are:

Xavier Humbert:
https://lists.freebsd.org/pipermail/freebsd-ports/2021-January/120144.html
https://lists.freebsd.org/pipermail/freebsd-ports/2021-February/120156.html

(It was split across the month boundary for "solved".)

Rainer Hurling:
https://lists.freebsd.org/pipermail/freebsd-ports/2021-January/120151.html

Dewayne Geraghty:
https://lists.freebsd.org/pipermail/freebsd-ports/2021-February/120154.html

Steve Kargl:
https://lists.freebsd.org/pipermail/freebsd-ports/2021-February/120298.html
https://lists.freebsd.org/pipermail/freebsd-ports/2021-February/120314.html

(The last for Steve K. is about how solved.)

But I cannot not tell if there is a common cause or a common
solution.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg vs uname troubles after upgrade to 14

[Brandon Bergren]

On Tue, Feb 16, 2021, at 10:38 AM, Ronald Klop wrote:
> I normally compile WITHOUT_CLEAN. What is the shortcut to recompile 
> uname with the proper version nr and not having to recompiling clang? 
> Cleaning and rebuilding only uname does not help.

Uh, I would drop into a buildenv with "make buildenv" and do the build there to 
ensure it's using the toolchain from your world build.

the kernel version and the base system version are not the same thing. pkg 
attempts to install binaries compatible with the base system.

Are you *sure* you did installworld after rebooting into the new kernel? For 
that matter, are you *sure* you have the correct branch checked out in the 
first place? Because it's acting as if you are on the wrong branch.


-- 
  Brandon Bergren
  bdra...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg vs uname troubles after upgrade to 14

[Ronald Klop]

libpkg/pkg_elf.c:const char *abi_files[] = {
libpkg/pkg_elf.c-getenv("ABI_FILE"),
libpkg/pkg_elf.c-_PATH_UNAME,
libpkg/pkg_elf.c-_PATH_BSHELL,
libpkg/pkg_elf.c-};

The detection first checks "/usr/bin/uname" if it exists and ABI_FILE is not 
set.
Yes the base is upgraded properly. It is a BE so if I installed wrongly I would 
not have any base.

But base is compiled by 13. So the ELF note NT_FREEBSD_ABI_TAG of the uname 
binary is 1300133.

I normally compile WITHOUT_CLEAN. What is the shortcut to recompile uname with 
the proper version nr and not having to recompiling clang? Cleaning and 
rebuilding only uname does not help.

Regards,
Ronald.


Van: Brandon Bergren 
Datum: dinsdag, 16 februari 2021 17:02
Aan: FreeBSD Current 
Onderwerp: Re: pkg vs uname troubles after upgrade to 14


IIRC, the detection works by probing /bin/sh, make sure you upgraded your base 
properly.

On Tue, Feb 16, 2021, at 9:55 AM, Ronald Klop wrote:
> Hi,
>
> Upgraded from 13 to 14.
>
> # uname -UK
> 143 143
>
> But elfdump on uname gives:
> note (.note.tag):
> FreeBSD 1300133 (NT_FREEBSD_ABI_TAG)
>
>
> # pkg -o OSVERSION=143 upgrade
> pkg: Warning: Major OS version upgrade detected.  Running "pkg
> bootstrap -f" recommended
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up to date.
> All repositories are up to date.
> Updating database digests format: 100%
> Checking for upgrades (1 candidates): 100%
> Processing candidates (1 candidates): 100%
> Checking integrity... done (0 conflicting)
> The following 1 package(s) will be affected (of 0 checked):
>
> Installed packages to be REINSTALLED:
> pkg-1.16.2 (ABI changed: 'freebsd:14:aarch64:64' -> 
'freebsd:13:aarch64:64')
>
> Number of packages to be reinstalled: 1
>
>
> How do I do this properly? Rebuilding name still gives it the ELF note
> of 1300133.
> It does not matter if I pass "-o OSVERSION=143" to pkg or not.
> Found https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104, but I
> don't think it was really resolved.
>
> This is on aarch64. And why does pkg not use the version uname is
> reporting by -UK instead of the ELF note?
>
> Regards,
> Ronald.
>
>  
> ___

> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>

--
  Brandon Bergren
  bdra...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"




___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg vs uname troubles after upgrade to 14

[Brandon Bergren]

IIRC, the detection works by probing /bin/sh, make sure you upgraded your base 
properly.

On Tue, Feb 16, 2021, at 9:55 AM, Ronald Klop wrote:
> Hi,
> 
> Upgraded from 13 to 14.
> 
> # uname -UK
> 143 143
> 
> But elfdump on uname gives:
> note (.note.tag):
> FreeBSD 1300133 (NT_FREEBSD_ABI_TAG)
> 
> 
> # pkg -o OSVERSION=143 upgrade
> pkg: Warning: Major OS version upgrade detected.  Running "pkg 
> bootstrap -f" recommended
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up to date.
> All repositories are up to date.
> Updating database digests format: 100%
> Checking for upgrades (1 candidates): 100%
> Processing candidates (1 candidates): 100%
> Checking integrity... done (0 conflicting)
> The following 1 package(s) will be affected (of 0 checked):
> 
> Installed packages to be REINSTALLED:
> pkg-1.16.2 (ABI changed: 'freebsd:14:aarch64:64' -> 
> 'freebsd:13:aarch64:64')
> 
> Number of packages to be reinstalled: 1
> 
> 
> How do I do this properly? Rebuilding name still gives it the ELF note 
> of 1300133.
> It does not matter if I pass "-o OSVERSION=143" to pkg or not.
> Found https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104, but I 
> don't think it was really resolved.
> 
> This is on aarch64. And why does pkg not use the version uname is 
> reporting by -UK instead of the ELF note?
> 
> Regards,
> Ronald.
> 
>  
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>

-- 
  Brandon Bergren
  bdra...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

pkg vs uname troubles after upgrade to 14

[Ronald Klop]

Hi,

Upgraded from 13 to 14.

# uname -UK
143 143

But elfdump on uname gives:
note (.note.tag):
   FreeBSD 1300133 (NT_FREEBSD_ABI_TAG)


# pkg -o OSVERSION=143 upgrade
pkg: Warning: Major OS version upgrade detected.  Running "pkg bootstrap -f" 
recommended
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Updating database digests format: 100%
Checking for upgrades (1 candidates): 100%
Processing candidates (1 candidates): 100%
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be REINSTALLED:
   pkg-1.16.2 (ABI changed: 'freebsd:14:aarch64:64' -> 'freebsd:13:aarch64:64')

Number of packages to be reinstalled: 1


How do I do this properly? Rebuilding name still gives it the ELF note of 
1300133.
It does not matter if I pass "-o OSVERSION=143" to pkg or not.
Found https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104, but I don't 
think it was really resolved.

This is on aarch64. And why does pkg not use the version uname is reporting by 
-UK instead of the ELF note?

Regards,
Ronald.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Interface counter inaccurate

[Daniel Ponte]

On Tue, Feb 16, 2021 at 10:39:28AM +0100, Kristof Provost wrote:
[...]
> Even stranger, in that you appear to only have the issue on one of your igb0
> interfaces.
> My initial guess was that there was a driver bug causing it to double count
> the packets.
> 
> That machine has 4 ethernet ports, does it have 4 igbX interfaces as well?
> Are there any vlans configured? (My current thinking is still that it’s a
> driver issue, manifesting only on one of the interfaces because of a
> configuration difference.)
> 
> It may also be useful to try capturing packets on igb0 and correlating the
> number of captured packets with the counters.
> 
> I’m not all that familiar with the igb driver code, so I don’t know if I’ll
> be able to help much.
> 
> Best regards,
> Kristof

It indeed has 4x igb interfaces.

I have been able to further correlate this. The issue is with incoming
packet counters on either interface. When the flow reverses (upload
speedtest vs download speedtest), the inside interface's ingress counter
starts counting double instead.

There is a single, seldom-used vlan, but it is only on the inside
interface. Destroying it made no difference.

Dan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: New Optane AIC does not show up in FreeBSD until . . . ?

[Mark Millard via freebsd-current]

On 2021-Feb-16, at 02:22, Harry Schmalzbauer  wrote:

> Am 16.02.2021 um 11:08 schrieb Mark Millard:
>> On 2021-Feb-16, at 00:48, Harry Schmalzbauer  wrote:
>>> Am 14.02.2021 um 02:36 schrieb Mark Millard via freebsd-current:
 On 2021-Feb-13, at 16:40, Warner Losh  wrote:
 
> Are you aware of gpart create?
> 
> Warner
 From which I derive that I had an implicit, incorrect
 assumption that gpart show would in some way list
 everything available that gpart could manipulate
 (including for use in creation).
>>> 
>>> 'geom disk status' is my first choice for such a case.
>>> Even nvd(4) should show up I think, nda(4) just changes the access path, 
>>> not geom(8) integration, afaik.
> 
> ...
>> Thanks for the alternatives to sysctl kern.disks
>> and to nvmecontrol devlist for making a list to
>> compare to gpart show output in order to find
>> what gpart show does not list (but can manipulate).
> 
> gpart(8) doesn't enumerate disks without any supported partition scheme 
> present.
> You can create new partition schemes with the help of gpart(8), but it's imho 
> correct not to show them, because 'gpart show' is meant to give information 
> about (existing) partition schemes - no scheme no info; thus your vanilla 
> disk is "unknown" to gpart(8).
> 
> I remember that I always thought the geom(8) disk class is kind of hidden - 
> especially since the man page misses listing DISK in the
> "Currently available classes which are aware of geom(8)" section!
> 
> The "show" command was enriched to contain valuable details, such as NAA.
> So 'geom disk' turned into one of the most useful mass storage admin 
> commands. imho.
> Maybe somebody should correct the aforementioned man page section and add add 
> any hint in the SEE ALSO section, because there is no gdisk(8) aequivalent, 
> like for all other geom classes...
> 
> -harry
> 
> P.S. Put it on my loger-term todo to file a bug report with a proposed man 
> page diff...

Looks like "geom -t" output avoids me having to compare
two outputs to find mismatches in the list of names: its
output is sufficient to identify the name(s) for drives
that do not have the scheme information (and the names
of those that do). This at least helps cut down what I
have to coordinate, especially when only one device is
in question.

For example, ada2 in the below has only DISK and one DEV
line, not multiple DEV's, no PART line, nor other such:

. . .
ada0   DISK   ada0
  ada0 PART   ada0s1
ada0s1 DEV   
  ada0 PART   ada0s2
ada0s2 DEV   
  ada0 DEV   
ada1   DISK   ada1
  ada1 PART   ada1p1
ada1p1 DEV   
  ada1 DEV   
ada2   DISK   ada2
  ada2 DEV   
da0DISK   da0
  da0  PART   da0p1
da0p1  DEV   
  da0  PART   da0p2
da0p2  LABEL  ntfs/VirtMachs
  ntfs/VirtMachs   DEV   
da0p2  DEV   
  da0  DEV   
. . .

So I can infer that I need a gpart create on ada2 .
(Presumes I know from the naming that the device
is not analogous to a cd-drive with no media in
the drive.) The output does span the nvd* devices.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: New Optane AIC does not show up in FreeBSD until . . . ?

[Harry Schmalzbauer]

Am 16.02.2021 um 11:08 schrieb Mark Millard:

On 2021-Feb-16, at 00:48, Harry Schmalzbauer  wrote:


Am 14.02.2021 um 02:36 schrieb Mark Millard via freebsd-current:

On 2021-Feb-13, at 16:40, Warner Losh  wrote:


Are you aware of gpart create?

Warner

 From which I derive that I had an implicit, incorrect
assumption that gpart show would in some way list
everything available that gpart could manipulate
(including for use in creation).


'geom disk status' is my first choice for such a case.
Even nvd(4) should show up I think, nda(4) just changes the access path, not 
geom(8) integration, afaik.


...

Thanks for the alternatives to sysctl kern.disks
and to nvmecontrol devlist for making a list to
compare to gpart show output in order to find
what gpart show does not list (but can manipulate).


gpart(8) doesn't enumerate disks without any supported partition scheme 
present.
You can create new partition schemes with the help of gpart(8), but it's 
imho correct not to show them, because 'gpart show' is meant to give 
information about (existing) partition schemes - no scheme no info; thus 
your vanilla disk is "unknown" to gpart(8).


I remember that I always thought the geom(8) disk class is kind of 
hidden - especially since the man page misses listing DISK in the

"Currently available classes which are aware of geom(8)" section!

The "show" command was enriched to contain valuable details, such as NAA.
So 'geom disk' turned into one of the most useful mass storage admin 
commands. imho.
Maybe somebody should correct the aforementioned man page section and 
add add any hint in the SEE ALSO section, because there is no gdisk(8) 
aequivalent, like for all other geom classes...


-harry

P.S. Put it on my loger-term todo to file a bug report with a proposed 
man page diff...

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

make installworld crashes the system in g_slice_access geom_slice.c:127

[Ali Abdallah via freebsd-current]

Hello,

While upgrading from source my 13-CURRENT box from ALPHA1 to BETA1, I
got the following crash on make installworld.

Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x30
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x8034d5b0
stack pointer   = 0x28:0xfe00c8204600
frame pointer   = 0x28:0xfe00c8204640
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled,
resume, IOPL = 0
current process = 65294 (fsck_ufs)
trap number = 12
panic: page fault
cpuid = 1
time = 1613467739

#16 0x8034d5b0 in g_slice_access (pp=0xf80003ca5100, dr=1,
dw=0, de=0) at /usr/src/sys/geom/geom_slice.c:127
#17 0x8034e6e4 in g_access (cp=0xf80003c82e00,
dcr=, dcr@entry=1, dcw=, dcw@entry=0,
dce=dce@entry=0) at /usr/src/sys/geom/geom_subr.c:1042
#18 0x8034698f in g_dev_open (dev=,
flags=, fmt=, td=) at
/usr/src/sys/geom/geom_dev.c:442
#19 0x80342e46 in devfs_open (ap=0xfe00c82047a0) at
/usr/src/sys/fs/devfs/devfs_vnops.c:1290
#20 0x806bb05c in VOP_OPEN_APV (vop=0x80863e20
, a=a@entry=0xfe00c82047a0) at vnode_if.c:436
#21 0x804bef1e in VOP_OPEN (vp=0xf80003cdc000, mode=1,
cred=0xf800029d4420, td=0x0, fp=0xf802a7208140) at
./vnode_if.h:220
#22 vn_open_vnode (vp=vp@entry=0xf80003cdc000, fmode=fmode@entry=1,
cred=, cred@entry=0xf80002993700, td=,
td@entry=0xfe00c8149300, fp=) at
/usr/src/sys/kern/vfs_vnops.c:411
#23 0x804bead0 in vn_open_cred
(ndp=ndp@entry=0xfe00c8204970, flagp=,
flagp@entry=0xfe00c8204a94, cmode=,
vn_open_flags=vn_open_flags@entry=0, cred=, fp=0x7) at
/usr/src/sys/kern/vfs_vnops.c:318
#24 0x804be6ad in vn_open (ndp=0xf80003ca5100,
ndp@entry=0xfe00c8204970, flagp=0xf800029d43c0,
flagp@entry=0xfe00c8204a94, cmode=0, fp=0xf800029d4420) at
/usr/src/sys/kern/vfs_vnops.c:193
#25 0x804b4983 in kern_openat (td=0xfe00c8149300,
fd=, path=, pathseg=,
flags=1, mode=) at /usr/src/sys/kern/vfs_syscalls.c:1143
#26 0x8068ea5c in syscallenter (td=0xfe00c8149300) at
/usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189

(kgdb) frame 16
#16 0x8034d5b0 in g_slice_access (pp=0xf80003ca5100, dr=1,
dw=0, de=0) at /usr/src/sys/geom/geom_slice.c:127
127 if ((pp->acw + dw) > 0 && pp2->ace > 0)

(kgdb) p pp2
$2 = (struct g_provider *) 0x0

pp2 is null, and pp2->ace crashes the system.

Does the above crash pattern rings any bell? My system uses UFS SU+trim on GELI.

On reboot, I had to manually run fsck. At the end I did reinstall
successfully world from my poudriere server through NFS, since I wasn't
sure about the state of the files in /usr/obj...

Regards,

Ali

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: New Optane AIC does not show up in FreeBSD until . . . ?

[Mark Millard via freebsd-current]

On 2021-Feb-16, at 00:48, Harry Schmalzbauer  wrote:

> Am 14.02.2021 um 02:36 schrieb Mark Millard via freebsd-current:
>> On 2021-Feb-13, at 16:40, Warner Losh  wrote:
>> 
>>> Are you aware of gpart create?
>>> 
>>> Warner
>> From which I derive that I had an implicit, incorrect
>> assumption that gpart show would in some way list
>> everything available that gpart could manipulate
>> (including for use in creation).
> 
> 'geom disk status' is my first choice for such a case.
> Even nvd(4) should show up I think, nda(4) just changes the access path, not 
> geom(8) integration, afaik.

Looks like "geom disk status" and "geom disk list"
both list "disks" that do not have a partition scheme
and spans the nvd* disks. (I only tested destroying a
partition scheme on an ada* and then seeing what
was displayed. I do not want to destroy such on any
nvd* as stands.)

"geom disk list" shows Mediasize and descr, which
at times could be handy for identification, at
least when the pair are unique in the system.

Thanks for the alternatives to sysctl kern.disks
and to nvmecontrol devlist for making a list to
compare to gpart show output in order to find
what gpart show does not list (but can manipulate).


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Interface counter inaccurate

[Kristof Provost]

On 16 Feb 2021, at 0:58, Daniel Ponte wrote:

On Mon, Feb 15, 2021 at 10:25:47PM +0100, Kristof Provost wrote:

On 15 Feb 2021, at 22:09, Daniel Ponte wrote:
I've noticed that since upgrading to stable/13-n244514-18097ee2fb7c 
from

12.2-STABLE, throughput on my WAN interface (the box runs pf) is
incorrectly showing double in systat -if, as well as in vnstat and 
pftop

from ports. The LAN interface does not appear to be so afflicted.

`systat -if` doesn’t read the pf counters, so I wouldn’t expect 
that to be

related.

Those are the interface counters.
What network card and driver do you use?

Kristof


I, too, questioned the relation. They are igb(4) I210 builtin 
interfaces

(in a Protectli Vault 4).


systat -if during said speed test:

   igb1  in 11.670 Mb/s 11.670 Mb/s
1.067 GB
 out   319.975 Mb/s320.458 Mb/s
2.062 GB


   igb0  in640.120 Mb/s640.690 Mb/s
6.351 GB
 out 5.824 Mb/s  5.824 Mb/s  
987.050 MB


igb1 is inside, igb0 is outside. The 6GB:2GB difference in totals seen 
above
is indeed real; this machine did not initiate that much traffic on its 
own.


Even stranger, in that you appear to only have the issue on one of your 
igb0 interfaces.
My initial guess was that there was a driver bug causing it to double 
count the packets.


That machine has 4 ethernet ports, does it have 4 igbX interfaces as 
well? Are there any vlans configured? (My current thinking is still that 
it’s a driver issue, manifesting only on one of the interfaces because 
of a configuration difference.)


It may also be useful to try capturing packets on igb0 and correlating 
the number of captured packets with the counters.


I’m not all that familiar with the igb driver code, so I don’t know 
if I’ll be able to help much.


Best regards,
Kristof
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

freebsd-update(8) without an echo of "You must be root to run this."

[Graham Perrin]

        echo "You must be root to run this."

Below: is this my PEBKAM, or (with a system that is preconfigured to 
deny login as root) _should_ there be an echo of the requirement to run 
as root?




mowa219-gjp4-vm-hellosystem-eol-freebsd% su -
Password:
su: Sorry
mowa219-gjp4-vm-hellosystem-eol-freebsd% sudo grep LOCKED 
/etc/master.passwd

root:*LOCKED*:0:0::0:0:Charlie &:/root:/bin/csh
mowa219-gjp4-vm-hellosystem-eol-freebsd% sudo freebsd-update upgrade -r 
13.0-BETA2

src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 12.1-RELEASE from update4.freebsd.org... 
done.

Fetching metadata index... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic world/base world/doc

The following components of FreeBSD do not seem to be installed:
kernel/generic-dbg world/base-dbg world/lib32 world/lib32-dbg

Does this look reasonable (y/n)?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: New Optane AIC does not show up in FreeBSD until . . . ?

[Harry Schmalzbauer]

Am 14.02.2021 um 02:36 schrieb Mark Millard via freebsd-current:

On 2021-Feb-13, at 16:40, Warner Losh  wrote:


Are you aware of gpart create?

Warner

 From which I derive that I had an implicit, incorrect
assumption that gpart show would in some way list
everything available that gpart could manipulate
(including for use in creation).


'geom disk status' is my first choice for such a case.
Even nvd(4) should show up I think, nda(4) just changes the access path, 
not geom(8) integration, afaik.


-harry


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: loader/boot fonts are painfully small (again)

[Harry Schmalzbauer]

Am 15.02.2021 um 16:55 schrieb Daniel Nebdal:

On Fri, 12 Feb 2021 at 15:33, Rodney W. Grimes <
freebsd-...@gndrsh.dnsmgr.net> wrote:




On 11. Feb 2021, at 23:21, Yuri Pankov  wrote:

Lenovo P51 laptop, 15'' 4k (3840x2160) display.

Booting from the latest available current snapshot (20210107), fonts
were at least readable; updating to the latest bits (manually

installing

new loader as well) made them really small -- terminal size reported by
stty is 480x135.


It is a issue about not so good automatic font size setup. The original

code was using 80x24 terminal as base, it was complained it did end up with
too large fonts, so I did pick uefi terminal size as base (see output from
mode command), but thats also not perfect. Till better solution, right now
the option is to set font manually (screen.font variable).

Can we just stick with the "known to work almost everywhere and always"
default value of 80x24?  These small fonts are great for those of you
who have 20/20 un corrected vision, but it is a royal PITA for almost
anyone who has even a slight visual imparement, even corrected I find
it near imposible to read the default efi screens we put up.

I would suggest we also override this in the -RELEASE/SNAPSHOT
media as one just does not need to fight this font size issue
while trying to install a new system.

Thanks,
Rod

I have also noticed large delays between different loader screens,
probably caused by very slow screen blanking given the terminal size?

yes, it definitely needs boost.There are few things we can do about it.

rgds,
toomas



If we assume that 16:9 screens are the most common aspect ratio, and that
the font we use is 1:2 (which is just guesswork, based on the 8x16 console
font), that gives us a 32:9 aspect ratio counted in characters.

It seems sensible to stick to an integer multiple of that, to avoid any
uncomfortable stretching or scaling. The 480x135 console you got follows
that idea - it's the 15x scale. That's obviously a bit optimistic, but how
about the 3x or 4x scale, at 96x27 or 128x36?


128x36, resp. 100x37 (previous 800x600 native) is the very lowest 
geometry numbers (biggest font result) we should consider reasonlable.
80x25 is evil pain having to read logs in emergency situations on any 
contemporary (commodity, server-console connected) display.
As long as nobody can prove she's connecting CRTs smaller than 14" and a 
maximum resolution of 640x480 to real-world setups, there's no use for 
80x25.
Post 20210107 fonts were way oo big on all my real world server setups, 
no matter if it's iLO/bmc KVM, or any first-to-find LCD.
Greatest surprise was on an 30" 2560x1600, where the UEFI/GOP limit of 
1920x1200 led to fonts with a size of fingernails - readable almost from 
the other building 20 meters away...

This is completely unusable too.
Obviously, Laptops fight the other direction.

I haven't tested how the new selection model works out...
And I don't have Laptop beyond 211dpi, but previous selection model 
showed too big fonts on that Laptop too (usable, but slightly too big, 
even for my very weak eyes [not without glasses anymore...])
Just wanted to note that we mustn't forget to take server consoles into 
account - it's all arround 100dpi at max. usually, and spliting single 
syslog line around the whole screen is real pain!


Thanks,
-harry
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"