Date: Sun, 7 Mar 2010 15:39:05 +0200 From: Dan Naumov <dan.naumov@gmail.com> To: freebsd-questions@freebsd.org Subject: Re: freebsd-update on a 8.0 rootzfs system Message-ID: <cf9b1ee01003070539i27bd1e6ds46e1eaf0360b4243@mail.gmail.com> In-Reply-To: <cf9b1ee01003070357t5d2d0f00r16a43656d200b54f@mail.gmail.com> References: <cf9b1ee01003070357t5d2d0f00r16a43656d200b54f@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 7, 2010 at 1:57 PM, Dan Naumov <dan.naumov@gmail.com> wrote: > Hello folks > > I have a 8.0 system that uses zfsroot and gptzfsboot. It uses the > GENERIC kernel and the only thing that had to be manually recompiled > is obviously the bootloader, to enable zfs boot support, other then > that, the system is using stock 8.0 binaries. Since fully rebuilding > world and kernel on this system is a 5 hour process, I would very much > like to use freebsd-update and I wanted someone to clarify the > utility's behaviour. If I run freebsd-update on this system, what will > it do when it detects that the bootloader binaries do not match those > of stock 8.0-RELEASE? Will it: > > 1) Ignore the changed/recompiled bootloader files completely, only > updating the binaries whose checksums it can recognize. This behaviour > is alright for updating within 8.0, updating for release errata, but > would cause some problems updating to 8.1 and further, since 8.1 will > have zfs capable bootloader by default and having freebsd-update > always completely ignore a system component that has once been > recompiled sounds a bit silly. > > 2) Happily update the system, overwrite my custom compiled bootloader, > forcing me to manually rebuild the bootloader again before I reboot > the system. This I guess would actually be the desired behaviour OK, I did a testrun of this in a VM environment and #1 is what happens. I tried "freebsd-update IDS" first and that showed that /boot/loader SHA256 does not match what is expected, I then applied the updates, but it ignored my custom /boot/loader anyway and didn't touch it despite the mismatch. Why? My biggest concern is what does this mean going forward, when the eventual time for upgrading to 8.1 and 8.2 comes. 8.1 definately has a changed bootloader. Does the current behaviour mean that when I upgrade to 8.1, it will still refuse to update the bootloader and will refuse to update it forever or will it actually update "whatever is given" to 8.1, which would be the desired behaviour? - Sincerely, Dan Naumov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cf9b1ee01003070539i27bd1e6ds46e1eaf0360b4243>