DISQUS

Daemonic Dispatches: FreeBSD Update to 8.0-BETA1

  • michaelathissell · 5 months ago
    Mr. Percival -

    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
  • cperciva · 5 months ago
    If you're installing a new system, you won't have to do any of the above -- this is just for upgrading existing systems.
  • kegf · 5 months ago
    Please sorry for my english.
    How upgrade system with custom kernel?
  • Ari Maniatis · 5 months ago
    You cannot use this mechanism for updating a custom kernel. You need to compile from source the old fashioned way.
  • Jamie · 2 months ago
    couldn't you simply revert to the generic kernel, perform the update, then revert back to your customised kernel (making appropriate changes due to version changes?
  • cperciva · 2 months ago
    Yes.
  • Ari Maniatis · 5 months ago
    Last night we upgraded one of our servers from 7.2 to 8.0-beta1 using the freebsd-update tool and following the instructions on this blog. I believe this problem will occur even if we had used a source update mechanism.

    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...
  • royce · 3 months ago
    I've often started a portupgrade run, and come back an hour later to see that it's been waiting for me to answer a configuration question. This can be especially frustrating when performing upgrades like this one on a system with many ports.

    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!
  • Colin Brace · 1 month ago
    Hi,

    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.
  • cperciva · 1 month ago
    The problem is that you're running 7.0-STABLE. There is no way for freebsd-update to know where along the 7-STABLE branch you are between 7.0-RELEASE and 7.1-RELEASE, so it can't do things like figuring out what files you've modified locally etc.

    You'll have to upgrade to a RELEASE via buildworld/buildkernel/installkernel/installworld before you can use FreeBSD Update to update your system.
  • Ari Maniatis · 1 month ago
    I'm not sure where else to post issues with freebsd-update, so this seems like the best place for now to get Colin's attention. For users who have compiled a /boot/loader with ZFS support (since they are booting from ZFS), the freebsd-update to RC3 will replace that with a version which does NOT support booting from ZFS. This is very very annoying when the server is in a data centre...

    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
  • Benjamin Lee · 1 month ago
    When upgrading from 7.2-RELEASE, ipfw will be broken after booting into the new kernel. I saw multiple ipfw kernel messages:

    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.
  • B2Pi · 1 month ago
    I upgraded a 7.2-RELEASE system. All went swimmingly, save that my disk devices where changed from daNs1D, where N is the drive number, and D the partition number. All of my devices were on slice 1. This isn't, I'm sure, a freebsd-update issue, but it was definitely a surprise. I may have caught a cold from going barefoot into the cellar where the machine is to fix the fstab file
  • cperciva · 1 month ago
    This is a GEOM issue which seems to bite some people but not others -- I'm not quite sure why.