FreeBSD upgrade with beadm

H

hukadan

Guest
Hello,

I am in the process of learning to use zfs(8) and sysutils/beadm. I recently tried to use sysutils/beadm to upgrade my server from 10.1-RELEASE to 10.2-RELEASE following this post. So I went through the first steps :

Code: 
# beadm create 10.2-RELEASE
# beadm mount 10.2-RELEASE /mnt
# mount -t devfs devfs /mnt/dev
# chroot /mnt /bin/sh
# freebsd-update -r 10.2-RELEASE upgrade
# freebsd-update install

My question is related to the end of the procedure. In a normal upgrade, I would reboot the server and run freebsd-update install again. From the handbook :
freebsd-update will not start from the beginning, but will instead move on to the next phase and remove all old shared libraries and object files.
Click to expand...
My understanding of this last step (this is the weak point of my reasoning) is that some programs are still using the old libraries and therefore a reboot is needed so that those programs switch to new ones, the older ones being taking care off with the last freebsd-update install.

Now, using sysutils/beadm and a chroot(8), these old libraries are not in use. So I thought it could be possible to run twice the freebsd-update install, then activate the new boot environment and reboot without no further step needed (for the base system). I tried this last solution with a test server and it seems to have worked but I was wondering if I just got lucky or if this way of doing things made sense.
 
Rather strange usage of beadm for me. If you have proper datasets layout, you can upgrade the system straight, without chroot after you created snapshot. If something goes wrong, just reboot to 10.2-RELEASE back. I upgrade my system like that and it's pretty safe operation.
 
abishai said:
Rather strange usage of beadm for me. If you have proper datasets layout, you can upgrade the system straight, without chroot after you created snapshot. If something goes wrong, just reboot to 10.2-RELEASE back. I upgrade my system like that and it's pretty safe operation.
Click to expand...

Well, I do not see the advantage of using beadm(1) in that case (but is does not mean that there is none). A simple rollback in case of failure should be enough. By the way, this point as already been discussed on twitter. One of the advantage cited is less down time, the main drawback being added complexity. To be complete, in the excellent Thread howto-freebsd-zfs-madness.31662, it is proposed to use a jail to upgrade the system.

In my case, downtime is not a problem. I am not an IT expert (you have guessed from the first post I suppose) but I run a personal server (mostly for learning purposes) on which is a forum for a gaming community. Most of the traffic on the forum is between 7pm and 11pm so I do not want to update during this period and make the server unavailable. If I proceed as you propose, I have to start the process around 11:30pm and it can sometimes be long (and I have to go to work the next day ;) ). Using the procedure above, I could prepare everything during the rush hour (rush is 30 users at the same time so the server is far from busy... and no, I did not forget two or three zeros) and then reboot at 11:30pm.

KdeBruin said:
I just did the same myself. See this link https://dan.langille.org/2015/03/13...-freebsd-10-1-using-beadm-and-freebsd-update/ for more information on how to proceed.
Click to expand...

Thank you for the link... but that the one I gave on my first post ;). If you look at the last part of the post, there is a warning about the risk of forgetting to complete the upgrade. As you can see from my use case above, there is enough time for me to forget to run the last freebsd-update install between the first part of the upgrade procedure and the last part (after reboot). If I see a reason to reboot before issuing the last freebsd-update install in the case of a normal upgrade procedure, I fail to see the point of rebooting in the case described above. Just because command lines explain better, here is my question in shell :

Using normal upgrade :
Code: 
# freebsd-update -r 10.2-RELEASE upgrade
# freebsd-update install
# reboot
# freebsd-update install

The method proposed in the post :
Code: 
# beadm create 10.2-RELEASE
# beadm mount 10.2-RELEASE /mnt
# mount -t devfs devfs /mnt/dev
# chroot /mnt /bin/sh
# freebsd-update -r 10.2-RELEASE upgrade
# freebsd-update install
^D (exit of chroot)
# umount /mnt/dev
# beadm umount 10.2-RELEASE
# beadm activate 10.2-RELEASE
# reboot
# freebsd-update install (the one I can forget)

The method I thought would also work :
Code: 
# beadm create 10.2-RELEASE
# beadm mount 10.2-RELEASE /mnt
# mount -t devfs devfs /mnt/dev
# chroot /mnt /bin/sh
# freebsd-update -r 10.2-RELEASE upgrade
# freebsd-update install
# freebsd-update install (placed here, I should not forget)
^D (exit of chroot)
# umount /mnt/dev
# beadm umount 10.2-RELEASE
# beadm activate 10.2-RELEASE
# reboot

But thanks to your questions, I realized that my problem is not quite related to beadm(8) afterall. I think that I have to make my mind clear about what the last freebsd-update install is doing exactly (what I have in mind at the moment is what is written on my first post).
 
Hmm, interesting. It would be great if upgrades could be done this easily.

The handbook says the same as you, that the second run removes old libraries and object files, which is done once you have booted into the new kernel. If you're in a separate environment and not touching any files actually in use by the system, I can't see why this couldn't be done without a reboot. I don't see any reason why freebsd-update would specifically need the new kernel running - I don't think it talks to the kernel in any way, it just adds/updates/removes files?

Would be good to have some confirmation though. This seems like a really slick way of doing the upgrade.
 
You must log in or register to reply here.
Back
Top