![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[3.4 -> 3.5] | [3.5 -> 3.6] | [3.6 -> 3.7] | [3.7 -> 3.8] | [3.8 -> 3.9] | [3.9 -> 4.0] | [4.0 -> 4.1] | [FAQ Index]
Jest niezwykle zalecane abyś przeczytał cały dokument i dokładnie zrozumiał proces zanim będziesz usiłował go przeprowadzić. Jeśli zamierzasz działać na krytycznej lub fizycznie odległej maszynie, jest zalecane abyś przetestował ten proces na identycznej, lokalnej maszynie i zweryfikował szanse na powodzenie zanim przystąpisz do krytycznej lub odległej maszyny.
Upgrade to wygodny sposób na utrzymywanie twojego systemu OpenBSD aktualnym z ostatnią aktualną wersją. Jednakże, rezultat w zamierzeniu nie odpowiada dokładnie wynikowi instalacji wyczyść-i-załaduj. W szczególności stare pliki bibliotek, nie są usuwane w procesie aktualizacji, ponieważ mogą być wymagane przez starsze aplikacje które mogą, lecz nie muszą być zaktualizowane w danym momencie. Jeżeli NAPRAWDĘ chcesz pozbyć się tych wszystkich plików, prawdopodobnie lepiej będzie jeśli zainstalujesz wszystko od początku.
Spis treści:
Oznacza to, że wiele systemów które nie korzystały wcześniej z X-ów, teraz będzie wymagało zainstalowania xbase42.tgz. Jeżeli nie wykonasz tego i będziesz próbować zainstalować pakiet który wymaga libexpat, pkg_add(1) zwróci błąd.
Zwróć także uwagę że kompilacja portów jest wspierana tylko przy pełnej instalacji, włącznie ze wszystkimi zestawami plików dla X-ów.
Ostatecznie po zaktualizowaniu wszystkich pakietów do wersji 4.2, wykonaj porządki poprzez usunięcie starego pakietu expat z twojego systemu:
# pkg_delete expat
Ponieważ projekt OpenBSD zaadoptował najnowsze wersje X.org, wsparcie dla XF3 na platformie i386 (tylko ta platforma z niego korzystała) zostało zaniechane. XF3 było wymagane tylko dla naprawdę starych kart graficznych, które nie były obsługiwane w XF4 i X.org. Wierzymy że ta zmiana nie będzie to dotyczyć wielu użytkowników.
Nowa wersja X.org zmienia wiele z plików konfiguracyjnych, zatem powstała osobna sekcja dla uzytkowników X-ów dotycząca tego procesu aktualizacji.
pciide1 at pci0 dev 31 function 2 "Intel 82801GBM AHCI SATA" rev 0x02: DMA, channel 0 wired to native-PCI, channel 1 wired to native-PCIteraz rozpoznawany jest jako
pciide1: using apic 2 int 11 (irq 11) for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0: <FUJITSU MHV2080BH>
wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5
ahci0 at pci0 dev 31 function 2 "Intel 82801GBM AHCI SATA" rev 0x02: AHCI 1.1: apic 2 int 16 (irq 11)Może to stanowić problem dla użytkowników wykonujących zdalne aktualizacje na tych maszynach, ponieważ plik fstab przestanie być "poprawny", zatem system nie uruchomi się całkowicie. Niestety, sposób w jaki sterownik obsługuje dysk jest zależny od wielu czynników włącznie z konfiguracją BIOS-u, zatem JEŚLI ktoś posiada interfejs AHCI SATA, będzie musiał eksperymentować z podobną maszyną dostępną lokalnie aby zobaczyć czy plik /etc/fstab musi zostać zmieniony.
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: <ATA, FUJITSU MHV2080B, 0084> SCSI2 0/direct fixed
sd0: 76319MB, 76319 cyl, 64 head, 32 sec, 512 bytes/sec, 156301488 sec total
Wierzymy, że bardzo niewielu użytkowników natrafi na takie problemy, ponieważ sterowniki ahci(4) są stosunkowo mało popularne w istniejącym sprzęcie, chociaż stają się teraz zoraz bardziej powszechne.
allow from any inet prefixlen 8 - 24
deny from any inet6 prefixlen > 64
Przypomnienamy, że bgplg i współpracujące binarki zostają wyłączone podczas procesu instalacji/aktualizacji. Jeżeli z nich korzystasz musisz je włączyć ponownie zgodnie z opisem w bgplg(8).
--- ./etc/ssh/sshd_config Sat Mar 10 20:31:32 2007
+++ ../42/etc/ssh/sshd_config Tue Aug 28 11:59:52 2007
@@ -11,3 +11,2 @@
#Port 22
-#Protocol 2,1
#AddressFamily any
@@ -15,2 +14,7 @@
#ListenAddress ::
+
+# Disable legacy (protocol version 1) support in the server for new
+# installations. In future the default will change to require explicit
+# activation of protocol 1
+Protocol 2
Aby większość rzeczy działała tak jak oczekujesz, plik z łatką poniżej dopisze linię "Defaults env_keep" do twojego pliku /etc/sudoers i postara się uczynić ten plik możliwie podobnym do tego z etc42.tgz, jednak prawdopodobnie zawiedzie. Musisz upewnić się że twój plik sudoers zawiera linię wyglądającą jak:
%wheel ALL=(ALL) SETENV: ALL
-- or --
%wheel ALL=(ALL) NOPASSWD: SETENV: ALL
JEŻELI twoja karta sieciowa jest jedną z nich, musisz zmodyfikować twój plik /etc/hostname.deX (podpowiedź: dowiązanie twarde) oraz odpowiednie reguły w pliku pf.conf.
Przypominamy, że zmianata dotyczy tylko platformy alpha.
Jedną z najłatwiejszych metod na uruchomienie systemu z instalacyjnego kernela jest umieszczenie pliku bsd.rd dla wersji 4.2 w głównym drzewie systemu plików i poinstruowanie boot loadera by wystartował z pliku bsd.rd. Dla amd64 oraz i386 wykonasz to wpisując po prostu "boot bsd.rd" gdy pojawi się znak zachęty boot>.
Czasem ktoś może potrzebować aktualizacji na maszynie na której nie można w łatwy sposób przeprowadzić normalnego procesu aktualizacji. Można wówczas wykonać aktualizację ostrożnie postępując w procesie podobnym do aktualizacji opartej na źródłach:
export RELEASEPATH=/usr/rel # gdzie mają znajdować się pliki
cd ${RELEASEPATH}
rm /obsd ; ln /bsd /obsd && cp bsd /nbsd && mv /nbsd /bsd
cp bsd.rd bsd.mp /
cd /
tar -C / -xzphf ${RELEASEPATH}/base42.tgz ./etc/firmware
export RELEASEPATH=/usr/rel
cd ${RELEASEPATH}
tar -C / -xzphf base42.tgz
tar -C / -xzphf comp42.tgz
tar -C / -xzphf game42.tgz
tar -C / -xzphf man42.tgz
tar -C / -xzphf misc42.tgz
tar -C / -xzphf xbase42.tgz
tar -C / -xzphf xfont42.tgz
tar -C / -xzphf xserv42.tgz
tar -C / -xzphf xshare42.tgz
Ponadto pliki z /etc są zarządzane oddzielnie, zatem etc42.tgz oraz xetc42.tgz NIE są tutaj rozpakowywane.
cd /dev
./MAKEDEV all
Nov 1 12:47:05 puffy sm-mta[16733]: filesys_update failed: No such file or dire
ctory, fs=., avail=-1, blocksize=380204
Wiadomość ta może być bezpiecznie zignorowana, możesz też chcieć zatrzymać
sendmail(8)-a na czas aktualizacji.
Zwracamy uwagę, że sendmail nie działa w tym punkcie aktualizacji dobrze
i wymagany jest jego restart (jako część restartu maszyny), zanim poczta
będzie mogła być obsługiwana zgodnie z oczekiwaniami.
Rozpakuj plik etc42.tgz do tymczasowej lokalizacji:
tar -C /tmp -xzphf ${RELEASEPATH}/etc42.tgz
etc/magic
etc/man.conf
etc/netstart
etc/rc
etc/rc.conf
etc/rpc
etc/services
etc/mail/helpfile
etc/mail/localhost.cf
etc/mail/sendmail.cf
etc/mail/submit.cf
etc/mtree/4.4BSD.dist
etc/mtree/BSD.local.dist
etc/mtree/special
cd /tmp/etc
cp magic man.conf netstart rc rc.conf rpc services /etc
cp mtree/* /etc/mtree/
cp mail/helpfile mail/localhost.cf mail/submit.cf /etc/mail
cp mail/sendmail.cf /etc/mail # Uważaj na ten plik!!
Pliki które muszą być ręcznie włączone, uwzględniając lokalne zmiany w nich wykonane, jeżeli były modyfikowane z domyślnych, w przeciwnym wypadku, po prostu również je skopiuj:
etc/ntpd.conf
etc/sensorsd.conf
etc/ssh/ssh_config
etc/ssl/x509v3.cnf
etc/sudoers
etc/sysctl.conf
etc/wsconsctl.conf
var/www/conf/httpd.conf
cd /
patch -C -p0 < upgrade42.patch
W poniższych plikach zostały wprowadzone pewne zmiany na które należy zwrócić uwagę, lecz nie mogą być bezpośrednio skopiowane lub scalone (przykładowo jeżeli korzystasz z bgpd.conf, przyjżyj się sugerowanej zmianie strategii i zdecyduj czy jest właściwa dla twoich potrzeb).
etc/bgpd.conf
etc/mail/spamd.conf
etc/ospfd.conf
etc/ssh/sshd_config
newaliases
mtree -qdef /etc/mtree/4.4BSD.dist -p / -u
Jeżeli podążałeś za instrukcjami procesu aktualizacji bez instalacji nowego kernela, juz zakończyłeś ten krok procesu. Jednakże, jeśli korzystałeś z medium instalacyjnego, i posiadałeś zmodyfikowany kernel w 4.1, istnieje prawdopodobieństwo, że będziesz musiał zmodyfikować kernel w 4.2. Może to być równie proste jak modyfikacja określonego urządzenia korzystając z config(8), lub może pociągać za sobą rekompilację, jeśli dana opcja nie jest włączona w kernelu GENERIC. Prosimy zobacz FAQ 5 - Tworzenie systemu ze źródeł, zanim zdecydujesz się na rekompilację kernela.
Plikami które najprawdopodobniej możesz chcieć zachować są /etc/X11/xorg.conf oraz /etc/X11/xinit/xinitrc. Ponieważ X-y często pracują BEZ pliku xorg.conf, możesz spróbować uruchomić je bez tego pliku, zanim wprowadzisz do nowej wersji swoje zmiany.
Rozpakuj xetc42.tgz podobnie jak inne zestawy plików:
export RELEASEPATH=/usr/rel
cd ${RELEASEPATH}
tar -C / -xzphf xetc42.tgz
Poniższe pakiety znane są z problemów jakie mogą wystąpić podczas ich aktualizacji dla znacznej grupy użytkowników. Fakt, że dany pakiet nie występuje na tej liście nie oznacza że jego uaktualnienie będzie proste. Musisz odrobić "pracę domową" dla aplikacji których UŻYWASZ.
Zanim przejdziemy dalej, jest kilka zmian w wydaniu 4.2 o których powinieneś wiedzieć:
# pkg_add -ui -F update -F updatedepends
Najprawdopodobniej zobaczysz podobny komunikat podczas wykonywania podanego powyżej polecenia:
Looking for updates: complete
Cannot find updates for expat-2.0.0
Proceed? [y/N]
Ostatecznie po zaktualizowaniu wszystkich twoich pakietów, posprzątaj system usuwając stary pakiet expat z systemu:
# pkg_delete expat
[3.4 -> 3.5] | [3.5 -> 3.6] | [3.6 -> 3.7] | [3.7 -> 3.8] | [3.8 -> 3.9] | [3.9 -> 4.0] | [4.0 -> 4.1] | [FAQ Index]
![[back]](../../images/back.gif){kind=small}
www@openbsd.org