Zum Thema nicht ganz nützliches Wissen:
Die "Vorschriften für Klassifikation und Bau von stählernen Seeschiffen" des Germanischen Lloyd von 1967. Sollte ich also irgendwann mal ein stählernes Seeschiff bauen wollen...;)
Montag, 23. März 2009
Mittwoch, 18. März 2009
VxVM defekte Private-Region
Mein "Lieblings"-VolumeManager VxVM wollte spontan 3 Diskgroups nicht importieren, obwohl die Platten da waren und sogar der vxdisk -o alldgs list anzeigt das die Platten zu der zu importierenden DG hoeren. Raetsels Loesung: vxprivutil beschwert sich das die Private Region kaputt ist.
Zum Glueck haben wir einen Sun Explorer Output von letzter Woche, dort gibts ein vxprint-th.out indem die Config des VxVM steht.
Also nachsehen wie die Platte aufgesetzt war. Format=sliced, d.h. kein Gewusel mit CDS.
Slice 3 war 1.88MB gross und hatte eine 1MB grosse PrivateRegion (VxVM 4.1 default). Nun gabs ein Upgrade auf VxVM 5 und der hat als default 32MB.
Ich moechte also die Volume Manager Config wieder herstellen, ohne Datenverlust im Filesystem.
Zuerst also ein freundliches:
/etc/vx/bin/vxdisksetup -f -i cXtXdX format=sliced privslice=3 privlen=1M
Damit ist eine leere Private Region auf der Platte und wir kommen nicht mehr an die Daten ran. Das heisst aber nicht das sie weg sind - vxdisksetup aendert im sliced layout nichts an der public region in der unsere volumes liegen.
Nun recovern wir die "foodg", welche eine Disk-Media namens foodg01 hatte:
vxdg init foodg foodg01=cXtXdXs2
Jetzt muessen wir uns im vxprint-th.out ansehen wie unsere subdisks ausgesehen haben (Zeile sd) und entsprechen neu anlegen:
vxmake -g foodg sd foodg01-01 disk=foodg01 offset=0 len=16777216
vxmake -g foodg sd foodg01-02 disk=foodg01 offset=16777216 len=16777216
Dazu bauen wir jetzt unsere zwei Plexes:
vxmake -g foodg plex foo01-01 sd=foodg01-01
vxmake -g foodg plex foo02-01 sd=foodg01-02
Und darueber je ein Volume, so wie es vorher war:
vxmake -g foodg -U fsgen vol foo01 plex=foo01-01
vxmake -g foodg -U fsgen vol foo02 plex=foo02-01
Jetzt sollte ein vxprint -g foodg -th genauso aussehen wie in unseren vxprint-th.out - allerdings sind die Volumes "DISABLED EMPTY" und vxvol mag sie nicht starten. Daher muessen wir sie mit einem speziellen vxvol Kommando starten:
vxvol -g foodg init active foo01
vxvol -g foodg init active foo02
Jetzt sollten wir zur Sicherheit einen fsck absetzen (in unserem Falle ein vxfs):
fsck -Fvxfs /dev/vx/rdsk/foodg/foo01
fsck -Fvxfs /dev/vx/rdsk/foodg/foo02
Und koennen sie wieder mounten - und haben unser altes Filesystem nicht ueberschrieben.
Zum Glueck haben wir einen Sun Explorer Output von letzter Woche, dort gibts ein vxprint-th.out indem die Config des VxVM steht.
Also nachsehen wie die Platte aufgesetzt war. Format=sliced, d.h. kein Gewusel mit CDS.
Slice 3 war 1.88MB gross und hatte eine 1MB grosse PrivateRegion (VxVM 4.1 default). Nun gabs ein Upgrade auf VxVM 5 und der hat als default 32MB.
Ich moechte also die Volume Manager Config wieder herstellen, ohne Datenverlust im Filesystem.
Zuerst also ein freundliches:
/etc/vx/bin/vxdisksetup -f -i cXtXdX format=sliced privslice=3 privlen=1M
Damit ist eine leere Private Region auf der Platte und wir kommen nicht mehr an die Daten ran. Das heisst aber nicht das sie weg sind - vxdisksetup aendert im sliced layout nichts an der public region in der unsere volumes liegen.
Nun recovern wir die "foodg", welche eine Disk-Media namens foodg01 hatte:
vxdg init foodg foodg01=cXtXdXs2
Jetzt muessen wir uns im vxprint-th.out ansehen wie unsere subdisks ausgesehen haben (Zeile sd) und entsprechen neu anlegen:
vxmake -g foodg sd foodg01-01 disk=foodg01 offset=0 len=16777216
vxmake -g foodg sd foodg01-02 disk=foodg01 offset=16777216 len=16777216
Dazu bauen wir jetzt unsere zwei Plexes:
vxmake -g foodg plex foo01-01 sd=foodg01-01
vxmake -g foodg plex foo02-01 sd=foodg01-02
Und darueber je ein Volume, so wie es vorher war:
vxmake -g foodg -U fsgen vol foo01 plex=foo01-01
vxmake -g foodg -U fsgen vol foo02 plex=foo02-01
Jetzt sollte ein vxprint -g foodg -th genauso aussehen wie in unseren vxprint-th.out - allerdings sind die Volumes "DISABLED EMPTY" und vxvol mag sie nicht starten. Daher muessen wir sie mit einem speziellen vxvol Kommando starten:
vxvol -g foodg init active foo01
vxvol -g foodg init active foo02
Jetzt sollten wir zur Sicherheit einen fsck absetzen (in unserem Falle ein vxfs):
fsck -Fvxfs /dev/vx/rdsk/foodg/foo01
fsck -Fvxfs /dev/vx/rdsk/foodg/foo02
Und koennen sie wieder mounten - und haben unser altes Filesystem nicht ueberschrieben.
Dienstag, 17. März 2009
Sun Connection...
Ich hasse die SCS GUI...
(262) olga5096:/export/home/olbohlen$ uce_console
(263) olga5096:/export/home/olbohlen$ X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 147 (XKEYBOARD)
Minor opcode of failed request: 16 (XkbSetNamedIndicator)
Serial number of failed request: 1302
Current serial number in output stream: 1305
Und das nur als ich mit dem Mouse Pointer im Login-Dialog ins Username-Feld geklickt habe und meinen Namen tippen wollte...
Passiert mir nur wenn ich se per X-Forwarding auf mein Notebook im JDS anzeigen lasse. Per X-Forwarding im CDE im eXceed auf der Wintendo-Schuessel lueppts. Sehr spannend.
(262) olga5096:/export/home/olbohlen$ uce_console
(263) olga5096:/export/home/olbohlen$ X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 147 (XKEYBOARD)
Minor opcode of failed request: 16 (XkbSetNamedIndicator)
Serial number of failed request: 1302
Current serial number in output stream: 1305
Und das nur als ich mit dem Mouse Pointer im Login-Dialog ins Username-Feld geklickt habe und meinen Namen tippen wollte...
Passiert mir nur wenn ich se per X-Forwarding auf mein Notebook im JDS anzeigen lasse. Per X-Forwarding im CDE im eXceed auf der Wintendo-Schuessel lueppts. Sehr spannend.
Citrix Client Solaris x86
Seit der Citrix Client 8.50 fuer Solaris x86 released wurde habe ich immer wieder versucht den zu benutzen, aber er ist immer auf die Bretter gegangen mit einem Segmentation fault. Heute habe ich durch Zufall auf den Citrix Foren die Loesung gefunden: der Citrix Client (namentlich der wfica) kommt mit der libXm.so.4 nicht klar. Daher hilft es in /usr/lib/ICAClient das binary wfica umzubenennen und einen shell-wrapper zu erzeugen:
(142) oldn9621-e:/usr/lib/ICAClient# cat wfica
#!/bin/ksh
# small hack for preventing segfaulting wfica in libXm.so.4
# olbohlen, 2009-03-17
LD_PRELOAD=/usr/dt/lib/libXm.so.3 /usr/lib/ICAClient/wfica.bin $@
(143) oldn9621-e:/usr/lib/ICAClient# ls -l wfica.bin
-r-xr-xr-x 1 root sys 1309280 Sep 14 2007 wfica.bin
Jetzt klappts auch mit dem Citrix :)
(142) oldn9621-e:/usr/lib/ICAClient# cat wfica
#!/bin/ksh
# small hack for preventing segfaulting wfica in libXm.so.4
# olbohlen, 2009-03-17
LD_PRELOAD=/usr/dt/lib/libXm.so.3 /usr/lib/ICAClient/wfica.bin $@
(143) oldn9621-e:/usr/lib/ICAClient# ls -l wfica.bin
-r-xr-xr-x 1 root sys 1309280 Sep 14 2007 wfica.bin
Jetzt klappts auch mit dem Citrix :)
Donnerstag, 5. März 2009
Neue Fock...
Heute erreichte mich also der seit Montag ersehnte Brief von Beilken mit der Auftragsbestätigung für meine neue Fock - welche streng genommen ja eine Genua ist:
Standard Genua 10,9 qm, Cross Cut, Dacron 270 g/qm Tan MT.
Schoen braun wird sie werden - Mitte April wird sie wohl fertig sein, ich kanns kaum erwarten :)
Standard Genua 10,9 qm, Cross Cut, Dacron 270 g/qm Tan MT.
Schoen braun wird sie werden - Mitte April wird sie wohl fertig sein, ich kanns kaum erwarten :)
Abonnieren
Posts (Atom)
