Re: testers needed: loader: use display pixel density for font autoselection

2021-02-25 Thread Toomas Soome via freebsd-current 


> On 26. Feb 2021, at 05:42, Rodney W. Grimes  wrote:
> 
>>> On 23. Feb 2021, at 17:53, Jakob Alvermark  wrote:
>>> 
>>> On 2/23/21 12:27 PM, Toomas Soome via freebsd-current wrote:
 hi!
 
 I have done some work to make font pickup a bit smarter (hopefully 
 better;), but my own ability to test is limited to one bugged supermicro 
 and one MBP with retina display?
 
 The phab link ishttps://reviews.freebsd.org/D28849  
 
 
 I have built loader binaries as well (bios and uefi):
 loader_lua
 loader_lua.efi
 
 To test, you should remove screen.font= line from loader.conf and test 
 with different resolutions.
 
 thanks,
 toomas
>>> 
>>> 
>>> 
>>> Hi Toomas,
>>> 
>>> 
>>> I tested on five different setups.
>>> 
>>> Surface Pro 10.6"@1920x1080:
>>> 
>>> The loader menu looks different, the "FreeBSD" text is on the right side of 
>>> the screen.
>> 
>> 
>> I think, this was the lua script bug we did fix not too long time ago.
>> 
>>> 
>>> Otherwise, the font size is what I would call a normal size.
>>> 
>>> 
>>> Acer laptop 11.6"@1366x768:
>>> 
>>> Menu looks fine. Almost fills the entire screen.
>>> 
>>> The font feels a little too big.
>> 
>> 
>> The laptop built in displays usually do not give out EDID (we get physical 
>> dimensions from EDID), so there we fall back to try to get 80x25 terminal 
>> method.
> 
> I am having a hard time with that statement.  EDID is very common on laptop 
> screens, infact I can not recall ever not seeing EDID on a laptops builtin 
> screen.
> My 11" acer 1400 has EDID in it.
> 
> 


If there is EDID, then it is all good. I have seen cases we do not get it with 
available API.


>>> 
>>> Thinkpad built in 13"@1920x1080:
>>> 
>>> Menu looks fine, but a little slow.
>>> 
>>> The font size is a little to big for my liking. When drm loads and mirrors 
>>> the screen to my external 27" it looks comically large.
>>> 
>> 
>> There is another issue - once DRM will kick in, we should re-consider the 
>> console attributes, like fonts, but at this time, the kernel itself only can 
>> use what was built in (8x16), or what loader was offering (default if 
>> present). So it is up to user to act there.
> 
> It would be really nice if DRM could pick up what the resolution and font was 
> when it loaded!

it should do more, my supermicro X10SAE is ony doing 800x600 with UEFI, it has 
dell 27” 4k monitor connected. VBE can get 1600x1200 from the same set. What I 
would like to see is, once KMS is attached (i915), I’d like to get bets 
possible resolution and appropriate font. But thats something for future work.

> 
>> 
>>> 
>>> Thinkpad external 24"@1920x1200:
>>> 
>>> Menu looks OK, uses about a quarter of the screen.
>>> 
>>> Font size is fine, but once drm loads it looks a bit squeezed (like thin 
>>> and tall), but I guess that's drm detecting the built in 1920x1080, and the 
>>> external display is stretched.
>>> 
>>> 
>>> Thinkpad external 27"@3840x2160:
>>> 
>>> Menu looks OK, uses about a quarter of the screen.
>>> 
>>> Font size is fine.
>>> 
>>> Looking at the dmesg though, it says: VT(efifb): resolution 1920x1080
>>> 
>>> 
>>> Jakob
>>> 
>> 
>> 
>> Those cases .. I suppose the menu was still at left side, not in middle? The 
>> thing there is, our menu is designed for 80x25 screen, with respective 
>> constants. 
> 
> SO again... why are we deviating from that causing us issues?


You have misunderstood - the current menu code *is* built for 80x25 - the menu 
frame size is fixed, logo/brand locations are constants and so on.


> 
>> 
>> many thanks for testing,
> 
> I have downloaded your modified loader, and put it in place, it shall get 
> tested on my next reboot, which should be soon as 13-BETA4 should be popping 
> out soon.
> 

thank you!

rgds,
toomas

___
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: testers needed: loader: use display pixel density for font autoselection

2021-02-25 Thread Rodney W. Grimes 
> > On 23. Feb 2021, at 17:53, Jakob Alvermark  wrote:
> > 
> > On 2/23/21 12:27 PM, Toomas Soome via freebsd-current wrote:
> >> hi!
> >> 
> >> I have done some work to make font pickup a bit smarter (hopefully 
> >> better;), but my own ability to test is limited to one bugged supermicro 
> >> and one MBP with retina display?
> >> 
> >> The phab link ishttps://reviews.freebsd.org/D28849  
> >> 
> >> 
> >> I have built loader binaries as well (bios and uefi):
> >> loader_lua
> >> loader_lua.efi
> >> 
> >> To test, you should remove screen.font= line from loader.conf and test 
> >> with different resolutions.
> >> 
> >> thanks,
> >> toomas
> > 
> > 
> > 
> > Hi Toomas,
> > 
> > 
> > I tested on five different setups.
> > 
> > Surface Pro 10.6"@1920x1080:
> > 
> > The loader menu looks different, the "FreeBSD" text is on the right side of 
> > the screen.
> 
> 
> I think, this was the lua script bug we did fix not too long time ago.
> 
> > 
> > Otherwise, the font size is what I would call a normal size.
> > 
> > 
> > Acer laptop 11.6"@1366x768:
> > 
> > Menu looks fine. Almost fills the entire screen.
> > 
> > The font feels a little too big.
> 
> 
> The laptop built in displays usually do not give out EDID (we get physical 
> dimensions from EDID), so there we fall back to try to get 80x25 terminal 
> method.

I am having a hard time with that statement.  EDID is very common on laptop 
screens, infact I can not recall ever not seeing EDID on a laptops builtin 
screen.
My 11" acer 1400 has EDID in it.


> > 
> > Thinkpad built in 13"@1920x1080:
> > 
> > Menu looks fine, but a little slow.
> > 
> > The font size is a little to big for my liking. When drm loads and mirrors 
> > the screen to my external 27" it looks comically large.
> > 
> 
> There is another issue - once DRM will kick in, we should re-consider the 
> console attributes, like fonts, but at this time, the kernel itself only can 
> use what was built in (8x16), or what loader was offering (default if 
> present). So it is up to user to act there.

It would be really nice if DRM could pick up what the resolution and font was 
when it loaded!

> 
> > 
> > Thinkpad external 24"@1920x1200:
> > 
> > Menu looks OK, uses about a quarter of the screen.
> > 
> > Font size is fine, but once drm loads it looks a bit squeezed (like thin 
> > and tall), but I guess that's drm detecting the built in 1920x1080, and the 
> > external display is stretched.
> > 
> > 
> > Thinkpad external 27"@3840x2160:
> > 
> > Menu looks OK, uses about a quarter of the screen.
> > 
> > Font size is fine.
> > 
> > Looking at the dmesg though, it says: VT(efifb): resolution 1920x1080
> > 
> > 
> > Jakob
> > 
> 
> 
> Those cases .. I suppose the menu was still at left side, not in middle? The 
> thing there is, our menu is designed for 80x25 screen, with respective 
> constants. 

SO again... why are we deviating from that causing us issues?

> 
> many thanks for testing,

I have downloaded your modified loader, and put it in place, it shall get 
tested on my next reboot, which should be soon as 13-BETA4 should be popping 
out soon.

> toomas
> 
> 
> 

-- 
Rod Grimes rgri...@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"

KTLS with zfs recv

2021-02-25 Thread Alan Somers 
My understanding is that KTLS works very well with OpenSSL for sending, but
not as well for receiving, because there's nothing like a recvfile
syscall.  However, it works great for both send and receive with NFS, where
all the data remains in the kernel. What about zfs recv?  A very common
pattern is for an application to read from an SSL socket and then pipe the
data to zfs recv. For example, zrepl does that.  Could zfs recv instead
read directly from the KTLS socket, bypassing userspace?  That could
potentially save a _lot_ of cycles for a _lot_ of people.

-Alan
___
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: HEADS-UP: PIE enabled by default on main

2021-02-25 Thread Greg 'groggy' Lehey 
On Thursday, 25 February 2021 at 21:22:43 -0500, Ed Maste wrote:
> On Thu, 25 Feb 2021 at 19:23, John Kennedy  wrote:
>>
>>   Not sure if Ed Maste just wants to make sure that all the executables
>> are rebuilt as PIE (vs hit-and-miss) or there is a sneaker corner-case that
>> he knows about.
>
> The issue is that without a clean build you may have some .o files
> left around that are built without PIE enabled (i.e., compiled without
> -fPIE), and attempting to link them into a PIE executable will fail
> with an error like:
>
> ld: error: can't create dynamic relocation R_X86_64_32 against local symbol 
> in readonly segment; recompile object files with -fPIC or pass 
> '-Wl,-z,notext' to allow text relocations in the output

Ah, thanks.  That makes more sense.

Greg
--
Sent from my desktop computer.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA


signature.asc
Description: PGP signature

Re: HEADS-UP: PIE enabled by default on main

2021-02-25 Thread Ed Maste 
On Thu, 25 Feb 2021 at 19:23, John Kennedy  wrote:
>
>   Not sure if Ed Maste just wants to make sure that all the executables
> are rebuilt as PIE (vs hit-and-miss) or there is a sneaker corner-case that
> he knows about.

The issue is that without a clean build you may have some .o files
left around that are built without PIE enabled (i.e., compiled without
-fPIE), and attempting to link them into a PIE executable will fail
with an error like:

ld: error: can't create dynamic relocation R_X86_64_32 against local
symbol in readonly segment; recompile object files with -fPIC or pass
'-Wl,-z,notext' to allow text relocations in the output

I am not aware of any configuration that would link successfully, but
then have some run-time failure. If it builds it should work.
___
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: HEADS-UP: PIE enabled by default on main

2021-02-25 Thread Ed Maste 
On Thu, 25 Feb 2021 at 18:10, Greg 'groggy' Lehey  wrote:
>
> This details worries me.  How compatible are PIE executables with
> non-PIE executables?  Can I run PIE executables on older systems?  Can
> I run older executables on a PIE system?

There is no issue mixing PIE and non-PIE binaries, and they introduce
no additional constraints on running on older kernels.
___
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: HEADS-UP: PIE enabled by default on main

2021-02-25 Thread John Kennedy 
On Fri, Feb 26, 2021 at 10:10:28AM +1100, Greg 'groggy' Lehey wrote:
> On Thursday, 25 February 2021 at 15:58:07 -0500, Ed Maste wrote:
> > As of 9a227a2fd642 (main-n245052) base system binaries are now built
> > as position-independent executable (PIE) by default, for 64-bit
> > architectures. ...
> >
> > If you track -CURRENT and normally build WITHOUT_CLEAN you'll need to
> > do one initial clean build -- either run `make cleanworld` or set
> > WITH_CLEAN=yes.
> 
> This details worries me.  How compatible are PIE executables with
> non-PIE executables?  Can I run PIE executables on older systems?  Can
> I run older executables on a PIE system?

  Assuming we're basically talking about WITH_PIE=YES in /etc/src.conf, I've 
been doing this since 2020/08/04 (12.1 -> 12.2 -> 13/14).  I don't think
I've associated any problems with PIE.  I've certainly got lots of non-PIE
ports linked against base libraries (but ELF 64-bit LSB shared object, vs
ELF 64-bit LSB pie executable).  The E in PIE is executable.

  Not sure if Ed Maste just wants to make sure that all the executables
are rebuilt as PIE (vs hit-and-miss) or there is a sneaker corner-case that
he knows about.

  I can't say that I've had an opportunity to try the scenario I think you're
looking at.  My "older" crossovers are +/- a __FreeBSD_version bump.

___
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: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?

2021-02-25 Thread John Baldwin 

On 2/11/21 9:59 AM, Hartmann, O. wrote:

On Wed, 10 Feb 2021 07:21:20 +0100
"Hartmann, O."  wrote:


On Tue, 9 Feb 2021 15:15:38 -0800
John Baldwin  wrote:


On 2/9/21 2:16 PM, Hartmann, O. wrote:

On Wed, 3 Feb 2021 17:34:24 +0100
Guido Falsi via freebsd-current  wrote:
 

On 03/02/21 17:02, John Baldwin wrote:

On 2/2/21 10:16 PM, Hartmann, O. wrote:

On Mon, 1 Feb 2021 03:24:45 +
Rick Macklem  wrote:
   

Rick Macklem wrote:

Guido Falsi wrote:
[good stuff snipped]

Performed a full bisect. Tracked it down to commit aa906e2a4957,
adding
KTLS support to embedded OpenSSL.

I filed a bug report about this:

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


Apart from switching to svn:// scheme, another workaround is to build
base using WITHOUT_OPENSSL_KTLS.

Just fyi, when I tested the daemons I have for nfs-over-tls (which
use ktls),
they acted like things were ok (no handshake problems), but the data
ended up on the wire unencrypted (nfs-over-tls doesn't do a
SSL_write(),
so it depends on ktls to do the encryption).

Since these daemons work fine with openssl3 in
ports/security/openssl-devel,
I suspect the ktls backport is not quite right. I've sent jhb@ email.

I was wrong on the above. I did a full buildworld/installworld and
the daemons
now seem to work with the openssl in head/main.

Btw, did anyone try rebuilding svn from sources after doing
the system upgrade?
(The openssl library calls and .h files definitely changed.)


Yes, I did, on all boxes and its a pain in the a..., we had to rebuild
EVERY port (at
least, I did, to avoid further problem). Yesterday, on of our fastes
boxes got ready and
even with a full rebuild of the system AND a full rebuild of the ports
(no poudriere,
traditional way via make), the Apache 2.4 webservice doesn't work, and
so does subversion
not (Firefox reports problems with SSL handshake, subversion is
stuck/frozen forever).
I will run today another full world build today, hopefully finishing
on friday (portmaster
-dfR doesn't get everything in line on some ports, I assume).

oh


I tracked the subversion hang down to a bug in serf (an Apache library
used by
subversion).  It would also affect any other software using serf.  The
serf in
ports will also have to be patched.



I submitted your patch as a bug report to the serf port:

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



What is the status of this bug?
As PR 253214 might suggest, the patch to www/serf has been commited. We still 
face a
problem with FreeBSD CURRENT-14 based systems running Apache24:

FreeBSD 14.0-CURRENT #4 main-n244672-866c8b8d5dd: Mon Feb  8 08:38:59 CET 2021 
amd64

/usr/ports is at Revision: 564736.

www/apache24, www/serf have been rebuilt using "portmaster -f www/apache24
www/serf".

Restarting Apache 2.4 still fails on any access with SSL enabled, firefox 
reports:

SSL_ERROR_HANDSHAKE_UNEXPECTED_ALERT


This is the first report I've had after the serf update.

Here's an untested patch that is similar to the serf bug.  You would
apply this in the www/apache24 port.

Index: files/patch-modules_ssl_ssl__engine__io.c
===
--- files/patch-modules_ssl_ssl__engine__io.c   (nonexistent)
+++ files/patch-modules_ssl_ssl__engine__io.c   (working copy)
@@ -0,0 +1,11 @@
+--- modules/ssl/ssl_engine_io.c.orig   2021-02-09 15:09:39.362123000 -0800
 modules/ssl/ssl_engine_io.c2021-02-09 15:12:13.59669 -0800
+@@ -542,7 +542,7 @@ static int bio_filter_in_gets(BIO *bio, char *buf, int
+
+ static long bio_filter_in_ctrl(BIO *bio, int cmd, long num, void *ptr)
+ {
+-return -1;
++return 0;
+ }
+
+ #if MODSSL_USE_OPENSSL_PRE_1_1_API
   


Thank you very much for investigating and the patch.

I haven't got the chance to apply the patch yet, I'll do within the next two 
hours. For
the record: I filed a PR on this specific problem in Apache 2.4, please see 
here:

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

Kind regards,

O. Hartmann



I tried the patch, it doesn't work.
Assuming that it is sufficient to recompile from scratch/clean tree the whole 
OS and then
recompile every port required by www/apach24, applying then the patch, I tried 
to connect
to pages served by the 14-CURRENT server running the pacthed Apache 2.4 (ports 
tree at
the most recent state at that time), I still get the error described above.

Kind regards,

oh


I finally reproduced this today and was able to at least get a valid response 
back
from the server using openssl s_client as the client with a larger version of 
this
patch.

You can find the full patch at https://reviews.freebsd.org/D28932

--
John Baldwin
___
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: HEADS-UP: PIE enabled by default on main

2021-02-25 Thread Greg 'groggy' Lehey 
On Thursday, 25 February 2021 at 15:58:07 -0500, Ed Maste wrote:
> As of 9a227a2fd642 (main-n245052) base system binaries are now built
> as position-independent executable (PIE) by default, for 64-bit
> architectures. PIE executables are used in conjunction with address
> randomization as a mitigation for certain types of security
> vulnerabilities.
>
> If you track -CURRENT and normally build WITHOUT_CLEAN you'll need to
> do one initial clean build -- either run `make cleanworld` or set
> WITH_CLEAN=yes.

This details worries me.  How compatible are PIE executables with
non-PIE executables?  Can I run PIE executables on older systems?  Can
I run older executables on a PIE system?

Greg
--
Sent from my desktop computer.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA


signature.asc
Description: PGP signature

HEADS-UP: PIE enabled by default on main

2021-02-25 Thread Ed Maste 
As of 9a227a2fd642 (main-n245052) base system binaries are now built
as position-independent executable (PIE) by default, for 64-bit
architectures. PIE executables are used in conjunction with address
randomization as a mitigation for certain types of security
vulnerabilities.

If you track -CURRENT and normally build WITHOUT_CLEAN you'll need to
do one initial clean build -- either run `make cleanworld` or set
WITH_CLEAN=yes.

No significant user-facing changes are expected from this change, but
there are some minor ones. For example, `file` will indicate that
binaries are PIE by reporting something like `ELF 64-bit LSB pie
executable` rather than `ELF 64-bit LSB executable`. Also, for most
workloads no notable performance impact is expected.

For almost all ports this should result in no change. There are a
small number of ports that use base system /usr/share/mk
infrastructure and thus inherit the base system default, and some of
those initially failed to build. Those found during an exp-run in
PR253275 have been addressed or have patches waiting.

Please watch out for any new issues after you next update the base
system and/or ports, and report issues via a Bugzilla PR or in reply
here.
___
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: zpool upgrade can't enable new features

2021-02-25 Thread Martin Matuska 

I have submitted a pull request to fix this in OpenZFS:
https://github.com/openzfs/zfs/pull/11653

On 25. 2. 2021 17:20, John Kennedy wrote:

On Thu, Feb 25, 2021 at 11:09:17AM -0300, Renato Botelho wrote:

I recently upgraded a CURRENT system to main-n244932-248a47a4c2f and
zpool status shows:

pool: zroot
   state: ONLINE
status: Some supported and requested features are not enabled on the pool.
  The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
  the pool may no longer be accessible by software that does not support
  the features. See zpool-features(5) for details.

   I noticed that the other day with main-n245037-6e822e99570f.

  pool: zroot
 state: ONLINE
status: Some supported and requested features are not enabled on the 
pool.
The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
the pool may no longer be accessible by software that does not 
support
the features. See zpool-features(5) for details.
  scan: scrub repaired 0B in 00:01:10 with 0 errors on Mon Feb  1 
18:34:43 2021
config:

NAME   STATE READ WRITE CKSUM
zroot  ONLINE   0 0 0
  vtbd0p3.eli  ONLINE   0 0 0

   I didn't see anything at all that seemed missing.

zpool get all zroot | grep feature | sed -E 's/^([^ ]+)[ ]+([^ ]+)[ 
]+([^ ]+)[ ]+([^ ]+).*$/\1 \3 \4/' | sort | uniq -c
  12 zroot active local
  21 zroot enabled local


___
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: zpool upgrade can't enable new features

2021-02-25 Thread Martin Matuska 

Looks like Ryan didn't think it all the way through in:
https://github.com/openzfs/zfs/commit/35ec51796f0aa8d4fe322b48e7d1d5a65e38a4ce

I am preparing a patch for OpenZFS.

On 25. 2. 2021 17:20, John Kennedy wrote:

On Thu, Feb 25, 2021 at 11:09:17AM -0300, Renato Botelho wrote:

I recently upgraded a CURRENT system to main-n244932-248a47a4c2f and
zpool status shows:

pool: zroot
   state: ONLINE
status: Some supported and requested features are not enabled on the pool.
  The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
  the pool may no longer be accessible by software that does not support
  the features. See zpool-features(5) for details.

   I noticed that the other day with main-n245037-6e822e99570f.

  pool: zroot
 state: ONLINE
status: Some supported and requested features are not enabled on the 
pool.
The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
the pool may no longer be accessible by software that does not 
support
the features. See zpool-features(5) for details.
  scan: scrub repaired 0B in 00:01:10 with 0 errors on Mon Feb  1 
18:34:43 2021
config:

NAME   STATE READ WRITE CKSUM
zroot  ONLINE   0 0 0
  vtbd0p3.eli  ONLINE   0 0 0

   I didn't see anything at all that seemed missing.

zpool get all zroot | grep feature | sed -E 's/^([^ ]+)[ ]+([^ ]+)[ 
]+([^ ]+)[ ]+([^ ]+).*$/\1 \3 \4/' | sort | uniq -c
  12 zroot active local
  21 zroot enabled local


___
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: zpool upgrade can't enable new features

2021-02-25 Thread John Kennedy 
On Thu, Feb 25, 2021 at 11:09:17AM -0300, Renato Botelho wrote:
> I recently upgraded a CURRENT system to main-n244932-248a47a4c2f and 
> zpool status shows:
> 
>pool: zroot
>   state: ONLINE
> status: Some supported and requested features are not enabled on the pool.
>  The pool can still be used, but some features are unavailable.
> action: Enable all features using 'zpool upgrade'. Once this is done,
>  the pool may no longer be accessible by software that does not 
> support
>  the features. See zpool-features(5) for details.

  I noticed that the other day with main-n245037-6e822e99570f.

  pool: zroot
 state: ONLINE
status: Some supported and requested features are not enabled on the 
pool.
The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
the pool may no longer be accessible by software that does not 
support
the features. See zpool-features(5) for details.
  scan: scrub repaired 0B in 00:01:10 with 0 errors on Mon Feb  1 
18:34:43 2021
config:

NAME   STATE READ WRITE CKSUM
zroot  ONLINE   0 0 0
  vtbd0p3.eli  ONLINE   0 0 0

  I didn't see anything at all that seemed missing.

zpool get all zroot | grep feature | sed -E 's/^([^ ]+)[ ]+([^ ]+)[ 
]+([^ ]+)[ ]+([^ ]+).*$/\1 \3 \4/' | sort | uniq -c
  12 zroot active local
  21 zroot enabled local

___
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"

zpool upgrade can't enable new features

2021-02-25 Thread Renato Botelho 
I recently upgraded a CURRENT system to main-n244932-248a47a4c2f and 
zpool status shows:


  pool: zroot
 state: ONLINE
status: Some supported and requested features are not enabled on the pool.
The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
the pool may no longer be accessible by software that does not 
support

the features. See zpool-features(5) for details.
config:

NAMESTATE READ WRITE CKSUM
zroot   ONLINE   0 0 0
  raidz2-0  ONLINE   0 0 0
da0p4   ONLINE   0 0 0
da1p4   ONLINE   0 0 0
da2p4   ONLINE   0 0 0
da3p4   ONLINE   0 0 0

errors: No known data errors

Then I ran zpool upgrade zroot and got:

This system supports ZFS pool feature flags.

Pool 'zroot' already has all supported and requested features enabled.

After that zpool status output stays the same what made me believe 
something is not right here.

--
Renato Botelho
___
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"