Upgrade FreeBSD 3.x -> 4.x
Предварительные действия:
- выполните важные для вас Backup's
- установите OpenSSH и удалите SSH 1.2.x с тем чтобы после поднятия
до RELENG_4 перенести ключи от OpenSSH из /usr/local/etc в
/etc/ssh
- сохраните конфигурацию sendmail и не забудьте прочитать /usr/src/UPDATING
об изменения в системе, man make.conf, man rc.conf и документацию по
новой версии sendmail в /usr/src/contrib/sendmail/cf/README и организацию
этого сервиса в /etc/mail ПОСЛЕ upgrade'а до 4.x!
Примечание: я реально поднимал с 3.2/3.4/3.5 до 4-Stable, последний в то
время был 4.2 и вплоть до выхода RELEASE-4.3.
В Демосе ребята сказали что подняли по этому руководству с 3.5 до RELEASE-4.3,
до 4-Stable который в настоящий момент 4.3 у них возникли ошибки, на текущий
момент Июнь 2001, можно поднимать в несколько приемов:
Примечание: Еще раз, поднятие с 3.x до 4-Stable, в
настоящий момент, совершенно железно работает по следующей схеме:
3.x(где x<5) -> 3.5 -> 4.2(RELEASE) -> 4-Stable
это не означает что нельзя сделать:
3.x -> 4.x
лишь следует иметь ввиду, если у вас возникли проблемы, попробуйте в несколько
приемов!
Если 3.2:
- сперва до 3.5-Stable или RELEASE-3.5 (указывайте правильно теги cvsup)
- затем 3.5 -> до RELEASE-4.2 или RELEASE-4.3 (не забывайте про теги)
- ну и последний шаг 4-Stable текущая.
Если 3.5:
- поднятие до RELEASE-4.2 или RELEASE-4.3 (не забывайте про теги)
- ну и последний шаг 4-Stable текущая.
Разумеется после каждого поднятия необходимо собрать систему и ядро, вкатится
в новую систему и продолжить поднятие.
Еще раз, не забывайте что для RELEASE-4.2 и RELEASE-4.3 свои теги, у меня
приведены теги лишь для Stable.
tag=RELENG_4_3_0_RELEASE - соответствует RELEASE-4.3
tag=RELENG_4_2_0_RELEASE - соответствует RELEASE-4.2
tag=RELENG_4 - соответствует текущей 4-Stable
tag=RELENG_3 - соответствует текущей 3-Stable
кроме того можно подняться до заданной Stable с соответствующей датой,
указав ее в вашем supfile.
1. Если вы уже поднимали свою систему с 3.x >= 3.5-Stable, то вам достаточно
поправить "tag" в настройках supfile для системы:
- *default tag=RELENG_3 ( тег для 3.x-Stable )
^
|
V
- *default tag=RELENG_4 ( тег для 4.x-Stable )
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^- актуально для нас.
примеры supfile'ов для SYSTEM SOURCES releng_3 и releng_4:
------------------------ releng3-supfile-all ---------------------------------
#--lavr: releng3-supfile-all for ALL-SRC FreeBSD-RELENG_3
#
# CVSup (CVS Update Protocol) allows you to download the latest CVS
# tree (or any branch of development therefrom) to your system easily
# and efficiently (far more so than with sup, which CVSup is aimed
# at replacing). If you're running CVSup interactively, and are
# currently using an X display server, you should run CVSup as follows
# to keep your CVS tree up-to-date:
#
# cvsup releng3-supfile-all
#
# If not running X, or invoking cvsup from a non-interactive script, then
# run it as follows:
#
# cvsup -g -L 2 releng3-supfile-all
#
# You may wish to change some of the settings in this file to better
# suit your system:
#
#--lavr: base=/var/log/cvs - good place for CVSUP-TREE
#
# base=/usr
# This specifies the root where CVSup will store information
# about the collections you have transferred to your system.
# A setting of "/usr" will generate this information in
# /usr/sup. Even if you are CVSupping a large number of
# collections, you will be hard pressed to generate more than
# ~1MB of data in this directory. You can override the
# "base" setting on the command line with cvsup's "-b base"
# option. This directory must exist in order to run CVSup.
#
# prefix=/usr
# This specifies where to place the requested files. A
# setting of "/usr" will place all of the files requested
# in "/usr/src" (i.e., "/usr/src/eBones" and "/usr/src/secure").
# The prefix directory must exist in order to run CVSup.
#--Russian
#*default host=cvsup.ru.FreeBSD.org - 7 hops - VERY fast / Demos
#*default host=cvsup2.ru.FreeBSD.org - 10 hops - VERY fast / N-NOV
#--USA
#*default host=cvsup2.freebsd.org - 21 hops - fast / burka
#*default host=cvsup3.freebsd.org - 21 hops - fast / mit.edu
#*default host=cvsup4.freebsd.org - 15 hops - fast
#*default host=cvsup5.freebsd.org - 20 hops
#*default host=cvsup6.freebsd.org - 18 hops
#*default host=cvsup8.freebsd.org - 18 hops
#*default host=cvsup11.freebsd.org - 17 hops - very fast UUNET-mirror
#--Canada
#*default host=cvsup.ca.freebsd.org - 17 hops - very fast
#--Europe
#*default host=cvsup.uk.freebsd.org - 15 hops - very fast
#*default host=cvsup2.uk.freebsd.org - 15 hops - very fast
#
#*default host=cvsup.de.freebsd.org - 14 hops - very fast
*default host=cvsup.ru.freebsd.org
*default base=/var/log/cvsup
*default prefix=/usr
*default release=cvs
*default tag=RELENG_3
*default delete use-rel-suffix
src-all
------------------------ end of releng3-supfile-all --------------------------
------------------------ releng4-supfile-all ---------------------------------
# $FreeBSD: src/share/examples/cvsup/stable-supfile,v 1.12.2.6 1999/10/04 17:48:17 ru Exp $
#
# This file contains all of the "CVSup collections" that make up the
# FreeBSD-stable source tree.
#
# CVSup (CVS Update Protocol) allows you to download the latest CVS
# tree (or any branch of development therefrom) to your system easily
# and efficiently (far more so than with sup, which CVSup is aimed
# at replacing). If you're running CVSup interactively, and are
# currently using an X display server, you should run CVSup as follows
# to keep your CVS tree up-to-date:
#
# cvsup stable-supfile
#
# If not running X, or invoking cvsup from a non-interactive script, then
# run it as follows:
#
# cvsup -g -L 2 stable-supfile
#
# You may wish to change some of the settings in this file to better
# suit your system:
#
# host=CHANGE_THIS.FreeBSD.org
# This specifies the server host which will supply the
# file updates. You must change it to one of the CVSup
# mirror sites listed in the FreeBSD Handbook at
# http://www.freebsd.org/handbook/mirrors.html.
# You can override this setting on the command line
# with cvsup's "-h host" option.
#
# base=/usr
# This specifies the root where CVSup will store information
# about the collections you have transferred to your system.
# A setting of "/usr" will generate this information in
# /usr/sup. Even if you are CVSupping a large number of
# collections, you will be hard pressed to generate more than
# ~1MB of data in this directory. You can override the
# "base" setting on the command line with cvsup's "-b base"
# option. This directory must exist in order to run CVSup.
#
# prefix=/usr
# This specifies where to place the requested files. A
# setting of "/usr" will place all of the files requested
# in "/usr/src" (e.g., "/usr/src/bin", "/usr/src/lib").
# The prefix directory must exist in order to run CVSup.
#
###############################################################################
#
# DANGER! WARNING! LOOK OUT! VORSICHT!
#
# If you add any of the ports collections to this file, be sure to
# specify them like this:
#
# ports-all tag=.
#
# If you leave out the "tag=." portion, CVSup will delete all of
# the files in your ports tree. That is because the ports collections
# do not use the same tags as the main part of the FreeBSD source tree.
#
###############################################################################
# Defaults that apply to all the collections
#
# IMPORTANT: Change the next line to use one of the CVSup mirror sites
# listed at http://www.freebsd.org/handbook/mirrors.html.
#*default host=cvsup.ru.FreeBSD.org
*default host=cvsup.ru.FreeBSD.org
*default base=/var/log/cvsup
*default prefix=/usr
#--lavr line for RELENG_4
*default release=cvs tag=RELENG_4
*default delete use-rel-suffix
# If your network link is a T1 or faster, comment out the following line.
*default compress
## Main Source Tree.
#
# The easiest way to get the main source tree is to use the "src-all"
# mega-collection. It includes all of the individual "src-*" collections,
# except the export-restricted collections.
src-all
------------------------ end of releng4-supfile-all --------------------------
Примечание: данное описание составлено на живом поднятии боевого сервера
одного из ISP с версии 3.5-Stable до 4.2-Stable!!!
Важное: если вы собираетесь поднимать боевые сервера со старых версий до
свежих Stable, у вас есть несколько вариантов чтобы проделать это как можно
аккуратнее и безболезнно для системы и работающих сервисов, ну и как следствие
для уменьшения _возможного_ геморроя:
- задайте вопрос в группе fido7.ru.unix.bsd на предмет поднимал ли кто
в последнее время с Версии-X.XX до Версии Y.YY FreeBSD и были с этим проблемы?
- попробуйте найти ответ через http://www.freebsd.org/search/search.html
- попробуйте процедуру upgrade'а через cvsup на свободной рабочей станции,
и у вас есть вполне реальные шансы произвести безболезненный upgrade
воспользовавшись заданием заведомо рабочего tag'а:
скажем вместо:
tag=RELENG_4
- tag=RELENG_4_1_0_RELEASE (FreeBSD-4.1 Release)
- tag=RELENG_4_1_1_RELEASE (FreeBSD-4.1.1 Release)
- tag=RELENG_4_2_0_RELEASE (FreeBSD-4.2 Release)
или скачивания RELENG_4 за конкретную дату, предварительно просмотрев нарекания
на Stable того времени на предмет сборки системы:
http://docs.freebsd.org/mail/ и выбрав maillist обсуждения stable
вы можете скачать версию Stable за конкретную дату, предварительно советую
изучить и прочитать `man cvsup` и http://www.freebsd.org/handbook/cvsup.html
после чего задать в вашем supfile:
tag=RELENG_4
date=[cc]yy.mm.dd.hh.mm.ss
необходимо задать дату строго в указанном формате, 17 или 19 символов.
Для любителей русскоязычной документации, FAQ по cvsup переведенный и
обработанный Сергеем Осокиным можно прочесть по адресу:
http://www.freebsd.org.ru/~osa/cvsup.html
Подобная процедура будет актуальна и для варианта 3.5-Stable -> 4.1-Stable,
а вот с версиями 4.0/4.1-Release возможны ньюансы в отношении сборки модулей
или иные заморочки, будьте осторожны.
- если у вас старая версия системы больше чем 2.2.x но меньше чем 3.5, лучше
поднимите ее до 3.5-Stable, по крайней мере этот вариант проверен.
- вполне логично подстраховаться, те сохранить дерево sources: /usr/src
от 3.x-Stable где-нибудь сбоку на этой машине и/или на другой.
2. Запускаем cvsup для синхронизации system sources до 4.x-Stable.
- на http://unix1.jinr.ru/~lavr можно взять мой скрипт который удобно
использовать для запуска cvsup и затем просмотра log-file в /var/log
3. Перед сборкой новой системы RELENG_4, нам необходимо поправить /etc/make/conf
вот что необходимо строго использовать, остальное закомментарить:
NOPERL=true
NOPROFILE=true
USA_RESIDENT=NO
CFLAGS=-O -pipe
COPTFLAGS=-O -pipe
COMPAT1X=yes
COMPAT20=yes
COMPAT21=yes
COMPAT22=yes
COMPAT3X=yes
4. Производим сборку системы:
-----------------------------------------------------------------------------
Внимание: прочитайте файл /usr/src/UPDATING, потому что по ходу развития,
происходят различные изменения по унификации сборки системы и
ядра, например, переменная KERNEL была заменена на KERNCONF!
-----------------------------------------------------------------------------
- cd /usr/src
- make buildworld (не более и не менее)
5. Теперь нам необходимо на основе собранной системы в /usr/obj/...
собрать и установить новое ядро 4.x-Stable:
-----------------------------------------------------------------------------
Внимание: в зависимости от того на какой RELEASE вы поднимаетесь, проверьте
описание изменений в файле /usr/src/UPDATING, в последних релизах
переменная KERNEL заменена на KERNCONF! А процедура сборки системы
и ядра УНИФИЦИРОВАНА следующим образом:
cd /usr/src
make buildworld [-DNOPERL для 3.x -> 4.x ]
[cd /usr/src/sbin/mknod для 3.x -> 4.x ]
[make install для 3.x -> 4.x ]
[cd /usr/src для 3.x -> 4.x ]
[cd gnu/usr.bin/texinfo/install-info для 3.x -> 4.x ]
[make install для 3.x -> 4.x ]
[cd ../../../.. для 3.x -> 4.x ]
[ldconfig -R /usr/obj/usr/src/lib/libc для 3.x -> 4.x ]
make buildkernel
make installkernel
make installworld [-DNOPERL для 3.x -> 4.x ]
-----------------------------------------------------------------------------
- ldconfig -R /usr/obj/usr/src/lib/libc (поскольку нам понадобится новая
собранная библиотека и config от новой системы)
- cd /sys/i386/conf
- vi GENERIC
или
- vi LINT
- можно взять заготовку ЯДРА с уже имеющейся машины под FreeBSD или
мою как основу для дальнейших изменений под свое железо:
http://unix1.jinr.ru/~lavr/KERNEL3up4
тонкости: закоментарьте в этом ядре pnp, и всю избыточность 4.x-Stable
в сравнении с 3.x-Stable, замените wd -> на ad
- итак у вас получилось ядро KERNEL3up4
без: pnp, acd0, conflicts и избыточных устройств,
wcd0 -(заменили на)-> ata0
bpfilter -> bpf
"isa?" с "atkbdc?" -> "atkbd0" и "psm0"
- cd /usr/src и приступаем к сборке нашего нового минимального ядра 4.x
-----------------------------------------------------------------------------
Внимание: в зависимости от того на какой RELEASE вы поднимаетесь, проверьте
описание изменений в файле /usr/src/UPDATING, в последних релизах
переменная KERNEL заменена на KERNCONF!
-----------------------------------------------------------------------------
- make installkernel KERNEL=KERNEL3up4
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~- ИМЕННО ТАК, советую неопытным
не пытаться собирать ядро на системе с binary от 3.x привычным методом:
(cd /sys/i386/conf; config KERNEL3up4; cd ../../compile/KERNEL3up4;
make depend; make) - без понятия что и как делать у вас ничего не
получится!!!
- имеем ядро от RELENG_4 == /kernel и ядра от RELENG_3: /kernel.xxx
и новые модули к новому ядру
- cd /etc
- cp make.conf make.conf.3
- cp rc.conf rc.conf.3
- cp /usr/src/etc/defaults/make.conf .
- cp /usr/src/etc/defaults/rc.conf .
отредактируйте новые make.conf & rc.conf - уберите все новшевства и
оставьте стандартные переменные касающиеся keyboard & font, hostname,
defaultrouter, network_interface.
примечание: можете оставить make.conf & rc.conf от старой системы, НО
проверьте совпадение сетевого устройства которое было и соответствие
из ВНОВЬ собранного ЯДРА, например:
- в releng_3 осталось исторически ed1;
- в конфигурации нового ядра ed0;
оставьте стандартные переменные совпадающие в RELENG_3 и RELENG_4
6. Соберите новый mknod, старый /sbin/mknod можете скопировать в /sbin/mknod.3
для страховки:
- cd /usr/src/sbin/mknod && make install (имеем новый mknod от RELENG_4)
- cd /dev ; cp MAKEDEV MAKEDEV.3; cp MAKEDEV.local MAKEDEV.local.3
- cp /usr/src/etc/MAKEDEV* /dev
- cd /dev ; sh MAKEDE all
- посмотрите свой /etc/fstab и создайте необходимые вам устройства для
дисков: scsi -> da* и ide -> ad*
например: ./MAKEDEV ad0
затем для slices: ./MAKEDEV ad0s1 и тд и тп.
7. Если у вас имеются IDE диски, отредактируйте ваш /etc/fstab
- все вхождения wdX -(замените на)-> adX
8. Поскольку загрузчик в 4.x изменился:
- cd /sys/boot && make install
9. Теперь перегружаем систему, желательно в single-user mode
(надо признаться что у меня и в multi-user поднялась без видимых проблем)
- shutdown -r now
- boot -s
Примечание: перезагрузка с НОВЫМ ЯДРОМ производится в целях проверки и
последующей установки binaries, подразумеваю что ради этого можно
и не перегружаться, что при этом произойдет можно подразумевать.
- mount -a
- ps -axuw (догадываетесь что покажет...)
- ldconfig -R /usr/obj/usr/src/lib/libc
- cd /usr/src
- make installworld
- cd /usr/src/release/sysinstall && make all install
Система ПОДНЯТА, проверьте вывод ps -axuw и сравните с предыдущим.
- mergemaster (и установите то что не требует изменений, остальное
сохраните в temproot и по завершению поправьте вручную)
- проверьте что нового или настройте:
/etc/syslog.conf - соответственно поправьте /var/log и ошметки от cron'а
touch /var/log/security
touch /var/log/cron
- удалите старый ssh-1.2.x и настройте OpenSSH
- ssh-keygen -f /etc/ssh/ssh_host_key
- ssh-keygen -d -f /etc/ssh/ssh_host_dsa_key
rm /var/cron/log*
10. Соберите необходимое вам _полноценное_ ЯДРО RELENG_4 и настройте
/etc/make.conf & /etc/rc.conf по полной программе
11. Для тех кто хочет иметь IDEA, можно выполнить:
раскомментируйте соответствующую строку в /etc/make.conf и пересоберите
security
12. Перегружаемся - все, процесс upgrade завершен.
13. Пересоберите важные для вас пакеты, совместимость совместимостью, но
от проблем никто не застрахован.
Copyleft Andrey Lavrentyev