-
Website
http://www.daemonology.net/blog/ -
Original page
http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html -
Subscribe
All Comments -
Community
-
Top Commenters
-
Marton Trencseni
3 comments · 1 points
-
Ralph Corderoy
4 comments · 1 points
-
da44en
2 comments · 1 points
-
Jason Dusek
2 comments · 1 points
-
royce
9 comments · 1 points
-
-
Popular Threads
-
Supporting FreeBSD
3 weeks ago · 1 comment
-
Supporting FreeBSD
So, if I'm starting from ground zero (fresh) with Sunday's AMD-x64 .iso on a wholly dedicated 80GB harddrive....there should be minimal additional hoops to jump thru, such as above. ...yes? :-)
I'd had smooth working FreeBSD systems over the past couple of years and touted the features and ease of operation/install to others. I underwent a major change in locale a year ago and just (now) coming back to FreeBSD. It's not as I recalled. Several of the 7-Betas did not work as expected. With additional duties surrounding my job....I've lagged in keeping up. I realize 99% of the problems are right in front of the keyboard!
I'll let 8-BETA1 download overnight as internet is not the quickest from the part of the world. I will also update my FreeBSD Handbook.
Best Regards from South Asia,
Mike
Negombo, Sri Lanka
How upgrade system with custom kernel?
The usual upgrade path is to install the new kernel, reboot, then install world. This fails because when rebooting into the 8.0 kernel with 7.2 userland, ZFS is unable to properly initialise and the file systems are not mounted. In our case we are booting with a small UFS partition to load the kernel, and then mounting /usr /var, etc from ZFS as per these instructions [1].
The problem with ZFS userland being out of sync with the kernel has been seen before [2] [3]. However now with lots of people running ZFS and starting to upgrade to 8.0, I think this will bite many more.
The workaround is to drop into single user mode, mount all the zfs partitions, and do the userland install.
mount -t zfs /usr
mount -t zfs /var
mount -o rw tank/root /
Those mount commands are slightly non-obvious and took a little guessing to get right. You can't use the 'zfs mount' command since it is broken at this point in time.
The other solution is to install userland BEFORE you reboot into the new kernel, although that may cause its own set of problems. Whatever the final solution, this needs to be clearly documented and ideally freebsd-update needs to detect the problem and advise the user about what to do.
Ari Maniatis
[1] http://www.ish.com.au/solutions/articles/freebs...
[2] http://www.nabble.com/Re%3A-ZFS-MFC-heads-up-p2...
[3] http://www.nabble.com/zfs-version-13-kernel-and...
The solution is portupgrade's '-c' or '--config' option. It makes portupgrade ask you all of the config dialogs at the *beginning* of the portupgrade run. Much preferable.
So I recommend:
portupgrade -afc
Enjoy!
I've used freebsd-update several times to upgrade systems quite successfully.
At the moment, I have 7.0-STABLE installed on a small server. I would like to upgrade it to 8.0-RC2.
To start with, I've updated all my ports with portupgrade.
However when I run freebsd-update the first time, I get error messages:
$ sudo freebsd-update -r 8.0-BETA1 upgrade
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 7.0-STABLE from update5.FreeBSD.org... failed.
Fetching metadata signature for 7.0-STABLE from update4.FreeBSD.org... failed.
Fetching metadata signature for 7.0-STABLE from update2.FreeBSD.org... failed.
No mirrors remaining, giving up.
I've googled this, and found various hits, but the problem and solution still aren't clear to me.
Thanks.
You'll have to upgrade to a RELEASE via buildworld/buildkernel/installkernel/installworld before you can use FreeBSD Update to update your system.
Can I suggest that freebsd-update detect this condition and either:
1. install a loader with the broadest possible support (no one will complain will they?)
2. warn the user they are about to shoot themselves in the foot very painfully.
(1) would be much nicer.
Thanks for a great tool.
Ari
ipfw: size mismatch (have 64 want 68)
ipfw: size mismatch (have 44 want 48)
One workaround is to set firewall_enable="NO" before rebooting. Otherwise, be prepared to grab console.