Upgrade 10.1 > 11.0 using freebsd-update fails

F

fwyKKCkQze2z

Hi forum

I am trying to upgrade a FreeBSD 10.1-RELEASE box to 11-RELEASE using freebsd-update. I am following
and/or

Code: 
# ll -d /boot/G*
drwxr-xr-x  2 root  wheel    40K Dec 18 10:02 /boot/GENERIC
# freebsd-update fetch
<snip>
No updates needed to update system to 10.1-RELEASE-p45.

WARNING: FreeBSD 10.1-RELEASE-p45 HAS PASSED ITS END-OF-LIFE DATE.
Any security issues discovered after Sun Jan  1 00:59:59 CET 2017
will not have been corrected.
# freebsd-update install
No updates are available to install.
Run '/usr/sbin/freebsd-update fetch' first.
# freebsd-update upgrade -r 11.0-RELEASE
<snip>
Fetching metadata signature for 11.0-RELEASE from update.FreeBSD.org... done.
Fetching metadata index... done.

The update metadata is correctly signed, but
failed an integrity check.
Cowardly refusing to proceed any further.

Also I noticed that pkg has stopped working. I do not exactly know when that happened but I assume it was after the upgrade from 10.1p?? to 10.1p45.

-----
EDIT 11.1.2017 10:00 UTC+1
To make this clearer: the issue with pkg not working (properly) any more appeared before I event tried to upgrade to 11. It was partly the reason I realised that 10.1 is EOL in the first place.

Also I am running a custom kernel but I kept a copy of GENERIC around and have moved that to /boot/GENERIC before first trying to do the upgrade to 11.
-----

Code: 
# pkg version
/usr/local/lib/libpkg.so.3: Undefined symbol "openat"

I can use pkg-static though.

-----
EDIT 11.1.2017 10:00 UTC+1
Code: 
# pkg-static -v
1.9.4
-----

And I do see error messages when booting, like for example:
Code: 
Shared object "libintl.so.8" not found, required by "bash"

I am not sure if that might be related? But it makes me feel uncomfortable.

I have tried pkg-static upgrade -f pkg as well as pkg-static upgrade -f and similar things.

Basically I do not care too much about pkg not working on 10.1 as long as it will work again on 11, but it seems weird anyway.

Any hint is greatly appreciated.
 
What I normally do is upgrade to the next release in smaller steps
freebsd-update upgrade -r 10.2-RELEASE
For real info see https://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html but here are my 5cent
It does take some time to complete (1/2 an hour) and several reboots.
But, it identifies changes that you made to the system.
For these changes you will be dropped into an editor to manually correct stuff. Be aware, that for most changes you really have to edit because freebsd-update inserts lines with >>>>>> that will break most config files if left untouched.
But it does a good job in getting your system in line with releases.
After that you can bump to next
freebsd-update upgrade -r 10.3-RELEASE
I would use single steps for release increments as long as it's bugging you for manual edits.
 
I see your point in going step by step; but that is quite a bit of work (and reboots, which make me nervous on remote systems). As the documentation [1] states 10.1-RELEASE should be possible to directly upgrade to 11 using freebsd-update I do prefer to try that.

Out of curiosity I issued freebsd-update upgrade -r 10.2-RELEASE though and in fact it does seem to proceed further... So it might really be the way I have to go?

-----
EDIT 11.1.2017 12:45 UTC+1
Hmm - maybe I *do* have to go to 10.2-RELEASE first? https://forums.freebsd.org/threads/56060/page-2#post-332443
-----

[1] https://www.freebsd.org/releases/11.0R/installation.html#upgrade-binary
 
This:
Code: 
The update metadata is correctly signed, but failed an integrity check.
Possibly indicates the files are downloaded but may be corrupt. I would remove everything in /var/db/freebsd-update/; rm -rf /var/db/freebsd-update/*. Then try to run the fetch again; freebsd-update -r 11.0-RELEASE upgrade.
 
SirDice said:
This:
Code: 
The update metadata is correctly signed, but failed an integrity check.
Possibly indicates the files are downloaded but may be corrupt. I would remove everything in /var/db/freebsd-update/; rm -rf /var/db/freebsd-update/*. Then try to run the fetch again; freebsd-update -r 11.0-RELEASE upgrade.
Click to expand...
Thanks; I just tried this. Unfortunately nothing changed in the output/behaviour of freebsd-update.
 
I am making some slow progress. After upgrading to 10.2-RELEASE (which seemed to work?) I could upgrade to 11.0-RELEASE.

Currently I am running on the (unchanged?) GENERIC kernel, it seems. I remembered that I have removed "kernel" from the components freebsd-update touches...

Code: 
Components src world

in /etc/freebsd-update.conf

Could that cause issues? And would freebsd-update not warn me if it was?

When I now try to build my custom kernel (using the same config as before the upgrade), it fails:

Code: 
===> ext2fs (all)
machine -> /usr/src/sys/amd64/include
x86 -> /usr/src/sys/x86/include
ln -sf /usr/obj/usr/src/sys/MYKERNEL/opt_ddb.h opt_ddb.h
ln -sf /usr/obj/usr/src/sys/MYKERNEL/opt_directio.h opt_directio.h
ln -sf /usr/obj/usr/src/sys/MYKERNEL/opt_quota.h opt_quota.h
ln -sf /usr/obj/usr/src/sys/MYKERNEL/opt_suiddir.h opt_suiddir.h
awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p
awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q
awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h
make[4]: don't know how to make ext2_hash.c. Stop

make[4]: stopped in /usr/src/sys/modules/ext2fs
*** Error code 2

Stop.
make[3]: stopped in /usr/src/sys/modules
*** Error code 1

Stop.
make[2]: stopped in /usr/obj/usr/src/sys/MYKERNEL
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src

I was thinking of using something like "WITHOUT_MODULES = ext2fs" in /etc/make.conf since I do not need EXT2. But first I do not know if it will help (or if just another module will fail to build) and second I do not see any reason why the build fails in the first place...
 
I have the exact same problem in exactly the same situation (upgrade from 10.1 to 11). On the other hand upgrade to 10.3 seems to be working...
 
I am making some sort of progress here (maybe as my understanding of the whole thing improves?). I still cannot build a (custom or the GENERIC) kernel because I still do receive the exact same error ("don't know how to make ext2_hash.c."). The pkg error(s) are gone, but the messages about "libintl.so.8" when booting persist.

I aborted buildworld after something more than 10 hours. Mainly because I do not see why the buildworld step should be required (can be due to my ignorance).

What I did by now is download the vanilla 11.0-RELEASE kernel from here: http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/11.0-RELEASE/kernel.txz and unpacked it ( tar xvzf kernel.txz -C /). It ends up in /boot/kernel.

Then I have successfully rebooted to that kernel; uname -a reported 11.0-RELEASE-p1 GENERIC.

After adding "kernel" back to the "Components" in /etc/freebsd-update.conf I re-ran freebsd-update and it claimed that it will upgrade (the kernel) to 11.0-RELEASE-p7. It did change something; but uname -a now reports 11.0-RELEASE-p2 GENERIC (instead of the -p7 I would have expected somehow).

This is the reason I tried to build a GENERIC kernel by issuing

make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/null

as suggested on https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html, section 23.2.3.1. To be honest, I am not sure how I could install that kernel after building it. Would a make installkernel (without any arguments) be the way to go?

As the kernel does not build ("don't know how to make ext2_hash.c.") I never came to try if that helps/has the effect of showing "-p7" then.

Code: 
# uname -a
FreeBSD foo.example.com 11.0-RELEASE-p2 FreeBSD 11.0-RELEASE-p2 #0: Mon Oct 24 06:55:27 UTC 2016     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

I understand that I am doing strange things here, but there also is a lot of contradicting information around. For example https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html states

Code: 
Only the GENERIC kernel can be automatically updated by freebsd-update. If a custom kernel is installed,
it will have to be rebuilt and reinstalled after freebsd-updatefinishes installing the updates. However,
freebsd-update will detect and update the GENERIC kernel if /boot/GENERIC exists, even if it is not the current
running kernel of the system.

which is just not true as far as I can tell. I have run freebsd-update on a (different) system running a custom kernel and having GENERIC in /boot/GENERIC. It did not update/touch /boot/GENERIC but wanted to change /boot/kernel instead (the custom kernel).

As I said, I also do not understand why building world should be necessary. freebsd-update should have (binary) updated world to 11.0-RELEASE by now as well as the sources. I agree that this does (did) not match my custom kernel which was still 10.1. But after I have booted from a vanilla 11.0-RELEASE GENERIC kernel, that mismatch should be history. So sources, world and kernel should all be 11.0-RELEASE by now, as far as I can tell. So building a custom kernel should work, no?

Ah yeah, I also did reinstall all packages using pkg-static upgrade -f.

-----
UPDATE
I have double checked now: the two files ext2_hash.c and ext2_htree.c were missing in /usr/src/sys/fs/ext2fs/ for whatever reason (they are the only files starting with the letter "h" after "ext2_" for example?). I have copied them over from another system now and restarted the kernel build (which will take some time, even if it fails again).

Yes, it is getting worse (in terms of strangeness) it seems. But there is not much to loose any more now, right?
-----
 
Last edited:
About the necessity of buildworld and buildkernel.
Theoretically kernel and userspace programs should be "in tune". But they can't be changed at the same time - unless during a full install. The kernel needs supporting executables to boot correctly (think /sbin). This is the case for doing a buildworld.
In practice, we can be more relaxed. Most executables will still work after a kernel bump.
On the other hand, one should NEVER installworld unless a compatible installkernel.

One important thing to know. Both buildworld and buildkernel are independent of the kernel and world that is currently installed - think of it as cross-compiling. After installkernel and subsequent boot there should be at least enough functionality to run installworld.

My personal recipe to do this:
- download the src package: ie. wget ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/10.3-RELEASE/src.txz:
- unpack in /usr/src: tar -C / src.txz
- perform a make buildworld (handbook chapter 23.6 procedure 23.2 step 1 and 2)
- configure and build your custom kernel (handbook chapter 8.5 procedure 8.1 step 1 and 2)

- take precautions for PLAN-B (snapshots, extra backups, emergency boot device, user announcements etc)
- make a list of installed packages that might need to be reinstalled pkg info | awk '{print$1}' >$securelocation/packages-list

do the actual upgrade

- boot single user
- perform make installkernel (handbook chapter 8.5 procedure 8.1 step 3)
- reboot single user
- make installworld (handbook chapter 23.6 procedure 23.2 step 5 to 11)
- reboot single user
- update/reinstall packages: pkg check --shlibs --all and resolve issues
- reboot multiuser

enjoy the new world, or - - - execute PLAN-B
 
Well, well

After I had the two files ext2_hash.c and ext2_htree.c copied over, building the (GENERIC) kernel from the sources I had downloaded and put into /boot/kernel worked:

Code: 
make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/null

(BTW: this command also directly installs the kernel in /boot/kernel)

I am now running on this (self compiled) GENERIC kernel, uname -a reports -p7 and all seems to be good. I am now waiting for the first freebsd-update automatic binary GENERIC update...
 
You must log in or register to reply here.
Back
Top