and INDEX-NEW and compare them, not generate the same list of directories
from INDEX-OLD twice...
Pointy hats to: cperciva & everybody who didn't proofread EN-13:04 enough
at the end of the upgrade process, after warning users to upgrade any
3rd party software (e.g., from the ports tree) which might link to the
libraries being removed.
Prior to this commit, the line
/usr/lib/libc.so|...|/lib/libc.so.7
matched the regex, which -- upgrading from 9.x to 10.x, where libc.so is
a regular file and thus was not part of a line which matched the regex --
resulted in freebsd-update thinking that /usr/lib/libc.so was a shared
library which was being removed as part of the upgrade. This had some
unfortunate consequences.
This will be part of an upcoming Errata Notice.
directories last.
This is generally handled by the fact that the list of filesystem objects
is sorted, but this sorting is broken by code which moves .so files ahead
(so that they're present before any binaries which use them)... that code
also moved .so files ahead of directories, which is a problem for upgrading
to 10.0 where there's a new directory containing new .so files.
Errata Notice Candidate.
forking lots of processes to run echo|cut. In one test this reduced
the CPU time from 980s to 134s and the wallclock time from 806s to
132s.
Submitted by: Oleg Ginzburg
configuration files.
If the current file differs from the canonical version from the old release
only due to differences in the $FreeBSD$ tag (which can happen if the system
was installed from source code, depending on how the src tree was checked out)
then freebsd-update will treat the file as "unmodified" and silently update
it to the "clean" version in the new release.
If the only change being made to a configuration file is in the $FreeBSD$
tag (e.g., for any configuration files which have been modified locally, now
that we're using SVN and the $FreeBSD$ tag changes when a branch is created),
freebsd-update will no longer print the diff and prompt "Does this look
reasonable (y/n)?".
Nagged by: pgollucci
MFC after: 1 month
protocol flaw. [09:15]
Correctly handle failures from unsetenv resulting from a corrupt
environment in rtld-elf. [09:16]
Fix permissions in freebsd-update in order to prevent leakage of
sensitive files. [09:17]
Approved by: so (cperciva)
Security: FreeBSD-SA-09:15.ssl
Security: FreeBSD-SA-09:16.rtld
Security: FreeBSD-SA-09:17.freebsd-udpate
using freebsd-update. This applies to using freebsd-update in "upgrade
mode" and normal freebsd-update on a security branch.
The backup kernel will be written to /boot/kernel.old, if the directory
does not exist, or the directory was created by freebsd-update in a
previous backup. Otherwise freebsd-update will generate a new directory
name for use by the backup. By default symbol files are not backed up
to save diskspace and avoid filling up the root partition.
This feature is fully configurable in the freebsd-update config file,
but defaults to enabled.
MFC after: 1 week (stable/7)
Reviewed by: cperciva
Approved by: re (kib)
non-matching index lines. This fixes a bug where bogus warnings would
be printed file has the wrong file flags AND has been updated by
FreeBSD Update.
Reported by: Royce Williams
version of freebsd-update, but I took it out when I rewrote everything
and added FreeBSD Update to the base system because I didn't think it
was useful. It turns out that quite a few people liked it and wanted
it back.
Requested by: Royce Williams + others
MFC after: 2 weeks
shared libraries.
This fixes a problem which resulted in 6.x->7.x upgrades having the
/usr/lib/libpthread.so -> libthr.so symlink missing; what happened was
that the old libpthread.so symlink pointed to /lib/libpthread.so.2 --
which matched the "/lib/*\.so\.[0-9]+" regex -- but the new symlink
didn't, so FreeBSD Update got confused and deleted the symlink as part
of its "remove old shared libraries" step.
To recreate the symlink (which I understand is necessary for ports like
KDE to build) on a 7.x system which FreeBSD Update upgraded from 6.x:
# ln -s libthr.so /usr/lib/libpthread.so
Reported by: Dmitry RCL Rekman
Help diagnosing bug from: kris
MFC after: 7 days
shared object files which have the same name as currently-installed
shared object files should be reinstalled after binaries are rolled
back. The order for rolling back updates is therefore
1. Install any old shared object files which can be installed without
overwriting a new shared object file.
2. Rollback everything which isn't a shared object or kernel file.
3. Rollback any shared object files which we didn't deal with in (1).
4. Rollback to the old kernel.
Bug reported by: Jan Henrik Sylvester
MFC after: 3 days
upgrading to new releases. Important parts of this code include
* automatically determining which optional components (e.g., src,
info, proflibs) are installed.
* merging changes in files which are modified locally and have
changed between the currently running and new release.
* prompting the user to rebuild all 3rd party software before
deleting old shared libraries.
Yes, this is compatible with "freebsd-update rollback" -- you can
test a new -BETA and roll back to the old release if you don't
like it.
Subject to re@ approval, this will be MFCed before 7.0-BETA3 and
6.3-RC1.
MFC after: 2 days
* When installing updates, make sure that securelevel <= 0. Otherwise
we can't remove the schg flag from files.
* When preparing to download updates, check to see if we already have
them sitting in the /files/ directory. This saves bandwidth if users
run "freebsd-update fetch" more than once without installing updates
in between.
While I'm here, bump the copyright date.
MFC after: 3 days
from EoL minus 6 months to EoL minus 3 months, in order to increase the odds
of there actually being a more recent release to which users can upgrade.
(In particular, for releases which are only supported for 12 months, it's
quite likely that the next release will occur between 6 and 9 months later.)
Discussed with: kensmith
Approved by: re (bmah)
MFC after: 3 days
patching and for rolling back updates, don't copy a file if it has already
been stored. This provides a significant speedup to the "Preparing to
download files" stage of "freebsd-update fetch" if many updates have already
been applied or if a file being updated is linked many times (such as
/rescue/*).
Reported by: Paul Dekkers
MFC after: 1 week
Approved by: re (bmah)
operating with the "-b basedir" option would not correctly update files
which had flags set or were hardlinked.
Submitted by: Karsten Schmidt
Pointy hat to: cperciva
MFC after: 1 week
1. When downloading metadata files, make sure we only download each
file once; without this fix, "freebsd-update fetch" will fail the first
time it is run if there have been no updates yet for the installed
release.
2. If the FOO kernel is installed in /boot/kernel instead of /boot/FOO
and the /boot/FOO directory does not exist, don't try to update
/boot/FOO. This is an issue only where an update involves adding a new
kernel module.
3. When removing files and directories, operate in reverse
lexographical order, in order to ensure that files are removed before
the directory which contains them.
MFC after: 3 days
