FreeBSD 7 auf 8 Update Tipps

Kamikaze

Kamikaze

Warrior of Sunlight
Teammitglied
Hier sind ein paar Tipps zum FreeBSD 8 Update:

WLAN
Um WLAN zu verwenden muss man ein wlan Interface erzeugen das kann man beim Booten mit einem derart gestalteten Eintrag in der rc.conf erledigen lassen:
Code: 
wlans_wpi0="wlan0"

Pakete
Nach dem Update steht erst mal das Installieren von misc/compat7x an.

Danach kann man in /usr/src die Kommandos make delete-old und make delete-old-libs ausführen. Wer faul ist verwendet yes | make delete-old.

In FreeBSD 8 ist libusb integriert. Das Vorhandensein des Pakets kann zu Konflikten führen, deshalb sofort löschen:
Code: 
pkg_delete -f libusb-\*

Egal ob man Binärpakete (z.B. pkg_upgrade [sysutils/bsdadminscripts]) oder die Ports verwendet (z.B. portmaster [ports-mgmt/portmaster]) verwendet, es müssen in der Regel weniger als ein Drittel der Pakete tatsächlich neu installiert werden um die Abhängigkeit auf veraltete Systembibliotheken loszuwerden.

Aber bevor man sich darum kümmert sollte man alles neu installieren, was den Release-Namen in Pfad- und Dateinamen einbaut. Diese Unsitte kann später zu massiven Problemen führen, deshalb den ganzen Mist gleich neu bauen/installieren. Das folgende Kommando (vorsicht, dauert lange) spuckt eine Liste der Pakete aus denen man diese Behandlung zukommen lassen sollte:
Code: 
pkg_info -aL | grep -F 'freebsd-7.2' | xargs -n1 pkg_info -W | grep -o '[^ ]*$' | sort -u

Die Ausgabe sollte man in der Regel in eine Datei umleiten, dann kann man sie direkt mit xargs weiterverarbeiten. Z.B.:
Code: 
xargs -o < [I]filename[/I] pkg_upgrade
Code: 
xargs -o < [I]filename[/I] portmaster

Leider spielt die Reihenfolge hier eine große Rolle. Die Liste wird wahrscheinlich recht kurz, aber es muss viel manuell eingegriffen werden.

Wenn das erledigt ist kann man mit den Paketen fortfahren die direkt mit den alten Systembibliotheken verlinkt sind. Folgendes Kommando setzt die Installation von sysutils/bsdadminscripts voraus und liefert eine Liste aller Pakete die mit fehlenden oder veralteten (in /usr/local/lib/compat liegenden) Bibliotheken verlinkt sind:
Code: 
pkg_libchk -q

Diese Liste kann man dann ebenfalls direkt mit xargs und dem Update-Tool seiner Wahl verarbeiten.

Es empfiehlt sich jedoch zumindest für Selbstbauer vorher die ganz dicken Brocken aus der Liste zu entfernen und sich später einzeln um diese zu kümmern. In meinem Fall war die Liste recht kurz, die JDKs und OpenOffice.

Update:
Ich habe glatt vergessen zu schreiben, wenn alles was pkg_libchk so ausgespuckt hat aktualisiert wurde, kann man misc/compat7x wieder deinstallieren.
 
Zuletzt bearbeitet:
Ich würde sogar knallhart ein "pkg_delete -a" vorschlagen und ganz von vorn alle Ports neuinstallieren. Das ist eine Lehre, die ich seinerzeit beim Update von 6.2 auf 7.0 gezogen habe, da dort nach einigen Wochen und mehreren problemlosen Updates mir GTK wunderprächtig explodiert ist. Es lag schlicht daran, dass einige der grundlegenden Komponenten des GNU-Systems, unter anderem autobreak, libtool und glib2, es gar nicht mochten, teilweise gegen unterschiedliche Versionen der Systembibliotheken gelinkt zu sein. Mag sein, dass es inzwischen wieder egal ist, wie früher auch, aber man weiß nie...
 
@Kamikaze:
Sehr schöne Anleitung, das hilft alten Fricklern wir mir, die von einem Release zum anderen upgraden und nicht neu installieren wollen.

Damit habe ich meinen Kram überprüft und in der Tat hat pkg_libcheck noch eine fehlende Lib angezeigt! Cool!
 
@spaulding
Danke für die Blumen.

@Yamagi
Auf solche Probleme bin ich nie gestoßen. Ziel dieser Anleitung ist ja die alten Systembibliotheken loszuwerden. Ich baue gerdae OpenOffice neu. Danach kann ich misc/compat7x wieder deinstallieren und das Risiko ist aus der Welt.
 
Yamagi schrieb:
Ich würde sogar knallhart ein "pkg_delete -a" vorschlagen und ganz von vorn alle Ports neuinstallieren.
Zum Vergrößern anklicken....

Denke ich auch. Mir hat es erstmal KDE4 zerrissen. Wenn man eh packages nutzt oder eine Maschine hat die entsprechend flott rechnet ist es wohl das schmerzfreiste

Kann jemand eigentlich erklären weshalb diese Änderung am WLAN geschehen ist? Mir leuchtet gerade nicht ganz ein wieso man erst ein "wlan" device erzeugen muss (sprich der technische Hintergrund für diese Entscheidung würde mich interessieren).
 
@MuffiXXL:
Du kannst jetzt virtuelle Interfaces anlegen, z.B. wlan0 im AccessPoint Modus für Netz X, wlan1 macht den AP für Netz Y, usw.
 
Besser: Schreib nen Patch fürs Handbuch, dann können nicht nur deutschsprachige Benutzer davon profitieren.
 
ich hatte diesen Beitrag ja leider zu spät gesehen und mir schon ziemlich viel zusätzliche Arbeit gemacht beim Update.
Trotzdem wollte ich dafür nochmal ausdrücklich danken.
Das ist sehr hilfreich.
 
Folgendes Kommando setzt die Installation von sysutils/bsdadminscripts voraus und liefert eine Liste aller Pakete die mit fehlenden oder veralteten (in /usr/local/lib/compat liegenden) Bibliotheken verlinkt sind:
Code: 
pkg_libchk -q
Zum Vergrößern anklicken....
Soweit scheint es ja zu tun :-)

Mal 'ne frage die hier nicht nur pkg_libchk betrifft, sondern auch z.B. xargs:
Wenn ich das nach dem Update auf 8.0 in einer Jail Shell aufruf, kommt laufend:
Code: 
cannot create /dev/tty: No such file or directory

Bei "xargs -o < foo.txt" dann:
Code: 
xargs: can't open /dev/tty: No such file or directory

Öffne ich in dieser Jail einen MC und mach das dort in einer Subshell, tut das ohne Fehler. Irgendwas scheint da beim Update (freebsd-update) vergessen worden zu sein?


(BTW: So auf ein ^C, scheint pkg_libchk ja wenn überhaupt, dann auch nur zögerlich zu reagieren?)
 
Nein, du hast einfach /dev/tty nicht in der Jeil freigegeben. Das wird für die Statusanzeige benötigt. Wenn es nicht da ist musst du den Parameter -c verwenden.
 
Ein paar Anmerkungen zu den Problemen, die sich hier aufgetan haben:

1. diablo-jdk-1.6.0.07.02_7 installiert beim portupgrade -f automatisch compat-7x
2. kdelibs zickt gewaltig, ich habe es jetzt erstmal verbannt. Ich werde eine manuelle Installation testen.
3. gimp-app-2.6.6 lässt sich aktuell nicht aktualisieren, was aber vermutlich nicht am Upgrade liegt sondern an einer Abhängigkeit von webkit-gtk2:
Code: 
configure: error: Package requirements (libsoup-2.4 >= 2.27.91) were not met:

No package 'libsoup-2.4' found
Ansonsten verlief das Update (das Basissystem etc) sehr reibungslos. pkg_libchk habe ich diverse male durchlaufen lassen müssen, da es immer wieder neue Pakete zum Vorschein gebracht hat, bei denen "etwas fehlte".

Gruß
 
Nein, du hast einfach /dev/tty nicht in der Jeil freigegeben.
Zum Vergrößern anklicken....
Hm, geht das genauer?

also ich hab 'jail_foo_devfs_ruleset="devfsrules_jail"' und darin steht u.a. "add include $devfsrules_unhide_login". Und in devfsrules_unhide_login werden ja die tty's aufgeführt. Von denen seh ich aber nichts in der Jail (das pts subdir hab ich aber.) Naja, das ist die "defaults/devfs.rules". Bisher hing das so jedenfalls.

UNd warum tut's dann, wenn ich in der Jail das im MC (Mindnight Commander) mach?

Ansonsten verlief das Update (das Basissystem etc) sehr reibungslos.
Zum Vergrößern anklicken....
Hm, ich hab dann hinterher noch die Ports zusammensuchen müssen, die noch eine Abhängigkeit auf libuuid haben...
 
/dev/tty zeigt auf das aktuelle Terminal (damit kann ich an stdout und stderr vorbei Statusausgaben machen, was toll ist, denn dann kann man diese trotzdem in eine Datei umleiten, ohne dass da die Statusausgaben reinpfuschen). In deiner Jail hast du aber keinen Zugriff auf das Terminal in dem du sie aufgerufen hast (wahrscheinlich müsstest du da die devfs rules anpassen). Ich vermute MC agiert selbst als Terminal, da du in diesem Fall nicht das Terminal von außen durch reichen müsstest, funktioniert es halt.
 
In deiner Jail hast du aber keinen Zugriff auf das Terminal in dem du sie aufgerufen hast (wahrscheinlich müsstest du da die devfs rules anpassen)
Zum Vergrößern anklicken....
Fragt sich nur wie... Mit den defaults hat's jedenfalls in 7.2. so funktioniert. Naja, mal bei FreeBSD anfragen.

/dev/tty zeigt auf das aktuelle Terminal (damit kann ich an stdout und stderr vorbei Statusausgaben machen, was toll ist, denn dann kann man diese trotzdem in eine Datei umleiten,
Zum Vergrößern anklicken....
"Ärgerlich" war hier nur, dass ich eben über ^C das Ding nicht abbrechen konnte, und durfte so einige Minuten die Fehlermeldungen anschauen. Und selbst im MC, wo es ja ansonsten tut, darf ich da noch 2 Min warten bis es sich "bequemt".
 
Wie das mit CTRL-C kommt habe ich keine Ahnung. Da wird der -c Parameter auch nicht weiterhelfen.

Wenn du CTRL-C verwendest wartet pkg_libchk aber noch ab bis die laufenden Prozesse abgeschlossen sind.
 
/dev/tty zeigt auf das aktuelle Terminal
Zum Vergrößern anklicken....
Manchmal kann man da wohl sagen ;-) Warum testest das nicht einfach im Script und setzt dann den "-c" bei Bedarf selbst?

BTW:
An einer Stelle benutzt du das tty ohne den $clean zu testen. Bei irgendeinem cat auf eine Tempdatei, könntest noch die Fehlerausgabe unterdrücken (die da manchmal kommt wenn man das Script abbricht). Bei "/tmp" könnte man evtl ja auch schauen, ob TMPDIR gesetzt ist.

Ärgerlich" war hier nur, dass ich eben über ^C das Ding nicht abbrechen konnte, und durfte so einige Minuten die Fehlermeldungen anschauen.
Zum Vergrößern anklicken....
BTW waren das beim Nachmessen hier gerade ~20min. Das Problem tritt auch nur auf, wenn das Script ein Paket gefunden hat und den Namen ausgegeben hat.


Mit den defaults hat's jedenfalls in 7.2. so funktioniert. Naja, mal bei FreeBSD anfragen.
Zum Vergrößern anklicken....
OK, in 7.2 tut das auch nicht. Ist mir nur noch nie aufgefallen, weil sonst kein Admintool (das ich benutze) versucht das tty direkt zu benutzen.

Jedenfalls liegt das daran, wenn man mit jexec in die Jail geht. In dem Fall gehört das Inputdevice noch zum Hauptsystem auf das man dann natürlich in der Jail keinen Zugriff hat. Damit solltest du das also Nachstellen, und dein Script daraufhin untersuchen können.
 
Zuletzt bearbeitet:
Wiedmann schrieb:
Manchmal kann man da wohl sagen ;-) Warum testest das nicht einfach im Script und setzt dann den "-c" bei Bedarf selbst?
Zum Vergrößern anklicken....
Mache ich.

Bloß nicht in der alten Version und der Entwicklungszweig ist gerade nicht in einem Zustand der ein Zwischenrelease möglich macht.

Wer kommt denn auch auf solche Ideen, dass man keinen Zugriff auf das Terminal bekommt?

Ach ja, danke noch für den Fehler, im trap teste ich das Flag nicht.
 
Hallo kamikaze, vielleicht interessiert dich dieser Commit von Ed in HEAD:
Code: 
  Author: ed                                                                          
  Date: Sat Dec 19 18:42:12 2009                                                      
  New Revision: 200732                                                                
  URL: http://svn.freebsd.org/changeset/base/200732                                   
                                                                                      
  Log:                                                                                
    Let access overriding to TTYs depend on the cdev_priv, not the vnode.             
                                                                                      
    Basically this commit changes two things, which improves access to TTYs           
    in exceptional conditions. Basically the problem was that when you ran            
    jexec(8) to attach to a jail, you couldn't use /dev/tty (well, also the           
    node of the actual TTY, e.g. /dev/pts/X). This is very inconvenient if            
    you want to attach to screens quickly, use ssh(1), etc.                           
                                                                                      
    The fixes:                                                                        
                                                                                      
    - Cache the cdev_priv of the controlling TTY in struct session. Change            
      devfs_access() to compare against the cdev_priv instead of the vnode.           
      This allows you to bypass UNIX permissions, even across different               
      mounts of devfs.                                                                
                                                                                      
    - Extend devfs_prison_check() to unconditionally expose the device node           
      of the controlling TTY, even if normal prison nesting rules normally            
      don't allow this. This actually allows you to interact with this                
      device node.                                                                    
                                                                                      
    To be honest, I'm not really happy with this solution. We now have to             
    store three pointers to a controlling TTY (s_ttyp, s_ttyvp, s_ttydp).             
    In an ideal world, we should just get rid of the latter two and only use          
    s_ttyp, but this makes certian pieces of code very impractical (e.g.              
    devfs, kern_exit.c).                                                              
                                                                                      
    Reported by:        Many people
 
Wirst du auch müssen, da diese Änderungen Jahre brauchen, bis alle Nutzer sie sicher im System haben. :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben