• From 16 to 2 ports: Ideal SATA/SAS Controllers for ZFS

See /var/sadm/patch/IDR145690-01/log for details
Patchadd is terminating
Patch IDR145690-01 failed to install due to a failure produced by pkgadd.
See /var/sadm/patch/IDR145690-01/log for details
Patchadd is terminating

Ein Blick ins Logfile zeigt, dass checkinstall fehlschlägt:

# cat /var/sadm/patch/IDR145690-01/log

This appears to be an attempt to install the same architecture and
version of a package which is already installed.  This installation
will attempt to overwrite this package.

/root/IDR145690-01/SUNWnfsckr/install/checkinstall: /root/IDR145690-01/SUNWnfsckr/install/checkinstall: cannot open
pkgadd: ERROR: checkinstall script did not complete successfully
Dryrun complete.
No changes were made to the system.

install:x:0:1:installation user:/:/bin/true 

Sofern man sich vorgängig registriert hat und über einen gültigen Service Vertrag mit Oracle verfügt, können sämtliche Patches welche in  der patchdiag.xref erwähnt werden bezogen werden.

Neu können die Patches und das patchdiag.xref File über folgende URLs bezogen werden:
https://getupdates.oracle.com/reports/patchdiag.xref

https://getupdates.oracle.com/all_unsigned/119254-76.zip

Wie man aus den einschlägigen IT Medien entnehmen konnte, hat sich Oracle entschieden von Solaris Entwicklungsmodel von Sun nicht zu übernehmen und stattdessen wieder die Express Releases einzuführen, welche man bereits aus früheren Solaris Releases kennt.

Der lang ersehnte erste Express Release von Solaris 11 wurde nun diese Woche von Oracle veröffentlicht und ist kostenlos auf als Download verfügbar.

Das schier endlose What’s New Dokument zeigt deutlich, dass es Oracle mit seinen Versprechungen bezüglich der Solaris Entwicklung ernst meint und zeigt deutlich, in welche Richtung es dabei gehen soll.

Auf die neuen Features werde ich in den nächsten Wochen in weiteren Blog Einträgen näher eingehen.

Solaris 11 Express

• What’s New in OpenSolaris 2010.05

Interessant bei dieser Entscheidung ist aber folgende Aussage auf der OpenSolaris Malingliste:

The Opera staff asked – as usual – for help to circumvent a Solaris
bug. The (new) response, totally the opposite from Sun’s helpful
behavior of the past was:

1. Opera did not purchase support for Solaris
2. Without support Oracle will not answer technical questions or provide ANY help
3. Opera uses the SOLARIS trademark without permission
4. Opera will have to buy a full year of support for 502018 Euro to obtain questions to their answers

In wie fern diese Aussage stimmt ist schwer abzuschätzen. Es kann sich durch aus um FUD handeln, es wäre aber auch vorstellbar, dass auch eine Spur Wahrheit in dieser Aussage steckt.

root@planex:~# ipfstat | grep lost
fragment state(in):     kept 0  lost 0  not fragmented 0
fragment state(out):    kept 0  lost 0  not fragmented 0
packet state(in):       kept 33302919   lost 11264
packet state(out):      kept 8572793    lost 214808

Interessant sind hier die lost Werte. Schaut man sich die default Settings an, merkt man, dass die Einstellungen in der Tat doch recht konservativ sind:

root@planex:~# ipf -T list | grep fr_state
fr_statemax     min 0x1 max 0x7fffffff  current 4013
fr_statesize    min 0x1 max 0x7fffffff  current 5737

Um die Limite zu erhöhen, muss als erstes ipf deaktiviert werden und anschliessend wieder aktiviert werden. Zu beachten ist dabei, dass fr_statemax ca. 70% so gross ein sollte wie fr_statesize.

root@planex:~# svcadm disable ipfilter
root@planex:~# /usr/sbin/ipf -T fr_statemax=24500,fr_statesize=35000
root@planex:~# svcadm enable ipfilter

root@planex:~# ipf -T list | grep fr_state
fr_statemax     min 0x1 max 0x7fffffff  current 24500
fr_statesize    min 0x1 max 0x7fffffff  current 35000

Damit die neuen Werte auch über die Reboot-Grenze erhalten bleiben, sollte folgender Eintrag in der /usr/kernel/drv/ipf.conf stehen:

name="ipf" parent="pseudo" instance=0; fr_statemax=24500 fr_statesize=35000;

Abschliessend sollte das Device mit devfsadm konfiguriert werden:

root@planex:~# devfsadm -i ipf

Als Workaround empfiehlt es sich das System in den maintenance mode zu booten und den Fehlerhaften Eintrag in der /etc/vfstab zu entfernen