Re: 14-current: unable to boot after upgrade (installworld)

[Toomas Soome via freebsd-current]

> On 9. Dec 2021, at 20:54, Sergey Dyatko  wrote:
> 
> tiger@dl:~ % gpart show
> 
>   |
> =>40  3907029088  da4  GPT  (1.8T)
>  4010241  freebsd-boot  (512K)
>1064 984   - free -  (492K)
>2048  39070269442  freebsd-zfs  (1.8T)
>  3907028992 136   - free -  (68K)
> 
> =>40  3907029088  da5  GPT  (1.8T)
>  4010241  freebsd-boot  (512K)
>1064 984   - free -  (492K)
>2048  39070269442  freebsd-zfs  (1.8T)
>  3907028992 136   - free -  (68K)
> 
> =>40  3907029088  da6  GPT  (1.8T)
>  4010241  freebsd-boot  (512K)
>1064 984   - free -  (492K)
>2048  39070269442  freebsd-zfs  (1.8T)
>  3907028992 136   - free -  (68K)
> 
> =>40  3907029088  da7  GPT  (1.8T)
>  4010241  freebsd-boot  (512K)
>1064 984   - free -  (492K)
>2048  39070269442  freebsd-zfs  (1.8T)
>  3907028992 136   - free -  (68K)
> 
> i'm not sure about video, everything happens faster than I can see :-) but
> sometimes the system does not freeze and I can enter commands. Can this
> help in some way?
> 

maybe, maybe not; from one hand, BTX register dump may help us to identify 
possible location or give other clues - eip=004cfrom your screenshot is 
telling us that some structure with function pointers must have been corrupted, 
seems like NULL pointer derefernce caused by this corruption. So the 
investigation should try to identify what is causing such corruption…. 

Since it was booting before, does the old loader start? I see the iKVM windo 
does have record menu entry, can it be used to record whole incident?

rgds,
toomas


> чт, 9 дек. 2021 г. в 18:19, Toomas Soome :
> 
>> 
>> 
>>> On 9. Dec 2021, at 20:06, Sergey Dyatko  wrote:
>>> 
>>> I was sure the installer did it when I reinstalled the system from
>> scratch. I
>>> can load 14-current successfully after boot via PXE and installworld with
>>> 13-current
>>> now I did the following:
>>> 1) boot from HDDs FreeBSD 14.0-CURRENT #0 main-n251494-f953785b3df (with
>>> 'old' world)
>>> 2)run installworld (f953785b3df)
>>> 3) run `gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da${D}`
>>> command , where D=4..7
>>> root@dl:/usr/src # zpool status
>>> pool: zroot
>>> state: ONLINE
>>> config:
>>> 
>>>   NAMESTATE READ WRITE CKSUM
>>>   zroot   ONLINE   0 0 0
>>> mirror-0  ONLINE   0 0 0
>>>   da4p2   ONLINE   0 0 0
>>>   da5p2   ONLINE   0 0 0
>>> mirror-1  ONLINE   0 0 0
>>>   da6p2   ONLINE   0 0 0
>>>   da7p2   ONLINE   0 0 0
>>> errors: No known data errors
>>> 
>>> after `shutdown -r now` system still doesn't boot  with the same error.
>> As
>>> far I can see, there is /boot/lua/config.lua present, but when I try to
>> run
>>> command more /boot/lua/config.lua system hangs with following error:
>>> https://imgur.com/5p0xu6W.png
>>> 
>> 
>> You seem to get 2x BTX panic, could you try to create video from console,
>> so we could get register dumps?
>> 
>> can this system do UEFI boot and if so, can you test it? Could you post
>> partition tables?
>> 
>> rgds,
>> toomas
>> 
>> 
>>> 
>>> чт, 9 дек. 2021 г. в 15:56, Warner Losh :
>>> 
 On Thu, Dec 9, 2021 at 7:58 AM Tomoaki AOKI 
 wrote:
 
> On Thu, 9 Dec 2021 13:36:10 +
> "Sergey V. Dyatko"  wrote:
> 
>> Hi,
>> 
>> Yesterday I tried to upgrade old 13-current (svn rev r368473) to fresh
>> 14-current from git,it looked like this:
>> 1) git pull https://git.freebsd.org/src.git /usr/src
>> 2) cd /usr/src ; make buildworld; make kernel
>> 3) shutdown -r now
>> after that I _successfully_ booted into 14-current and continued with
>> etcupdate -p
>> make installworld
>> etcupdate -B
>> shutdown -r now
>> 
>> but after that server doesn't come back. After I conneted to this
 server
> via
>> IPMI ip-kvm I saw following (sorry for external link):
>> https://i.imgur.com/jH6MHd2.png
>> 
>> Well. There was a migration to zol between r368473 and current 'main'
> branch so
>> I decided to install fresh 14-current from snapshot
>> FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to
 avoid
>> possible problems
>> 
>> and again, after make kernel and reboot OS runs, but after
>> installworld
> I ended up in the same situation
>> 
>> thoughts ?
>> 
>> --
>> wbr, Sergey
>> 
>> 
> 
> Bootcode should be updated.
> The procedure you wrote doesn't seem to update it.
> 
 
 The posted error is one you get when you can't read the filesystem,
>> which
 is why you need to update

Re: 14-current: unable to boot after upgrade (installworld)

[Toomas Soome via freebsd-current]

> On 9. Dec 2021, at 20:06, Sergey Dyatko  wrote:
> 
> I was sure the installer did it when I reinstalled the system from scratch. I
> can load 14-current successfully after boot via PXE and installworld with
> 13-current
> now I did the following:
> 1) boot from HDDs FreeBSD 14.0-CURRENT #0 main-n251494-f953785b3df (with
> 'old' world)
> 2)run installworld (f953785b3df)
> 3) run `gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da${D}`
> command , where D=4..7
> root@dl:/usr/src # zpool status
>  pool: zroot
> state: ONLINE
> config:
> 
>NAMESTATE READ WRITE CKSUM
>zroot   ONLINE   0 0 0
>  mirror-0  ONLINE   0 0 0
>da4p2   ONLINE   0 0 0
>da5p2   ONLINE   0 0 0
>  mirror-1  ONLINE   0 0 0
>da6p2   ONLINE   0 0 0
>da7p2   ONLINE   0 0 0
> errors: No known data errors
> 
> after `shutdown -r now` system still doesn't boot  with the same error. As
> far I can see, there is /boot/lua/config.lua present, but when I try to run
> command more /boot/lua/config.lua system hangs with following error:
> https://imgur.com/5p0xu6W.png
> 

You seem to get 2x BTX panic, could you try to create video from console, so we 
could get register dumps?

can this system do UEFI boot and if so, can you test it? Could you post 
partition tables?

rgds,
toomas


> 
> чт, 9 дек. 2021 г. в 15:56, Warner Losh :
> 
>> On Thu, Dec 9, 2021 at 7:58 AM Tomoaki AOKI 
>> wrote:
>> 
>>> On Thu, 9 Dec 2021 13:36:10 +
>>> "Sergey V. Dyatko"  wrote:
>>> 
 Hi,
 
 Yesterday I tried to upgrade old 13-current (svn rev r368473) to fresh
 14-current from git,it looked like this:
 1) git pull https://git.freebsd.org/src.git /usr/src
 2) cd /usr/src ; make buildworld; make kernel
 3) shutdown -r now
 after that I _successfully_ booted into 14-current and continued with
 etcupdate -p
 make installworld
 etcupdate -B
 shutdown -r now
 
 but after that server doesn't come back. After I conneted to this
>> server
>>> via
 IPMI ip-kvm I saw following (sorry for external link):
 https://i.imgur.com/jH6MHd2.png
 
 Well. There was a migration to zol between r368473 and current 'main'
>>> branch so
 I decided to install fresh 14-current from snapshot
 FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to
>> avoid
 possible problems
 
 and again, after make kernel and reboot OS runs, but after installworld
>>> I ended up in the same situation
 
 thoughts ?
 
 --
 wbr, Sergey
 
 
>>> 
>>> Bootcode should be updated.
>>> The procedure you wrote doesn't seem to update it.
>>> 
>> 
>> The posted error is one you get when you can't read the filesystem, which
>> is why you need to update
>> boot blocks across the OpenZFS change.
>> 
>> Warner
>> 

Re: EFI/loader show garbage in console when set to some resolution in loader.conf

[Toomas Soome via freebsd-current]

> On 6. Sep 2021, at 19:44, Karel Gardas  wrote:
> 
> Hello,
> 
> I'm attempting to set EFI console resolution in loader to 1920x1920. This is 
> working fine on all 3 tested* combinations when interrupting loader with '3' 
> key and then
> issueing 'gop set 11' command and then 'boot' command.
> 
> However I'd like to make that permanent and here issue comes. I've tried both:
> 
> - edit /boot/loader.conf by adding
>  'exec="gop set 11"'
> 
> - edit /boot/loader.conf by adding
>  'efi_max_resolution="1920x1920"'
> 
> neither of those works on neither of 3 tested combinations where tested 
> combinations are:

if you have this setting, what does gop get report? With the versions listed 
below, was the loader in ESP updated too?

> 
> (1) 13.0 release
> (2) 13.0-p4 (stable)
> (3) 14.0 snapshot from 2.9.
> 
> The behavior is still the same. Screen blanks (like it would do gop set 11), 
> then switches to text mode to show loader UI and when kernel
> is loaded it correctly shows that efi resolution is 1920x1920 but then when 
> kernels boot, it produce just garbage to the console like loader and kernel 
> resolution would be off
> by some unknown number...
> 
> Is this is known issue, is there a known workaround for it? Or shall I report 
> it properly to bugzilla?
> 
> Thanks!
> Karel
> 

what you get from: dmesg | grep efifb

rgds,
toomas

Re: FreeBSD-13-STABLE: lib/libsecureboot/verify_file.c: error: use of undeclared identifier 'SOPEN_MAX'

[Toomas Soome via freebsd-current]

> On 3. Sep 2021, at 18:59, FreeBSD User  wrote:
> 
> Hello,
> 
> enabling 
> 
> WITH_BEARSSL 
> 
> in src.conf renders buildworld on 13-STABLE to fail, but not on
> 14-CURRENT. 
> 
> 
> 
> This is the difference between the sources, obviously 14-CURRENT contains the 
> correct
> definition of SOPEN_MAX, while 13-STABLE not (undefinied SOPNE_MAX triggers 
> the compiler to
> fail, 
> /usr/src/lib/libsecureboot/verify_file.c:59:22: error: use of undeclared 
> identifier
> 'SOPEN_MAX'), see
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258211
> 
> 
> [...]
> 13-STABLE
> :/pool/sources/13-STABLE/src # grep -r SOPEN_MAX .
> ./lib/libsecureboot/tests/Makefile:XCFLAGS.verify_file += -DSOPEN_MAX=64
> ./lib/libsecureboot/verify_file.c:static int ve_status[SOPEN_MAX+1];
> ./lib/libsecureboot/verify_file.c:  if (fd >= 0 && fd < SOPEN_MAX) {
> ./lib/libsecureboot/verify_file.c:  ve_status[SOPEN_MAX] = ves;
> ./lib/libsecureboot/verify_file.c: *@li ve_status[SOPEN_MAX] if 
> ve_status_state is none
> ./lib/libsecureboot/verify_file.c:  fd >= 0 && fd < SOPEN_MAX)
> ./lib/libsecureboot/verify_file.c:  return (ve_status[SOPEN_MAX]);  /* 
> most recent */
> 
> [...]
> 14-CURRENT
> ./lib/libsecureboot/tests/Makefile:XCFLAGS.verify_file += -DSOPEN_MAX=64
> ./lib/libsecureboot/verify_file.c:#ifndef SOPEN_MAX
> ./lib/libsecureboot/verify_file.c:#define   SOPEN_MAX   64
> ./lib/libsecureboot/verify_file.c:static int ve_status[SOPEN_MAX+1];
> ./lib/libsecureboot/verify_file.c:  if (fd >= 0 && fd < SOPEN_MAX) {
> ./lib/libsecureboot/verify_file.c:  ve_status[SOPEN_MAX] = ves;
> ./lib/libsecureboot/verify_file.c: *@li ve_status[SOPEN_MAX] if 
> ve_status_state is none
> ./lib/libsecureboot/verify_file.c:  fd >= 0 && fd < SOPEN_MAX)
> ./lib/libsecureboot/verify_file.c:  return (ve_status[SOPEN_MAX]);  /* 
> most recent */
> 
> 
> 
> 
> -- 
> O. Hartmann
> 

Hi!

Sorry, it is fixed now. Missed one cherry-pick.

rgds,
toomas

Re: lost high resolution console with lastest snapshot

[Toomas Soome via freebsd-current]

> On 6. Jul 2021, at 16:21, Nuno Teixeira  wrote:
> 
> it worked! 8x16 is exacly
> the same size as before.
> 
> And you are right, screen res is correct but font size is wrong. Is it some
> kind of bug?
> 


yes and no. the automatic font selection does try the best, but people are 
different and the automatic selection may not be best for You. Anyhow, thats 
the reason to have option to set it manually.

rgds,
toomas


> Tomoaki AOKI  escreveu no dia terça, 6/07/2021
> à(s) 14:08:
> 
>> Or if the previous installation is old enough,
>> possibly just a font auto-selection problem.
>> If screen resolution is correct, but tooo large font is selected,
>> lower resolution screen is mimiced.
>> 
>> If so, try setting
>> 
>> screen.font=8x16
>> 
>> or any size you prefer from files in /boot/fonts.
>> 
>> 
>> On Tue, 6 Jul 2021 14:42:26 +0200 (CEST)
>> Ronald Klop  wrote:
>> 
>>> Maybe your previous install did not use UEFI?
>>> 
>>> Ronald.
>>> 
>>> 
>>> Van: Toomas Soome via freebsd-current 
>>> Datum: dinsdag, 6 juli 2021 14:12
>>> Aan: Nuno Teixeira 
>>> CC: FreeBSD CURRENT 
>>> Onderwerp: Re: lost high resolution console with lastest snapshot
>>>> 
>>>> 
>>>> 
>>>>> On 6. Jul 2021, at 14:49, Nuno Teixeira  wrote:
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> gop get says:
>>>>> ---
>>>>> EDID 1920x1080
>>>>> mode 0
>>>>> ---
>>>>> 
>>>>> When I try other modes it sometimes decreases res.
>>>>> 
>>>>> I remember that high res was working until now.
>>>>> Maybe a bug?
>>>> 
>>>> GOP set/get/list is the only interface with uefi graphics we can use
>> from bootloader. From loader, we only can try to use resolutions listed by
>> gop list, even if the hardware does support better. This is the firmware
>> limit (check for update?). Once operating system is running, X11/DRM
>> drivers can switch to use better resolution.
>>>> 
>>>> Toomas
>>>> 
>>>>> 
>>>>> Toomas Soome  escreveu no dia ter〓a, 6/07/2021 〓(s)
>> 12:11:
>>>>> 
>>>>>> 
>>>>>> 
>>>>>>>> On 6. Jul 2021, at 14:07, Nuno Teixeira 
>> wrote:
>>>>>>> 
>>>>>>> I forgot to say that dmesg show vt resolution:
>>>>>>> 
>>>>>>> ---
>>>>>>> (...)
>>>>>>> FreeBSD clang version 12.0.1 (g...@github.com:llvm/llvm-project.git
>>>>>>> llvmorg-12.0.1-rc2-0-ge7dac564cd0e)
>>>>>>> WARNING: WITNESS option enabled, expect reduced performance.
>>>>>>> ==> VT(efifb): resolution 1920x1080
>>>>>>> (...)
>>>>>>> 
>>>>>>> But res isn't at 1920x1080
>>>>>> 
>>>>>> from boot menu, press ESC to get OK prompt, enter commands:
>>>>>> 
>>>>>> gop get
>>>>>> gop list
>>>>>> gop set X 〓 where X is number from gop list output.
>>>>>> 
>>>>>> this way you can check if the resolution does change or not.
>>>>>> 
>>>>>> rgds,
>>>>>> toomas
>>>>>> 
>>>>>>> 
>>>>>>> Nuno Teixeira  escreveu no dia ter〓a,
>> 6/07/2021
>>>>>> 〓(s)
>>>>>>> 11:37:
>>>>>>> 
>>>>>>>> Hello,
>>>>>>>> 
>>>>>>>> I remember having high resolution console at 1920x1080 but due to
>>>>>> hardware
>>>>>>>> problems I replaced hdd and installed latest snapshot #0
>>>>>>>> main-n247671-c5f4772c66d: Thu Jul  1 and now console resolution
>> is very
>>>>>> low.
>>>>>>>> 
>>>>>>>> Did I missed something or I need to configure system so I can
>> have high
>>>>>>>> res again?
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Nuno Teixeira
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> 
>> --
>> Tomoaki AOKI
>> 
>> 

Re: lost high resolution console with lastest snapshot

[Toomas Soome via freebsd-current]

> On 6. Jul 2021, at 14:49, Nuno Teixeira  wrote:
> 
> Hello,
> 
> gop get says:
> ---
> EDID 1920x1080
> mode 0
> ---
> 
> When I try other modes it sometimes decreases res.
> 
> I remember that high res was working until now.
> Maybe a bug?

GOP set/get/list is the only interface with uefi graphics we can use from 
bootloader. From loader, we only can try to use resolutions listed by gop list, 
even if the hardware does support better. This is the firmware limit (check for 
update?). Once operating system is running, X11/DRM drivers can switch to use 
better resolution.

Toomas 

> 
> Toomas Soome  escreveu no dia terça, 6/07/2021 à(s) 12:11:
> 
>> 
>> 
 On 6. Jul 2021, at 14:07, Nuno Teixeira  wrote:
>>> 
>>> I forgot to say that dmesg show vt resolution:
>>> 
>>> ---
>>> (...)
>>> FreeBSD clang version 12.0.1 (g...@github.com:llvm/llvm-project.git
>>> llvmorg-12.0.1-rc2-0-ge7dac564cd0e)
>>> WARNING: WITNESS option enabled, expect reduced performance.
>>> ==> VT(efifb): resolution 1920x1080
>>> (...)
>>> 
>>> But res isn't at 1920x1080
>> 
>> from boot menu, press ESC to get OK prompt, enter commands:
>> 
>> gop get
>> gop list
>> gop set X — where X is number from gop list output.
>> 
>> this way you can check if the resolution does change or not.
>> 
>> rgds,
>> toomas
>> 
>>> 
>>> Nuno Teixeira  escreveu no dia terça, 6/07/2021
>> à(s)
>>> 11:37:
>>> 
 Hello,
 
 I remember having high resolution console at 1920x1080 but due to
>> hardware
 problems I replaced hdd and installed latest snapshot #0
 main-n247671-c5f4772c66d: Thu Jul  1 and now console resolution is very
>> low.
 
 Did I missed something or I need to configure system so I can have high
 res again?
 
 Thanks,
 Nuno Teixeira
 
>> 
>> 

Re: lost high resolution console with lastest snapshot

[Toomas Soome via freebsd-current]

> On 6. Jul 2021, at 14:07, Nuno Teixeira  wrote:
> 
> I forgot to say that dmesg show vt resolution:
> 
> ---
> (...)
> FreeBSD clang version 12.0.1 (g...@github.com:llvm/llvm-project.git
> llvmorg-12.0.1-rc2-0-ge7dac564cd0e)
> WARNING: WITNESS option enabled, expect reduced performance.
> ==> VT(efifb): resolution 1920x1080
> (...)
> 
> But res isn't at 1920x1080

from boot menu, press ESC to get OK prompt, enter commands:

gop get
gop list
gop set X — where X is number from gop list output.

this way you can check if the resolution does change or not.

rgds,
toomas

> 
> Nuno Teixeira  escreveu no dia terça, 6/07/2021 à(s)
> 11:37:
> 
>> Hello,
>> 
>> I remember having high resolution console at 1920x1080 but due to hardware
>> problems I replaced hdd and installed latest snapshot #0
>> main-n247671-c5f4772c66d: Thu Jul  1 and now console resolution is very low.
>> 
>> Did I missed something or I need to configure system so I can have high
>> res again?
>> 
>> Thanks,
>> Nuno Teixeira
>> 

Re: vt: efifb / fb+kms resolutions and fonts — how to?

[Toomas Soome via freebsd-current]

> On 13. May 2021, at 17:04, Lev Serebryakov  wrote:
> 
> 
> Is it possible to get native 1920x1080 resoultiuon and small fond (many 
> lines) early on boot?
> 
> Lenovo T540p has native resolution 1920x1080 and boots with UEFI. I've tried 
> two configs:
> 
> (1) No special configuration in /boot/loader.conf
> 
> (1.1) Loader menu is ugly, font is large and jagged, looks like "text 
> resolution" is 80x25.
> 
> (1.2) Early on boot kernel reports: "VT(efifb): resolution 640x480".
>   "text resolution" is 80x25 and font is large and ugly still.
>   Font ugliness is expected for non-native resolution and explains loader 
> ugliness.
> 
> (1.3) After i915kms.ko load (by rc(8)) resolution is native (1920x1080), font 
> is very small, there are
>   A LOT of "text resolution".
> 
> (2) "efi_max_resolution=1080p" in /boot/loader.conf
> 
> (2.1) Loader menu is nice, font is large and smooth, but looks like "text 
> resolution" is 80x25 still.
> 
> (2.2) Early on boot kernel reports: "VT(efifb): resolution 1920x1080".
>   "text resolution" is 80x25 and font is large and smooth still.
> 
> (2.3) After i915kms.ko load (by rc(8)) resolution is native (1920x1080), font 
> is THE SAME (large and smooth),
>   "text resolution" is 80x25 still!
> 
> 
> Adding "screen.font="16x32"" into "/boot/loader.conf" doesn't change anything.
> 
> Is it possible to have EFIFB resolution 1920x1080, but small font and lot of 
> "text resolution" from early boot on?
> 

First thing, please check if you have boot1.efi or loader.efi in ESP (EFI 
System Partition), and when it is loader.efi, please check it is latest.

Then next step would be to test out gfx modes, on loader OK prompt, try to 
switch modes with gop list + gop set command, use gop get to verify (on my 
system, only 800x600 is used, despite there are different modes in list). With 
mode change, there also may be font change.

Then next thing is to check different fonts; the default list is shown when you 
enter: set screen.font=— without value, it will list the available ones. 
Once you set the font, show COLUMNS and show LINES will tell you terminal size. 
This font is also passed to kernel and used as default font.

If you want to use custom font, it must be prepared with vtfontcvt; and can be 
loaded with loadfont command (or it can be added to index, note that index is 
assuming unique glyph size and last entry wins). In any case, you can test this 
with loadfont /boot/fonts/gallant.fnt, gallant is not listed in the index 
(because it has much smaller number of glyphs compared to terminus).

If KMS will set different resolution and the default font is not good, then 
vidcontrol command can be used to load better one. 

hope this helps,
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: bectl, chroot, pkg upgrade, no record of the upgrade in /var/log/messages

[Toomas Soome via freebsd-current]

BE as snapshot + clone? zpool history has that fact, but if anything else is 
logged (syslog or direct file write), it will be in old BE. Unless /var/log is 
created as shared dataset.

Sent from my iPhone

> On 2. May 2021, at 14:42, Graham Perrin  wrote:
> 
> This morning I created a boot environment, mounted it at
> 
> /tmp/up
> 
> – then chroot to /tmp/up and at 09:52,
> 
> pkg upgrade -y -r FreeBSD
> 
> Upgrade succeeded. I activated then unmounted the environment, restarted.
> 
> No record of the upgrade in /var/log/messages – is this normal?
> 
> <2021-05-02 10:48 messages without a record of recent pkg upgrade.txt>
> ___
> 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: [Bug 254395] bsdinstall: fail script install after BETA3

[Toomas Soome via freebsd-current]

> On 20. Mar 2021, at 00:21, Yuri Pankov  wrote:
> 
> Chris wrote:
>> On 2021-03-19 13:06, bugzilla-nore...@freebsd.org wrote:
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395
>>> 
>>> Nathan Whitehorn  changed:
>>> 
>>>What|Removed |Added
>>> 
>>> 
>>>Severity|Affects Only Me |Affects Some People
>>>  CC||i...@freebsd.org
>>>Priority|--- |Normal
>>> 
>>> --- Comment #6 from Nathan Whitehorn  ---
>>> Thanks for the suggestion about the documentation -- I've updated the
>>> man page.
>>> 
>>> The core problem here is that our tar can't extract archives to FAT32
>>> with
>>> default options, since it treats inability to set modification time as
>>> a fatal
>>> error and FAT32 doesn't let you do that on the root directory. As
>>> such, any
>>> file in the release tarballs can't be extracted to FAT32. For interactive
>>> installations, the bsdinstall distextract tool, a CURSES-y frontend to
>>> libarchive, solves this by ignoring ctime/mtime errors.
>>> 
>>> Some extra commentary on solutions, so it can be in one place.
>>> Possibilities
>>> are:
>>> 
>>> 1. We drop /boot/efi from mtree. That will result in it not existing in
>>> base.txz, solving this issue, but will result in it not being in
>>> mtree. It will
>>> also leave in place an identical bug that will break scripted
>>> installation on
>>> bare-metal POWER8 and POWER9 systems, although that is a tier-2 platform.
>>> 
>>> 2. We add an option to tar to ignore failure in setting ctime/mtime,
>>> like the
>>> interactive installer uses. This has the difficulty that the patch is
>>> hacky and
>>> would have to go through upstream.
>>> 
>>> 3. We go back to using distextract for scripted installations as well as
>>> interactive ones, reverting d7640440fb644fde697f62fdff0b55aa3a4d5ef7.
>>> This
>>> fixes this issue but will result in installation failures for scripted
>>> installs
>>> without a controlling tty. (It will also add nice progress bars to
>>> scripted
>>> installs).
>>> 
>>> 4. We do --exclude /boot/efi when running tar, then mkdir -p it by hand
>>> afterward. This is incredibly hacky and otherwise essentially
>>> functionally
>>> equivalent to #1. Like #1, it will fix this issue and has no obvious
>>> functional
>>> downside, but leaves scripted installs bare-metal POWER8 and POWER9
>>> broken.
>>> 
>>> 5. We patch the file system driver to (pretend to) allow setting times
>>> on the
>>> mount point. I don't want to do this, since I don't want to solve this
>>> in the
>>> kernel at RC3 and I don't like it pretending to do things it can't do.
>> 
>>  6. (my favorite) do NOT require that the efi/ partition be in strictly a
>>  fat32 format. I mean fat32 is not strictly required as the format for
>> the efi
>>  partition. It is simply _assumed_ to be the required format and as
>> such, the
>>  one used in so many cases.
> 
> Wrong, see "13.3 File System Format" in UEFI specification.
> 

it is not as simple as that:)


13.3.1.1 is more specific:
=
The EFI firmware must support the FAT32, FAT16, and FAT12 variants of the EFI 
file system. What variant of EFI FAT to use is defined by the size of the 
media. The rules defining the relationship between media size and FAT variants 
is defined in the specification for the EFI file system.

=

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

[Toomas Soome via freebsd-current]

> On 2. Mar 2021, at 20:32, Rodney W. Grimes  
> wrote:
> 
>>> On 26. Feb 2021, at 17:56, Rodney W. Grimes  
>>> wrote:
>>> 
>>>>> 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  
>>>>>>>> <https://reviews.freebsd.org/D28849>
>>>>>>>> 
>>>>>>>> I have built loader binaries as well (bios and uefi):
>>>>>>>> loader_lua<http://148-52-235-80.sta.estpak.ee/loader_lua>
>>>>>>>> loader_lua.efi<http://148-52-235-80.sta.estpak.ee/loader_lua.efi>
> 
> I have tested this on:
>   Lenovo W530
>   Dell E5470
>   Acer Aspire 1410
> 
> all work fine with resonable display resolution.
> 
> One more comment below...
> 
>>>>>>>> 
>>>>>>>> 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.
>>> 
>>> Is there a way for me to know if the laoder found EDID data or not?
>>> It might be that the issue is that what ever loader is using for an API is 
>>> not working.
>>> I based my "EDID is very common on laptop screens" on the fact that X11 
>>> almost always finds EDID.
>>> 
>> 
>> Yes, gop get / vbe list   ? yes, it is inconsistent, should fix at some 
>> point? :)
>> 
>> we do use gop get active edid/get discovered edid protocol and vbe function 
>> 0x4f15.
> 
> On all my handy laptops, E5470, T400, W530, Acer 1410 edid is present and seen
> by the loader.
> 
> 

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: No serial console: VBE not available

[Toomas Soome via freebsd-current]

> On 1. Mar 2021, at 12:34, Harry Schmalzbauer  wrote:
> 
> Am 26.02.2021 um 17:58 schrieb Toomas Soome via freebsd-current:
>>> On 26. Feb 2021, at 18:54, O. Hartmann  wrote:
>>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>> 
>>> hello,
>>> 
>>> running a FreeBSD appliance on top of a PCengines APU2C4 with the latest 
>>> seabios
>>> (apu2_v4.13.0.3.rom). The PCengines boot image layout is based on 
>>> pmbr/gptboot (GPT patition
>>> scheme), via nanoBSD the latest pmbr/gptboot binaries are applied taken 
>>> from the 13-STABLE
>>> tree (or 14-CURRENT).
>>> 
>>> It doesn't matter whether I put these lines into /boot/loader.conf:
>>> 
>>> boot_serial="YES"
>>> comconsole_speed="115200"
> :
> :
> :
>> 
>> You are missing this one:
>> commit 61c50cbc096d28e44cb8b627e524ae58158c423a
> 
> Actually stable/13 is missing this.
> It was merged to releng/13.0, but not to stable/13 as far as my git skills 
> last:
> https://cgit.freebsd.org/src/log/stand/i386/libi386/vidconsole.c?h=stable%2F13
>  
> <https://cgit.freebsd.org/src/log/stand/i386/libi386/vidconsole.c?h=stable%2F13>
> 

.oO totally my bad, I have missed push… fixed, sorry.

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

[Toomas Soome via freebsd-current]

> On 28. Feb 2021, at 13:27, dmilith .  wrote:
> 
> First of all - ALSR is designed as mitigation for external attacks,
> not internal ones (logged in user).
> Second - Linux and FreeBSD both have weak implementations in
> comparison to PAX-driven ones. Try attacking the system with
> Grsecurity or HardenedBSD (both use the strongest ASLR available
> AFAIK).
> 
> Saying that security mitigation features that affect no performance
> are "meaningless", is just ridiculous or at least just irresponsible.
> It's like telling C programmers that stack protection or out of bounds
> checks are bad, cause there's nothing wrong with random SEGFAULTS from
> time to time…
> 


You seem to forget that those mechanisms are there exactly because programmers 
are not caring about random faults from time to time:D With correct code, one 
would not need mechanisms like ALSR. 

rgds,
toomas

> 
> On 28/02/2021, Ihor Antonov  wrote:
>> On 2021-02-27 22:29, Warner Losh wrote:
>>> On Sat, Feb 27, 2021 at 9:34 PM Ihor Antonov 
>>> wrote:
>>> 
> 
> But isn't it well-known that ASLR/ASR/any-related-buzzwork does not
> add
> any security, except imaginary?  The only purpose of it is to have a
> check-list item ticked green.
 
 I don't know if I should parse this as sarcasm (or any other form of
 "humor") or is a serious statement? But this does leave me with a whole
 bunch of questions..
 
 If this is really how Konstantin is describing it then is it OK to say
 about this to the whole Internet? Why FreeBSD Foundation is paying for
 meaningless work then? Why members of the Core team do this work?  Does
 this mean that FreeBSD is working to satisfy the silly needs of some
 fat
 customer? What about project independence and not being controlled by
 big money?
 
 Where can I read about ASLR and security myths?
>>> 
>>> Why not spend time and explain why this does not work?
 
>>> 
>>> Not to rise to the baitiness of all these leading questions (they really
>>> are quite contrary to how our community usually comports itself, but for
>>> the sake of civil discourse, I'll ignore)
>>> 
>>> I'll bet it has something to do with the many known ASLR attacks.  One is
>>> chronicled in https://www.vusec.net/projects/anc/ and elsewhere, which
>>> show
>>> how MMU side channels can defeat ASLR. Or maybe he's familiar with the
>>> offset2lib attack against Linux 64-bit ASLR documented in this paper
>>> https://cybersecurity.upv.es/attacks/offset2lib/offset2lib-paper.pdf.
>>> There's many others as well that show the shortcomings of ASLR and
>>> disclose
>>> ways to defeat it using various clever means.
>> 
>> Warner, thanks for the links. They are indeed interesting.
>> 
 You clearly should mean something useful and much more important than
 that,
>>> 
>>> Maybe he'd like to understand how PIE accomplishes better security give
>>> the
>>> known ASLR weaknesses. And rather than take a sarcastic tone, he asked
>>> for
>>> more details that back up the earlier claims of improved security so we
>>> could all learn something.
>> 
>> The conclusion of the paper in the second link clearly says:
>> 
>>We present a new weakness on the current implementationof the ASLR
>>Linux systems which affects PIE compiled ex-ecutables.  Applications
>>compiled with PIE are consideredto be more robust since it makes
>>attacks more difficult.
>> 
>> Which I read as ASLR and PIE work better together. This is the same what
>> Gordon was saying.
>> 
>> The whole situation is wrong on 2 different levels.
>> 
>> First: saying that ASLR is not perfect and can be broken is not the same
>> thing as saying "The only purpose of it is to have a check-list item ticked
>> green"
>> 
>> There are no perfect security measures, and you guys (kernel and OS
>> developers) should know that better than us (users). Hackers find new
>> exploits, developers find ways to mitigate them and cycle repeats. Just
>> the fact that ASLR can be broken is not the reason to not have it.
>> 
>> Second: look at this exchange from a distance
>> 
>> Ed: we are enabling security feature X, please rebuild your worlds..
>> Godron: great progress! go team!
>> Konstantin: why do you think this is great progress? (implying it is
>> not)
>> Gordon: well, I heard feature X works best with feature Y
>> Konstantin: feature Y is useless checkbox, next time you speak make sure
>> you say something useful!
>> 
>> Considering the fact that Konstantin himself worked on ASLR this is at
>> least confusing.. Also does this also mean that feature X (PIE) is also
>> useless checkbox?
>> 
>> Konstantin, Ed, Warner - I dunno what is going on in your house (Core) but
>> it does not look good form the outside. You are sending mixed signals to
>> your auditory.
>> 
>> 
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current

Re: No serial console: VBE not available

[Toomas Soome via freebsd-current]

> On 26. Feb 2021, at 18:54, O. Hartmann  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> hello,
> 
> running a FreeBSD appliance on top of a PCengines APU2C4 with the latest 
> seabios
> (apu2_v4.13.0.3.rom). The PCengines boot image layout is based on 
> pmbr/gptboot (GPT patition
> scheme), via nanoBSD the latest pmbr/gptboot binaries are applied taken from 
> the 13-STABLE
> tree (or 14-CURRENT).
> 
> It doesn't matter whether I put these lines into /boot/loader.conf:
> 
> boot_serial="YES"
> comconsole_speed="115200"
> console="comconsole"
> 
> autoboot_delay="0"
> 
> and in the kernel config file:
> 
> options CONSPEED=115200
> 
> while having alos in both cases
> 
> /boot/config
> - -h -S115200
> 
> following strict the handbook's suggestions.
> 
> After booting, I face always forever this screen:
> 
> SeaBIOS (version rel-1.12.1.3-0-g300e8b70)
> 
> Press F10 key now for boot menu
> 
> Select boot device:
> 
> 1. SD card SN64G 60906MiB
> 2. USB MSC Drive  USB DISK 3.0 PMAP
> 3. AHCI/0: Samsung SSD 860 EVO mSATA 250GB ATA-11 Hard-Disk (232 GiBytes)
> 4. Payload [setup]
> 5. Payload [memtest]
> 
> Booting from Hard Disk...
> /boot/config: -h -S115200
> Consoles: serial port  
> BIOS drive C: is disk0
> BIOS drive D: is disk1
> BIOS drive E: is disk2
> BIOS 639kB/3405336kB available memory
> 
> FreeBSD/x86 bootstrap loader, Revision 1.1
> (Mon Feb 22 18:17:30 CET 2021 root@thor)
> |
> 
> VBE not available
> 
> 
> 
> ... and its stuck forever ...
> 
> What is wrong here?
> 
> Thanks for your help,
> 
> kind regards
> 
> Oliver
> 


You are missing this one:
commit 61c50cbc096d28e44cb8b627e524ae58158c423a
Author: Toomas Soome 
Date:   Sun Feb 21 12:32:18 2021 +0200

loader: autoload_font will hung loader when there is no local console

If we start with console set to comconsole, the local
console (vidconsole, efi) is never initialized and attempt to
use the data can render the loader hung.

Reported by:Kamigishi Rei
MFC after: 3 days


The temporary workaround is to add -D, this will trigger call to vidc_init() 
and will prevent the hung.

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

[Toomas Soome via freebsd-current]

> On 26. Feb 2021, at 17:56, Rodney W. Grimes  
> wrote:
> 
>>> 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  
>>>>>> <https://reviews.freebsd.org/D28849>
>>>>>> 
>>>>>> I have built loader binaries as well (bios and uefi):
>>>>>> loader_lua<http://148-52-235-80.sta.estpak.ee/loader_lua>
>>>>>> loader_lua.efi<http://148-52-235-80.sta.estpak.ee/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.
> 
> Is there a way for me to know if the laoder found EDID data or not?
> It might be that the issue is that what ever loader is using for an API is 
> not working.
> I based my "EDID is very common on laptop screens" on the fact that X11 
> almost always finds EDID.
> 

Yes, gop get / vbe list   — yes, it is inconsistent, should fix at some point… 
:)

we do use gop get active edid/get discovered edid protocol and vbe function 
0x4f15.

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

[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  
>>>> <https://reviews.freebsd.org/D28849>
>>>> 
>>>> I have built loader binaries as well (bios and uefi):
>>>> loader_lua<http://148-52-235-80.sta.estpak.ee/loader_lua>
>>>> loader_lua.efi<http://148-52-235-80.sta.estpak.ee/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

[Toomas Soome via freebsd-current]

> 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  
>> <https://reviews.freebsd.org/D28849>
>> 
>> I have built loader binaries as well (bios and uefi):
>> loader_lua<http://148-52-235-80.sta.estpak.ee/loader_lua>
>> loader_lua.efi<http://148-52-235-80.sta.estpak.ee/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.

> 
> 
> 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.

> 
> 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. 

many thanks for testing,
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"

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

[Toomas Soome via freebsd-current]

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 is https://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
___
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)

[Toomas Soome via freebsd-current]

> 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).


> 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

___
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: Setting for displaying utf8 characters on all vt consoles results in panic on 14-CURRENT and 13.0-ALPHA3

[Toomas Soome via freebsd-current]

> On 1. Feb 2021, at 05:35, Yasuhiro Kimura  wrote:
> 
> From: Yasuhiro Kimura mailto:y...@utahime.org>>
> Subject: Setting for displaying utf8 characters on all vt consoles results in 
> panic on 14-CURRENT and 13.0-ALPHA3
> Date: Mon, 01 Feb 2021 11:41:35 +0900 (JST)
> 
>> To display utf8 characters on all vt console I did following settings.
>> 
>> 1. Download GNU Unifont BDF file
>>   
>> (http://unifoundry.com/pub/unifont/unifont-13.0.05/font-builds/unifont-13.0.05.bdf.gz)
>> 2. gunzip unifont-13.0.05.bdf.gz
>> 3. vtfontcvt unifont-13.0.05.bdf unifont.fnt
>> 4. cp unifont.fnt /usr/share/vt/fonts
>> 5. Add 'allscreens_flags="-f 8x16 unifont.fnt"' to /etc/rc.conf
>> 6. Add 'hw.vga.textmode=0' to /boot/loader.conf.local
>> 7. shutdown -r now
>> 
>> On 12.2-RELEASE and 11.4-RELEASE it works as is expected. But on
>> 14-CURRENT(man) and 13.0-ALPHA3(stable/13) it result in kernel panic.
>> 
>> Screen shot of 14-CURRENT.
>> https://www.utahime.org/FreeBSD/panic.20210201.14-CURRENT.png
>> 
>> 14-CURRENT(main):
>> yasu@rolling-vm-freebsd1[1006]% uname -a
>> FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 
>> 14.0-CURRENT #0 main-n244517-f17fc5439f5: Mon Feb  1 10:55:51 JST 2021 
>> ro...@rolling-vm-freebsd1.home.utahime.org:/usr0/freebsd/src/obj/usr0/freebsd/src/git/amd64.amd64/sys/GENERIC
>>   amd64
>> 
>> 13.0-ALPHA3(stable/13):
>> yasu@rolling-vm-freebsd5[1005]% uname -a
>> FreeBSD rolling-vm-freebsd5.home.utahime.org 13.0-ALPHA3 FreeBSD 13.0-ALPHA3 
>> #0 stable/13-c256214-g40cb0344eb2: Mon Feb  1 11:30:28 JST 2021 
>> ro...@rolling-vm-freebsd5.home.utahime.org:/usr0/freebsd/src/obj/usr0/freebsd/src/git/amd64.amd64/sys/GENERIC
>>   amd64
> 
> I submitted this problem to Bugzilla.
> 
> Bug 253147 - Setting for displaying utf8 characters on all vt consoles
> results in panic on 14-CURRENT and 13.0-ALPHA3
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253147 
> 
> 
> ---
> Yasuhiro Kimura

Should be fixed on current now.

thanks,
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: vidcontrol < /dev/console -i active ioctl error

[Toomas Soome via freebsd-current]

> On 28. Jan 2021, at 01:35, Jesper Schmitz Mouridsen  wrote:
> 
> FreeBSD build.freebsd.lan 13.0-ALPHA1 FreeBSD 13.0-ALPHA1 #0 
> main-c255938-g7ae27c2d6c4: Thu Jan 14 06:29:55 UTC 2021 
> r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
> jesper@build:~ $ su
> Password:
> root@build:~ # vidcontrol < /dev/console -i active
> vidcontrol: getting active vty: Inappropriate ioctl for device
> 
> build is virtualized in bhyve, it happens as well on my pinebook pro.
> 
> This is annoying to sysutils/consolekit2
> 
> on 12.2 it works (not tested on same HW)
> 

it should work for local console:

root@freebsd:/usr/src # vidcontrol -i active < /dev/console
1

may it be your “primary” is actually serial console?

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: DRM and Radeon

[Toomas Soome via freebsd-current]

> On 26. Jan 2021, at 10:18, Marek Zarychta  
> wrote:
> 
> W dniu 26.01.2021 o 08:58, Graham Perrin pisze:
>> On 26/01/2021 07:02, Alexey Dokuchaev wrote:
>> > Re: loading drm crashes system
>> > … There are known issues with Radeon cards, they were quite well
>> > supported a year ago, then something got broken. I've promised to
>> > bisect this and find the cause, but there were several
>> > syscall-related changes in -CURRENT though the course of the last
>> > year, so bisecting just the kernel is not enough (machine won't get
>> > to login prompt if the userland does not match), which cripples the
>> > process.
>> >
>> > I still intend to take this quest, just not sure when. :(
>> >
>> > ./danfe
>> Any cards in particular?
>> 
>>  – whilst I didn't mention Radeon there, for me it _was_ the Radeon story 
>> that seemed to improve a few months ago.
>>  AMD Thames [Radeon 
>> HD 7550M/7570M/7650M]
> 
> 
> 
> For example old RS880 [Radeon HD 4200]. After deprecation of 
> graphics/drm-fbsd12.0-kmod I found that it is still supported fine on 
> 12-STABLE with legacy /boot/kernel/radeonkms.ko from the base. While trying 
> the driver from graphics/drm-fbsd12.0-kmod I was not able to use this card 
> with gdm, only startx or x11/slim worked. On 13-ALPHA this card still works 
> fine with deprecated graphics/drm-legacy-kmod.
> 
> 

Does gdm start X in specific way? I mean, afaik, gdm is X11 client as any 
other, so the question would be, how does gdm get Xorg started, what is 
different compared to startx etc? Might it be about gdm user permissions to 
access drm devices?

my 2cents..
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: ZFS feature compatibility?

[Toomas Soome via freebsd-current]

> On 26. Jan 2021, at 00:23, John Kennedy  wrote:
> 
>> Thanks, I am new to the EFI world.  Does the name now have to be
>> BOOTx64.efi ?
>> 
>> root@zoo2:/boot # ls -l /mnt/EFI/freebsd/
>> total 824
>> -rwxr-xr-x  1 root  wheel  843776 Nov 21 10:50 loader.efi
>> root@zoo2:/boot #
> 


if there is no UEFI bootmanager configured (see man efibootmgr), then (ESP) 
efi/boot/bootx64.efi is default. with efibootmgr(8), you can configure custom 
path, such as (ESP) efi/freebsd/loader.efi

rgds,
toomas



>  I don't know.  This came out of an email thread I had a while ago:
> 
>   Date: Thu, 9 Jul 2020 14:18:54 -0700
>   From: John Kennedy 
>   To: Kyle Evans 
>   Cc: FreeBSD-STABLE Mailing List 
>   Subject: Re: 12.1p7 no longer boots after doing zpool upgrade -a
> 
>  The "new" documentation was here:
> 
>   https://wiki.freebsd.org/UEFI
> 
>  The older stuff is still mentioned here:
> 
>   https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot
> 
> ___
> 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: ZFS feature compatibility?

[Toomas Soome via freebsd-current]

> On 25. Jan 2021, at 23:08, Allan Jude  wrote:
> 
> On 2021-01-25 16:03, Toomas Soome via freebsd-current wrote:
>> 
>> 
>>> On 25. Jan 2021, at 22:15, mike tancsa  wrote:
>>> 
>>> On 1/25/2021 2:37 PM, Toomas Soome via freebsd-current wrote:
>>>> 
>>>>> On 25. Jan 2021, at 21:31, Michael Butler via freebsd-current 
>>>>>  wrote:
>>>>> 
>>>>> I have a few machines on which I've been hesitant to run 'zpool upgrade' 
>>>>> as I'm not sure of the (boot?) implications. They report like this ..
>>>>> 
>>>>> imb@toshi:/home/imb> uname -a
>>>>> FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD 
>>>>> 14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021 
>>>>> r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI
>>>>>  amd64
>>>>> 
>>>>> imb@toshi:/home/imb> zpool status
>>>>> pool: zroot
>>>>> state: ONLINE
>>>>> status: Some supported 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.
>>>>> 
>>>>> Is it safe to upgrade the root pool?
>>>>> 
>>>>>   imb
>>>> We can not boot from encrypted pool and draid. Rest is all ok. Please 
>>>> note, you may need to update the bootblocks.
>>>> 
>>> last Friday on zoo.freebsd.org <http://zoo.freebsd.org/> 
>>> <http://zoo.freebsd.org/ <http://zoo.freebsd.org/>>, m...@freebsd.org 
>>> <mailto:m...@freebsd.org> <mailto:m...@freebsd.org 
>>> <mailto:m...@freebsd.org>> and I could not boot
>>> again because v2 bookmarks were on the boot pool.  I had to boot from
>>> another disk, remove the bookmarks and then boot. This was on RELENG_13
>>> (stable/13-c256203-g51d73a3e46c)
>>> 
>>>—Mike
>> 
>> /*
>> * List of ZFS features supported for read
>> */
>> static const char *features_for_read[] = {
>>"org.illumos:lz4_compress",
>>"com.delphix:hole_birth",
>>"com.delphix:extensible_dataset",
>>"com.delphix:embedded_data",
>>"org.open-zfs:large_blocks",
>>"org.illumos:sha512",
>>"org.illumos:skein",
>>"org.zfsonlinux:large_dnode",
>>"com.joyent:multi_vdev_crash_dump",
>>"com.delphix:spacemap_histogram",
>>"com.delphix:zpool_checkpoint",
>>"com.delphix:spacemap_v2",
>>"com.datto:encryption",
>>"com.datto:bookmark_v2",
>>"org.zfsonlinux:allocation_classes",
>>"com.datto:resilver_defer",
>>"com.delphix:device_removal",
>>"com.delphix:obsolete_counts",
>>"com.intel:allocation_classes",
>>"org.freebsd:zstd_compress",
>>"com.delphix:bookmark_written",
>>NULL
>> };
>> 
>> Are you sure you have bootblocks updated? ESP for UEFI boot and freebsd-boot 
>> for BIOS boot.
>> 
>> rgds,
>> toomas
>> ___
>> freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current 
>> <https://lists.freebsd.org/mailman/listinfo/freebsd-current>
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org 
>> <mailto:freebsd-current-unsubscr...@freebsd.org>"
>> 
> 
> Toomas: how difficult do we think it would be to make a ports version of
> the updated boot code, especially for the case of people using the
> openzfs-kmod on 12.2?
> 
> 

zstd would be interesting…  

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: ZFS feature compatibility?

[Toomas Soome via freebsd-current]

> On 25. Jan 2021, at 22:15, mike tancsa  wrote:
> 
> On 1/25/2021 2:37 PM, Toomas Soome via freebsd-current wrote:
>> 
>>> On 25. Jan 2021, at 21:31, Michael Butler via freebsd-current 
>>>  wrote:
>>> 
>>> I have a few machines on which I've been hesitant to run 'zpool upgrade' as 
>>> I'm not sure of the (boot?) implications. They report like this ..
>>> 
>>> imb@toshi:/home/imb> uname -a
>>> FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD 
>>> 14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021 
>>> r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI
>>>  amd64
>>> 
>>> imb@toshi:/home/imb> zpool status
>>> pool: zroot
>>> state: ONLINE
>>> status: Some supported 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.
>>> 
>>> Is it safe to upgrade the root pool?
>>> 
>>> imb
>> We can not boot from encrypted pool and draid. Rest is all ok. Please note, 
>> you may need to update the bootblocks.
>> 
> last Friday on zoo.freebsd.org <http://zoo.freebsd.org/>, m...@freebsd.org 
> <mailto:m...@freebsd.org> and I could not boot
> again because v2 bookmarks were on the boot pool.  I had to boot from
> another disk, remove the bookmarks and then boot. This was on RELENG_13
> (stable/13-c256203-g51d73a3e46c)
> 
> —Mike

/*
 * List of ZFS features supported for read
 */
static const char *features_for_read[] = {
"org.illumos:lz4_compress",
"com.delphix:hole_birth",
"com.delphix:extensible_dataset",
"com.delphix:embedded_data",
"org.open-zfs:large_blocks",
"org.illumos:sha512",
"org.illumos:skein",
"org.zfsonlinux:large_dnode",
"com.joyent:multi_vdev_crash_dump",
"com.delphix:spacemap_histogram",
"com.delphix:zpool_checkpoint",
"com.delphix:spacemap_v2",
"com.datto:encryption",
"com.datto:bookmark_v2",
"org.zfsonlinux:allocation_classes",
"com.datto:resilver_defer",
"com.delphix:device_removal",
"com.delphix:obsolete_counts",
"com.intel:allocation_classes",
"org.freebsd:zstd_compress",
"com.delphix:bookmark_written",
NULL
};

Are you sure you have bootblocks updated? ESP for UEFI boot and freebsd-boot 
for BIOS boot.

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: ZFS feature compatibility?

[Toomas Soome via freebsd-current]

> On 25. Jan 2021, at 21:31, Michael Butler via freebsd-current 
>  wrote:
> 
> I have a few machines on which I've been hesitant to run 'zpool upgrade' as 
> I'm not sure of the (boot?) implications. They report like this ..
> 
> imb@toshi:/home/imb> uname -a
> FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD 14.0-CURRENT 
> #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021 
> r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI
>   amd64
> 
> imb@toshi:/home/imb> zpool status
>  pool: zroot
> state: ONLINE
> status: Some supported 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.
> 
> Is it safe to upgrade the root pool?
> 
>   imb

We can not boot from encrypted pool and draid. Rest is all ok. Please note, you 
may need to update the bootblocks.

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"