Upgrade with only one reboot

[BaronBS]

Hello forum, good afternoon.

I want to minimize the number of reboots required during the upgrade process by src.
I'm running Stable and the current upgrade process that I do it is this:

doas git -C /usr/src pull
cd /usr/src
doas make clean
doas make -j8 buildworld buildkernel
doas make installkernel
doas shutdown -r now
doas etcupdate -p
cd /usr/src
doas make installworld
doas etcupdate -B
doas make check-old
doas make delete-old
doas make check-old-libs
doas make delete-old-libs
doas shutdown -r now

Is there a way to upgrade the system with only one reboot?
Some like mounting a BE, upgrade it inside of a chroot/jail and only reboot when the whole process is done and it is time to test it.
Is something like this possible?

Ps.: I tried pkgbase and I didn't liked.

 

[SirDice]

Is there a way to upgrade the system with only one reboot?

Sure, just don't reboot after installkernel. I never do. Not the safest option of course. Definitely make sure to read /usr/src/UPGRADING.

 

[BaronBS]

Not the safest option of course.

There is a Brazilian say for this type of situation:
Something wrong is not right.
IDK if I like this approach.
I'm thinking in something like this:

doas bectl create new
doas bectl mount new /mnt
doas chroot /mnt /bin/sh
(chroot) cd /usr/src
(chroot) make build.....
(chroot) make installkernel
(chroot) exit
doas chroot /mnt /bin/sh
(chroot) etcupdate -p
(chroot) make installword
(chroot) ....
(chroot) exit
doas bectl activate -t new
doas shutdown -r now

Is this possible? if so, is it safer then your approach?

 

[gotnull]

Here is a thread about it but using freebsd-update, I don't know if it can help:

B

Thread 'Adventures in upgrading boot environments'

Sep 18, 2020

I've been struggling for a while now to find the proper upgrade procedure when using boot environments and freebsd-upgrade with the -b and -d flags (i.e. upgrading without rebooting into the new BE first). I thought I had found something that works but was proven wrong when our primary storage server failed to boot earlier this week.

There are two scenarios I've found that are pretty easy to get yourself in to when upgrading boot environments this way:

1. A mismatch in kernel and kernel modules. This is what happened to us this week. I believe the kernel had been upgraded to...

• Bren
• Replies: 7
• Forum: Installing and Upgrading FreeBSD

• 

 

[BaronBS]

Here is a thread about it but using freebsd-update, I don't know if it can help:

B

Thread 'Adventures in upgrading boot environments'

Sep 18, 2020

I've been struggling for a while now to find the proper upgrade procedure when using boot environments and freebsd-upgrade with the -b and -d flags (i.e. upgrading without rebooting into the new BE first). I thought I had found something that works but was proven wrong when our primary storage server failed to boot earlier this week.

There are two scenarios I've found that are pretty easy to get yourself in to when upgrading boot environments this way:

1. A mismatch in kernel and kernel modules. This is what happened to us this week. I believe the kernel had been upgraded to...

• Bren
• Replies: 7
• Forum: Installing and Upgrading FreeBSD

• 

Thanks, but:

I'm running Stable

 

[cracauer@]

For minor updates I don't reboot at all unless I know the kernel has a change that I want.

 

[Andriy]

Is there a way to upgrade the system with only one reboot?
Some like mounting a BE, upgrade it inside of a chroot/jail and only reboot when the whole process is done and it is time to test it.
Is something like this possible?

Not only possible, that's exactly how people using ZFS BEs do it.

 

[monwarez]

There is a Brazilian say for this type of situation:
Something wrong is not right.
IDK if I like this approach.
I'm thinking in something like this:

doas bectl create new
doas bectl mount new /mnt
doas chroot /mnt /bin/sh
(chroot) cd /usr/src
(chroot) make build.....
(chroot) make installkernel
(chroot) exit
doas chroot /mnt /bin/sh
(chroot) etcupdate -p
(chroot) make installword
(chroot) ....
(chroot) exit
doas bectl activate -t new
doas shutdown -r now

Is this possible? if so, is it safer then your approach?

I wonder how this would be safer than just doing what freebsd-update already do: creating a new BE snapshot before doing the upgrade.
If you don't want to reboot at each stage, don't. If something would require a new running kernel, then either using a chroot or not would change nothing.

 

[BaronBS]

I wonder how this would be safer than just doing what freebsd-update already do: creating a new BE snapshot before doing the upgrade.

Some clarification, I didn't ask for a safer approach then the default one, I asked for one with less rebooting. When I asked if my approach would be safer was in comparison with SirDice approach (don't reboot), not the default one.

Not only possible, that's exactly how people using ZFS BEs do it.

Like this?

I'm thinking in something like this:
doas bectl create new doas bectl mount new /mnt doas chroot /mnt /bin/sh (chroot) cd /usr/src (chroot) make build..... (chroot) make installkernel (chroot) exit doas chroot /mnt /bin/sh (chroot) etcupdate -p (chroot) make installword (chroot) .... (chroot) exit doas bectl activate -t new doas shutdown -r now

 

[bakul]

This is what I have been using (probably should check that bectl create succeeds):

#!/bin/sh
cd /usr/src
case .$1 in
.-k) k=installkernel;;
.-w) w=installworld;;
.-n) cmd=echo; k=installkernel; w=installworld;;
.?*) echo "Usage: `basename $0` [-k|-n|-w]"; exit 1;;
.) k=installkernel; w=installworld;;
esac

if [ $(id -u) -ne 0 -a .$cmd = . ] ; then
        echo `basename $0`: Must be run as root; exit 1
fi

case .$k in
.installkernel)
        if mount -t zfs |grep ' / '>/dev/null; then
                date=$(date +%y%m%d)
                if ! (bectl list | grep $date >/dev/null); then
                        echo Creating backup boot env....
                        $cmd bectl create $date
                fi
        fi
        ;;
esac
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin $cmd make KERNCONF=GENERIC $k $w

 

[Andriy]

I wonder how this would be safer than just doing what freebsd-update already do: creating a new BE snapshot before doing the upgrade.
If you don't want to reboot at each stage, don't. If something would require a new running kernel, then either using a chroot or not would change nothing.

Doing things in a chroot helps a lot.
First of all, you can work with it from outside it.
Second, if something breaks in the chroot, your system is still fully functional.
You can fix the chroot using host tools or you can just destroy it, etc.

If you upgrade the running system image directly and something essential breaks mid-upgrade, then you'd have more pain.

 

[mer]

Not only possible, that's exactly how people using ZFS BEs do it.

Yep I'm one of those people.
I typically only do it when going across major releases like 12 to 13, 13 to 14 etc. The rest of the time I let freebsd-update do create the new BE. Going across major releases also gives me the chance to triple check everything like config files and pkg upgrade -f to pick up all the new packages including things like drm-kmod.

monwarez
The biggest difference between the two is that the new BE created by freebsd-update represents the system BEFORE the upgrade.
Manually creating a new BE and chroot into it represents the system AFTER the upgrade.

 

[BaronBS]

So, vermaden gave me the insight I wanted:

Because of ZFS Boot Environments that will make your life very peaceful - You will never again have to worry about upgrades - https://is.gd/BECTL - more here.

First, a interest fact that I didn't know before:
What I'm looking for is basic the Illumos approach for the upgrade process:

There is a example in this presentation on how to replicate Illumos behavior in FreeBSD:

But, since I'm running stable I don't think this is it.

Maybe a BE-Jail is what I need:

Can I upgrade the BE inside of a Jail and then reboot into this BE? What you guys think?

 

[mer]

Jails? I don't know.
The emulate Solaris/Illumos is basically the create new BE, mount it and use it as the base of a chroot. freebsd-update and the pkg command have options to do chroot.

 

[BaronBS]

Jails? I don't know.
The emulate Solaris/Illumos is basically the create new BE, mount it and use it as the base of a chroot. freebsd-update and the pkg command have options to do chroot.

I want to upgrade from src, not freebsd-update. Since I'm running Stable.

 

[T-Aoki]

For minor updates I don't reboot at all unless I know the kernel has a change that I want.

Would be OK, usually. But if updated libc.so (with same major version) or something want the updated kernel, we need to reboot.

On the other hand, not sure on what release (maybe upgrading 11 to 12 or before, as if I recall correctly, it was not at switching from ZFS on FreeBSD to OpenZFS), I was forced to roll back on reboot after installkernel to previous state, because:

• /sbin/zfs wants old libc.so before etcupdate -p and make installworld to work
• old libc hesitated to work on new kernel

thus, cannot zfs mount -a for installworld.

This was solved by redoing make installkernel (/usr/obj was/still is a dedicated dataset and didn't rolled back), install /sbin/zfs and /sbin/zpool on /usr/src/cddl/sbin/zfs and on /usr/src/cddl/sbin/zfs respectively before reboot. If I recall correctly, required libraries were pulled in, too.
If no one others are working on the same computer, etcupdate -p and following make installworld would be safe.

 

[cracauer@]

Would be OK, usually. But if updated libc.so (with same major version) or something want the updated kernel, we need to reboot.

No, I think libc changes are picked up fine without a reboot.

This is, BTW, another nail in the coffin for Linux. You can't pick up systemd changes without reboot. Granted, you can't pick up FreeBSD init(8) changes without reboot either, but init has almost no functionality that would change.

 

[mer]

I want to upgrade from src, not freebsd-update. Since I'm running Stable.

If the make installkernel/installworld lets you specify a destination in a config file, then I think you could manually create a new BE, do the buildkernel/buildworld steps then let the install steps do their thing into the alternate location. I'm assuming building from ports would need a similar step.
It's been a while since I've updated from source so I don't know if the process has the needed knobs.

 

[vermaden]

So, vermaden gave me the insight I wanted:


First, a interest fact that I didn't know before:
What I'm looking for is basic the Illumos approach for the upgrade process:

View attachment 21549

There is a example in this presentation on how to replicate Illumos behavior in FreeBSD:
View attachment 21550

But, since I'm running stable I don't think this is it.

Maybe a BE-Jail is what I need:
View attachment 21551

Can I upgrade the BE inside of a Jail and then reboot into this BE? What you guys think?

That presentation is from 2018 - I upgraded beadm(8) a little since then - especially the chroot and reroot (do not confuse with reboot) options are useful.

For example I now use only chroot instead of jail/unjail options.

When I do upgrades with FreeBSD its usually these:

- https://vermaden.wordpress.com/2021/02/23/upgrade-freebsd-with-zfs-boot-environments/

- https://vermaden.wordpress.com/2021/10/19/other-freebsd-version-in-zfs-boot-environment/

More about reroot here:

- https://vermaden.wordpress.com/2022/03/14/zfs-boot-environments-revolutions/

Regards,
ver