Problems updating from 9.2 to 9.3

R

RichardM

Hello, I'm having some problems performing a minor version upgrade using freebsd-update from 9.2 to 9.3. I use ZFS and a custom kernel, and have been patching and recompiling the kernel for 9.2. A copy of GENERIC is kept in /boot/GENERIC.

I have done the following, as per the handbook:

Code: 
freebsd-update -r 9.3-RELEASE upgrade
freebsd-update install
nextboot -k GENERIC
shutdown -r now

The nextboot command gave a warning about ZFS. When I rebooted I got to the loader prompt, presumably related to the nextboot warning.

At the loader prompt, I get 'no valid kernel found'. I can type boot GENERIC, and boot a 9.2 kernel. However, I was expecting freebsd-update to have updated /boot/GENERIC so I then can rerun freebsd-update and complete the upgrade.

Looking though /boot, it appear that GENERIC hasn't been updated, and contains a 9.2 kernel patched to level p4. Similarly /boot/kernel.old contains a kernel patched to level p12. I have been applying patches using freebsd-update, but it looks like the GENERIC kernel hasn't been updated beyond patch level p4.

The updated kernels for 9.3 seem to be in /boot/kernel and /boot/kernel.old1. It looks like /boot/modules has not been updated.

I'm honestly a bit lost as to what has happened here. I thought freebsd-update would have updated GENERIC and the kernel modules, but maybe the patching and custom kernel building has got things mixed up.

Is there any way I can recover this, so that I can run the next freebsd-update install ? All the commands above worked without error - just the warning from nextboot.

Many thanks!
 
I believe the default kernel is no longer /boot/GENERIC *) and the handbook is wrong in this one. It's /boot/kernel now as far as I know. Can you look at what is the value of kernel in /boot/defaults/loader.conf. If it says kernel you probably just have to get rid of /boot/nextboot.conf and the system should boot normally.

The ZFS warning in nextboot(8) comes from the fact that the boot time loader can not write on the ZFS filesystem, something that it can do with UFS. This causes the exact problem you have. If loading or booting the kernel fails the /boot/nextboot.conf never gets deleted because the only thing that could delete it on ZFS is one of the scripts in /etc/rc.d but those can't be run until you have booted succesfully with a kernel.

*) I poked around the SVN repository and it looks like it has been /boot/kernel for quite a while, at least 7.4 defaults to /boot/kernel. I don't understand why the handbook still has those instructions if that's the case...
 
Thanks, that's really helpful. I guess /boot/GENERIC simply hasn't been updated at all by freebsd-update when I've been patching. As I understand it, it's overwritten my custom kernel in /boot/kernel, and also seems to have overwritten /boot/kernel.old1 , but not /boot/kernel.old.

Anyway, I should be able to boot into /boot/kernel now and do the rest of the update, then recompile the kernel. I'll ignore the nextboot step next time! Thanks for your help.
 
I've managed to boot into the new kernel fine now, and run the second freebsd-update install.

However, this command says I need to recompile all ports and rerun the command. I thought the point of a minor version upgrade was that ABIs did not change. Ported software seems to work ok, but do I still have to run portmaster -af ? Do I have to rerun freebsd-update install ?

Thanks.
 
Don't recompile any ports yet. Everything you have now installed should keep working unless you have a port that installs kernel modules, those should be recompiled because the KBI (kernel binary interface) is not so stable as the userland counterpart.
 
My ports worked after the 9.2 => 9.3 update, but I did go ahead and do a global reinstallation. My understanding is the update will preserve 9.2's shared libs that are used by the ports, but if you recompile the system is able to delete the old shared libs. I didn't keep track of how much disk space this cleared (probably not a lot).

If you do decide to update your ports, I suggest a couple of clean up steps:
* pkg autoremove will clean up any packages that you're not using (installed as a dependency)
* pkg query -e '%a = 0' %o provides a list of your installed ports
** this differs from pkg info in that it displays only the things you installed, no dependencies
** sanity check its results one-by-one against what you're currently running, so you're sure everything is there
** when something goes horribly wrong and your ports get blown away, you'll be happy to have this list.

I roughly followed the steps in the portmaster man page, and purged all of my installed ports before rebuilding everything from the list. Note that step 6 is wrong if you're using pkgng. Also portmaster shouldn't be in the list if you've installed it manually.
 
aupanner said:
My ports worked after the 9.2 => 9.3 update, but I did go ahead and do a global reinstallation. My understanding is the update will preserve 9.2's shared libs that are used by the ports, but if you recompile the system is able to delete the old shared libs. I didn't keep track of how much disk space this cleared (probably not a lot).
Click to expand...

You have a misunderstanding of how the base system works. None of the shared libraries in the base system were changed from 9.2 to 9.3, absolutely none of them. If there had been a version change that would have violated the stable ABI requirement. Shared libraries installed by ports are a different matter though, they keep changing all the time when new versions replace the old ones.
 
kpa said:
You have a misunderstanding of how the base system works. None of the shared libraries in the base system were changed from 9.2 to 9.3, absolutely none of them. If there had been a version change that would have violated the stable ABI requirement. Shared libraries installed by ports are a different matter though, they keep changing all the time when new versions replace the old ones.
Click to expand...

That may be the case, however when I upgraded from 9.2 => 9.3 freebsd-update clearly stated:

Completing this upgrade requires removing old shared object files.
Please rebuild all installed 3rd party software (e.g., programs
installed from the ports tree) and then run "freebsd-update install"
again to finish installing updates.
Click to expand...
 
It's not exactly wrong because rebuilding everything doesn't hurt. But it is a time consuming job that usually isn't required. I think it's just there to cover all bases.
 
I found the process to be pretty much as @kpa describes above, with binary compatibility maintained, so that xorg() and nvidia-driver() work fine. However, virtualbox-ose() now causes a kernel panic, as this installs a kernel module, so I'll have to recompile this. The warning from freebsd-update() seems too alarming to me.

I think the process in the handbook could cause an incorrect upgrade, as if someone created /boot/GENERIC, as suggested, and assumed freebsd-update() was updating this kernel, then run nextboot() with GENERIC as suggested, the reboot would be with the old kernel, rather than the new. Do you agree? What is the procedure for suggesting a handbook update?
 
You must log in or register to reply here.
Back
Top