# From 12.2 to 13



## mefizto (Apr 14, 2021)

Greetings all,

when transitioning between different versions, is it better to freshly install the new version, or to upgrade the older version?

Or does it not make any difference?

Kindest regards,

M


----------



## zirias@ (Apr 14, 2021)

IMHO, a fresh installation is kind of "windows thinking".


----------



## mefizto (Apr 14, 2021)

Hi Zirias,

thank you for the reply.  Could you please explain the term "windows thinking"?  Did you mean "windows tinting"?

In any event, I do not understand either term.

Kindest regards,

M


----------



## joplass (Apr 14, 2021)

I just went from 12.2-RELEASE to 13.0-RELEASE. My lack of freebsd knowledge got me in some troubles now smooth sailing.


----------



## Alexander88207 (Apr 14, 2021)

mefizto said:


> Hi Zirias,
> 
> thank you for the reply.  Could you please explain the term "windows thinking"?  Did you mean "windows tinting"?
> 
> ...



This means that you don't have to do a new installation when a new major release comes out. Because with Windows it was or is so that one is preferred with a major update or even forced to reinstall Windows, since it often comes to problems after the update.


----------



## richardtoohey2 (Apr 14, 2021)

Don't think there is a 12.3 (yet?).  I _think_ Zirias means "Windows (TM)" thinking i.e. that it is better to re-install a fresh version rather than upgrade, but I've never done that myself (certainly not for newer versions!)  Been more a question of having to buy new hardware to keep up with the RAM requirements of newer versions of Windows, but that is truer of the "richer" desktop environments these days anyway.

I'd go for upgrade BUT if you have a test machine or two try on those.

It's a very fresh release, and a .0 release, so there are likely to be problems.  If you want an easy life - stay on 12.x for now.

Let others bleed on the bleeding edge for a little while.


----------



## CyberCr33p (Apr 14, 2021)

I use dump/restore and a shell script to build new servers. My "image" was first build 10 years ago (if I remember correctly with FreeBSD 8). So this "image" was updated multiple times with minor and major versions of FreeBSD without issues and my installation is almost fresh as a new installation. Now I run FreeBSD 13.0. After major updates and after I rebuild the ports I always run these commands:

`make -DBATCH_DELETE_OLD_FILES delete-old
make -DBATCH_DELETE_OLD_FILES delete-old-libs`


----------



## drhowarddrfine (Apr 14, 2021)

Just do an upgrade. It's easy. I do it every time and have so for almost two decades.


----------



## mefizto (Apr 14, 2021)

Hi Alexander88207, richardtoohey2,

thank you for the explanation of the term, if only Zirais used "W". 

I have used 12.3 since I usually stay on the previous version until XX.1 is out, and by that time, the next minor will be out.  I asked at this time since there are a lot of "upgrade" posts so I though I will get a response what is the advantage, since so far I always re-installed.  I have a script, so the re-installation is rather quick and painless, most of the time takes rebuilding all the ports.  But, I understand they have to be re-built anyway.

Hi CyberCr33p, drhowarddrfine,

Thank you for your replies.

Kindest regards,

M


----------



## scottro (Apr 15, 2021)

I too, am waiting to see what happens with other people, and considering waiting for 13.1. I have laptops that I use for various purposes, and on those it doesn't matter. But my main workstation would be irksome to restore from backup. Also, there is an upgrade of ZFS for 13.x, so if you have ZFS, you would think of upgrading that too.  Though to be honest, I don't think I've ever had problems with a XX.0 release. (Though I don't think we've done one on production servers, but on my workstations, it's gone smoothly.)


----------



## bsduck (Apr 15, 2021)

The only advantage I see in reinstalling from scratch is the speed. Major upgrades are slow and can take a few hours, depending on the sets installed (having /usr/src/ to upgrade typically takes a long time), while a fresh install is a matter of minutes. It may be more convenient to reinstall if you have little configuration and your data on a separate drive. I have the opposite, so I prefer upgrading and I find it reliable, more than most Linux upgrades.

"Windows thinking" - it's better to reinstall because the system gets bloated and slow with time.
"Linux thinking" - it's better to reinstall because upgrades often end up in a broken system so I you will have to reinstall anyway.
"FreeBSD thinking" - do whatever is more convenient to you!


----------



## a6h (Apr 15, 2021)

I have three different procedures:
* On bare metal machine ==>Upgrade
* On VM: backup home, etc and restore ==> Install
* On VM with custom/personal patch/code, i.e. VM as a developing/programming machine ==> Upgrade

On VM, I keep /src /doc /ports on different drive (secondary). Thus when I reinstall, I won't loose fetched/checkout sources.


----------



## a6h (Apr 15, 2021)

mefizto said:


> Did you mean "windows tinting"?


This is how I think of "Windows Thinking", and this is what I was doing in Windows:
New version, something goes wrong, bit-rot (*), or deleting wrong files => fdisk, format, and install it again.

(*) Windows Bit-rot is generally is the consequence of Registry. Contrary to /etc (UNIX) , you just can't delete Registry (NTUSER.dat, etc) and start from scratch


----------



## richardtoohey2 (Apr 15, 2021)

mefizto said:


> I have used 12.3


I'm _fairly_ sure there is no 12.3 - there's an 11.4, and 13.0, and a 12.0, .1, and .2 ... but no .3 (yet).


----------



## scottro (Apr 15, 2021)

That's correct, there's no 12.3 at this time.  You can always check https://freebsd.org, it will show the latest suppoprted branch of each release.


----------



## SirDice (Apr 15, 2021)

mefizto said:


> when transitioning between different versions, is it better to freshly install the new version, or to upgrade the older version?


I have various systems that have been upgraded over time from 9.1 to 9.2 to 9.3 to 10.1, 10.2 etc. all the way up to 12.2. This is usually not a problem. But it does depend on the system, sometimes I take the opportunity of an upgrade to wipe the system and do a fresh new install because I want to set things up differently.


----------



## eternal_noob (Apr 15, 2021)

I did not upgrade my 13.0-RC5 to 13.0-RELEASE but did a fresh new install. For the peace of mind.


----------



## zirias@ (Apr 15, 2021)

eternal_noob said:


> I did not upgrade my 13.0-RC5 to 13.0-RELEASE but did a fresh new install. For the peace of mind.


Uhm. 13.0-RELEASE is exactly the same as 13.0-RC5-p1. Well, except for version strings and one constant


----------



## eternal_noob (Apr 15, 2021)

Yeah, but installing FreeBSD is so much fun.


----------



## rawthey (Apr 15, 2021)

mefizto said:


> I have a script, so the re-installation is rather quick and painless, most of the time takes rebuilding all the ports. But, I understand they have to be re-built anyway.


Unless you need non standard options for your ports you can save a lot of time by installing from packages instead.


----------



## BostonBSD (Apr 15, 2021)

Two things I noticed that are different from 12.2 and 13.0 is the fuse.ko module does not appear to be available in 13.0 [I can still use filesystems in userspace, such as rclone mounts, so perhaps this functionality is built into the kernel now?] and this directive in loader.conf does not appear to have any effect: `kern.vt.fb.default_mode="1024x768"`

Perhaps there is a different way to set the VT driver console resolution....


----------



## scottro (Apr 15, 2021)

The kern.vt.fb.default_mode works for me in /boot/loader.conf.  I use it because the console font size is too small for my aging eyes, so I have it set to 800x600.  As for fusefs, I found it was pulled in by something else, in my case, fusefs-jmtpfs, a package which allows me to connect my Android phone to the computer. I don't recollect every using fuse.ko as opposed to fusefs, but I could easily be wrong.


----------



## BostonBSD (Apr 15, 2021)

scottro said:


> The kern.vt.fb.default_mode works for me in /boot/loader.conf.  I use it because the console font size is too small for my aging eyes, so I have it set to 800x600.  As for fusefs, I found it was pulled in by something else, in my case, fusefs-jmtpfs, a package which allows me to connect my Android phone to the computer. I don't recollect every using fuse.ko as opposed to fusefs, but I could easily be wrong.


I did a kldstat and found fusefs.ko is loaded, maybe fuse.ko is deprecated.  Since I didn't explicitly load fusefs, I wonder where it was loaded from. 

I'll try setting the resolution to 800x600 and see if that works [1024x768 was definitely smaller in 12.2, but I can just eyeball it to a larger resolution if its settable at any resolution].

It is settable to 800x600.  However, I know 1024x768 was definitely smaller text, larger resolution in 12.2, regardless of my ability to prove anything.


----------



## BostonBSD (Apr 15, 2021)

There is something very strange going on with the VT driver in FreeBSD 13.0.

I just compiled a custom kernel with white on blue, as I always do with a fresh install and it didn't actually change the foreground and background colors.

This is the kernel config file:

```
include GENERIC
ident BSDKERNEL

options TERMINAL_NORM_ATTR=(FG_WHITE|BG_BLUE)
options TERMINAL_KERN_ATTR=(FG_YELLOW|BG_BLUE)
```

Everything compiled  and installed like normal, but the actual colors didn't change.
The VT driver is loaded in loader.conf.  I did notice a driver called "efifb" that I have never seen before. From DMESG VT: Replacing driver "efifb" with new "fb".


----------



## SirDice (Apr 15, 2021)

BostonBSD said:


> I did a kldstat and found fusefs.ko is loaded, maybe fuse.ko is deprecated


On 12.x both fuse and fusefs loaded the same fusefs(5) kernel module. The module got renamed with 12.x and the old name (fuse) was removed in 13.0.


----------



## bsduck (Apr 15, 2021)

BostonBSD said:


> I did notice a driver called "efifb" that I have never seen before. From DMESG VT: Replacing driver "efifb" with new "fb".


I already had this on 12.2.
What's new to me is the line before: `WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 14.0.`


----------



## BostonBSD (Apr 15, 2021)

There are new options in loader.conf(5), that affect some of these issues.  

I fixed the terminal resolution, not by changing the resolution, but by changing the font size.  This is a new option in FreeBSD 13.0.

So in loader.conf: `screen.font="8x16"` will reduce the font size and make it appear the same size as VT 1024x768 font size from FreeBSD 12.2.

The default font size in FreeBSD 13.0 is larger than the default from 12.2, but now we have the option to change it.


----------



## mickey (Apr 16, 2021)

BostonBSD said:


> I just compiled a custom kernel with white on blue, as I always do with a fresh install and it didn't actually change the foreground and background colors.
> 
> This is the kernel config file:
> 
> ...


Although both of these options are still documented in vt(4) for FreeBSD 13, they are indeed not working anymore. A message on the freebsd-current mailing list from january suggests that there are now loader tunables to set fore-/background colors, but no mention of those in loader.conf(5).



BostonBSD said:


> The VT driver is loaded in loader.conf.  I did notice a driver called "efifb" that I have never seen before. From DMESG VT: Replacing driver "efifb" with new "fb".


(vt_)efifb is a framebuffer device driver that accesses the graphics hardware through UEFI's graphics output protocol (GOP) without needing a specialized graphics device driver. Once a KMS driver is loaded (like one provided by graphics/drm-kmod) it replaces efifb.


----------



## BostonBSD (Apr 16, 2021)

mickey said:


> Although both of these options are still documented in vt(4) for FreeBSD 13, they are indeed not working anymore. A message on the freebsd-current mailing list from january suggests that there are now loader tunables to set fore-/background colors, but no mention of those in loader.conf(5).
> 
> 
> (vt_)efifb is a framebuffer device driver that accesses the graphics hardware through UEFI's graphics output protocol (GOP) without needing a specialized graphics device driver. Once a KMS driver is loaded (like one provided by graphics/drm-kmod) it replaces efifb.


This explains it.  Hopefully the loader tunable options will show up somewhere.


----------



## BostonBSD (Apr 16, 2021)

The loader tunable options showed up in that message.


```
teken.fg_color="7"
teken.bg_color="4"
```

This will make the background blue and the foreground white [notice that the numbers are not mapped to the same colors as "vidcontrol show" I had to use trial and error {red and blue were swapped}.].


----------



## mickey (Apr 16, 2021)

BostonBSD said:


> This explains it. Hopefully the loader tunable options will show up somewhere.


`grep -E "teken\.[fb]g_color" /usr/src/sys/kern/subr_terminal.c`

```
TUNABLE_INT_FETCH("teken.fg_color", &fg);
        TUNABLE_INT_FETCH("teken.bg_color", &bg);
```
There! Feel free to experiment. 
I am still working through my 12.2 -> 13.0 update queue but once I'm through I sure will have a closer look at those.

On a sidenote: Thanks to vt_vbefb I now got a high(er) resolution console with loadable fonts and fast vt switching using a 1996 graphics card *yay*


----------



## BostonBSD (Apr 16, 2021)

mickey said:


> `grep -E "teken\.[fb]g_color" /usr/src/sys/kern/subr_terminal.c`
> 
> ```
> TUNABLE_INT_FETCH("teken.fg_color", &fg);
> ...


I've noticed a performance boost of about 3-5%, but the most interesting thing about FreeBSD 13.0 is the loader tunable options.

....Oh yeah, these tunable options appear to take effect when the FreeBSD menu appears before booting the kernel.  The kernel VT options didn't take effect until the kms driver was loaded, later in the boot process [of 12.2, i'm not sure but I think that syscons was the default console driver before 13, but now it appears to be vt].


----------



## mickey (Apr 16, 2021)

BostonBSD said:


> ```
> teken.fg_color="7"
> teken.bg_color="4"
> ```
> This will make the background blue and the foreground white [notice that the numbers are not mapped to the same colors as "vidcontrol show" I had to use trial and error {red and blue were swapped}.].


The colors are defined in /usr/src/sys/teken/teken.h and seem to correspond to standard ANSI colors:

```
typedef unsigned char teken_color_t;
#define TC_BLACK        0
#define TC_RED          1
#define TC_GREEN        2
#define TC_BROWN        3
#define TC_BLUE         4
#define TC_MAGENTA      5
#define TC_CYAN         6
#define TC_WHITE        7
#define TC_NCOLORS      8
#define TC_LIGHT        8       /* ORed with the others. */
```

Looking at the code that handles the tunables it seems that it does not quite provide the flexibility of the previous kernel config options:

```
fg = bg = -1;
        TUNABLE_INT_FETCH("teken.fg_color", &fg);
        TUNABLE_INT_FETCH("teken.bg_color", &bg);

        if (fg != -1) {
                default_message.ta_fgcolor = fg;
                kernel_message.ta_fgcolor = fg;
        }
        if (bg != -1) {
                default_message.ta_bgcolor = bg;
                kernel_message.ta_bgcolor = bg;
        }

        if (default_message.ta_bgcolor == TC_WHITE) {
                default_message.ta_bgcolor |= TC_LIGHT;
                kernel_message.ta_bgcolor |= TC_LIGHT;
        }

        if (default_message.ta_bgcolor == TC_BLACK &&
            default_message.ta_fgcolor < TC_NCOLORS)
                kernel_message.ta_fgcolor |= TC_LIGHT;
        teken_set_defattr(&tm->tm_emulator, &default_message);
```
Using TERMINAL_NORM_ATTR and TERMINAL_KERN_ATTR you could set two pairs of fore- and background colors for a total of 4 colors independently. Now you can only set a single fore- and background color, and if the background color happens to be black, then it chooses a lighter version of the foreground color (probably bold) for the kernel messages. My configuration so far has been:

```
options         TERMINAL_NORM_ATTR=(FG_LIGHTGREY|BG_BLACK)
options         TERMINAL_KERN_ATTR=(FG_LIGHTBLUE|BG_BLACK)
```
Which made kernel messages appear in bright blue, whereas normal messages appeared grey. I'm afraid that wont be possible to achieve with the loader tunables anymore.



BostonBSD said:


> ....Oh yeah, these tunable options appear to take effect when the FreeBSD menu appears before booting the kernel.  The kernel VT options didn't take effect until the kms driver was loaded, later in the boot process [of 12.2, i'm not sure but I think that syscons was the default console driver before 13, but now it appears to be vt].


The TERMINAL_(NORM|KERN)_ATTR options worked just the same way in vt(4) as the corresponding SC_KERNEL_CONS_ATTR and SC_NORM_ATTR options in sc(4) did before. They got active as soon as the kernel started booting, but not before that (i.e. in loader). The KMS driver should not have any effect on that and is also loaded much later in the boot process. Some tunable options like _kern.vt.fb.default_mode _however do only work if a KMS driver is present. Not sure when exactly vt(4) became the default console, but it was the default in 12.2 already and has been around since FreeBSD 9.3:

```
HISTORY
     The vt driver first appeared in FreeBSD 9.3.
```


----------



## BostonBSD (Apr 16, 2021)

I remember the splash screen would show up, then the screen would go into text mode, then blank out, then go text mode again after the kms driver was loaded.

If I think about it, I guess these attributes were active before the screen blanked out.

These new tunable options make the splashscreen background color whatever the console background color is, the vt kernel options didn't do that, as I recall.


----------



## mickey (Apr 16, 2021)

BostonBSD said:


> I remember the splash screen would show up, then the screen would go into text mode, then blank out, then go text mode again after the kms driver was loaded.


That's when the KMS driver replaces vt_vga/vt_efifb and optionally switches to a higher resolution mode.



BostonBSD said:


> These new tunable options make the splashscreen background color whatever the console background color is, the vt kernel options didn't do that, as I recall.


Well, looks like someone thought it would be a good idea to have _consistent_ colors during the transition from loader to kernel. YMMV. I generally dislike such restrictions being imposed on me.


----------



## mickey (Apr 16, 2021)

Just tested the loader tunables and put this into my /boot/loader.conf:

```
teken.fg_color="4"
teken.bg_color="0"
```
Unfortunately that makes all text blue on black, in loader before the kernel starts booting, as well as the kernel *and* normal console messages, with the kernel messages just being a lighter shade of blue. Even text on all of the virtual terminals is all blue with this setting. I'm afraid that just doesn't cut it.


----------



## joplass (Apr 17, 2021)

I would like to modify my logo as well but I would like to see shots of what you are guys are working on. Can you good people post some pictures?


----------



## BostonBSD (Apr 17, 2021)

I didn't try to modify the logo nor the splash screen yet, I noticed that there are some newer settings that may allow for it, but I haven't looked into it at all so far.

I modified the color scheme and changed the font size with the loader tunables [previously this would have been done with kernel options at compile time].


```
screen.font="8x16"
teken.fg_color="7"
teken.bg_color="4"
```

So this is what it looks like under the previously stated options [white on blue].

These instructions, from Vermaden, reduce the number of kernel messages during the boot process.


----------



## joplass (Apr 17, 2021)

Pretty cool. I need to get to work.


----------



## grahamperrin@ (Apr 20, 2021)

CyberCr33p said:


> `make -DBATCH_DELETE_OLD_FILES delete-old-libs`



From <https://reviews.freebsd.org/D28062#inline-184455>:



> > … deleting old _libraries_ can cause breakage (if performed carelessly). …





joplass said:


> I would like to modify my logo as well



I'd like circular logos to appear circular, not oval:






						254422 – 16:9 logo for boot_mute
					






					bugs.freebsd.org


----------



## zirias@ (Apr 20, 2021)

If you have a 16:9 display, select a 16:9 mode (with square pixels) for EFI framebuffer. Problem solved.


----------



## grahamperrin@ (Apr 20, 2021)

Zirias said:


> select a 16:9 mode (with square pixels) for EFI framebuffer



How to do those two things?


----------



## zirias@ (Apr 20, 2021)

Find a 16:9 mode supported by your UEFI:








						Solved - Broken boot menu layout since update to 13.0
					

Hello,  Since I updated my laptop from 12.2 to 13.0 using freebsd-update, the boot menu shows a broken layout, displaying "â" characters instead of the frame.    Any idea where the problem comes from?  Thank you.




					forums.freebsd.org
				




The `exec` shouldn't be necessary, giving the mode to `efi_max_resolution` should work just as well.

If you have a machine with a 16:9 panel and UEFI only offers 4:3 modes, IMHO FreeBSD ist the wrong place to complain about it. I don't think it would be a good idea to scale the logo assuming non-square pixels.


----------



## grahamperrin@ (Apr 20, 2021)

Thanks, I might have tried that a few weeks ago. I'll retry. 



Zirias said:


> … If you have a machine with a 16:9 panel …



For real hardware (not virtual machines), I assume that 16:9 is the most commonplace aspect ratio.


----------



## drhowarddrfine (Apr 21, 2021)

grahamperrin said:


> I assume that 16:9 is the most commonplace aspect ratio.


Actually, I read that laptops are going with a taller and less wide ratio nowadays so you might look into that.


----------



## balanga (Apr 21, 2021)

BostonBSD said:


> There are new options in loader.conf(5), that affect some of these issues.
> 
> I fixed the terminal resolution, not by changing the resolution, but by changing the font size.  This is a new option in FreeBSD 13.0.
> 
> ...


What screen font sizes are available?


----------



## mickey (Apr 21, 2021)

balanga said:


> What screen font sizes are available?


Check /boot/fonts


----------



## grahamperrin@ (Apr 21, 2021)

Thanks, 



drhowarddrfine said:


> … you might look into that.



I looked into it a couple of months ago, <https://old.reddit.com/r/AskTechnology/comments/ljtd73/-/>


----------



## zirias@ (Apr 21, 2021)

The thing is still: I don't think it makes sense to just _assume_ non-square pixels (which will result if your panel is 16:9 while your UEFI BIOS only offers modes for 4:3). The complaint about this would be best addressed to the vendor of the hardware/firmware…

On my little notebook with 16:9 display, I found one matching mode in UEFI. Not the native resolution, but at least offering square pixels.


----------

