Neues Board für den Heimserver

Frisch auf dem Markt – Die neuen ATOM CPUs von Intel

Wobei, was früher ATOM war, heißt jetzt für den Desktop ja Celeron und Pentium.

Die Rede ist von dem Celeren N3050 / N3150 und Pentium N3700.

Die Prozessoren treten damit die Nachfolge zu den Celeron J1800 / J1900 und Pentium J2900 an welche schon eine sehr attracktive Platform für den kleinen Heim- und MedienServer bohten.

Ansich sind die neuen Prozessoren eine konsequente Weiterentwicklung.

Die Performance der CPU ist nur geringfügig gesteigert dafür aber mit noch niedrigerem Verbrauch (6W anstelle von 10W), dafür wurde aber die Grafikperformance um rund 50% gesteigert und auch mit 4K Untestützung ausgerüstet.

Mainboards im ITX Format sind in Deutschland bis jetzt nur von ASRock zu bekommen.

Das ist aber nicht schlim. Das N3150-ITX ist von der Ausstatung sehr nah an dem schon sehr guten Q1900-ITX. Die zwei zusätzlichen USB 3.0 Ports und den Displayport nimmt man dann auch gerne noch mit.

Natürlich muss so ein Heimserver mit Linux befeuert werden.

Als headless System kein Problem, aber für ein System mit Grafik (und das macht es eigentlich erst interessant) braucht man den neusten Kernel vom neusten.

Damit die Braswell-U Grafik arbeitet muss es nämlich gleich Kernel 4.1 sein.

Warum es Intel scheinbar nicht rechtzeitig geschafft hat, entsprechenden Code schon längst vor release der Prozessoren in den Kernel zu bekommen ist mir unverständlich und auch nicht wirklich gewohnt.

Den 4.1 Kernel wird man aktuell wohl in keiner Distribution finden.

Für Arch Linux kann man aber zum glück auf den linux-mainline Kernel im AUR zurücgreifen..

Wer sich die Zeit fürs kompilieren sparen will, der kann sich den Kernel bei mir runterladen.

linux-mainline-4.1rc7-1-x86_64.pkg.tar.xz
linux-mainline-headers-4.1rc7-1-x86_64.pkg.tar.xz

Die Config wurde nicht verändert. Lediglich der Prozessor-Typ von generic x86_64 auf Core2/Later Xeon geändert.

Realtek 8192EU unter Linux Arch

Vor ca. einem Jahr habe ich mir ein Lenovo G710 gekauft. Leider ist die WLAN-Karte in diesem Gerät sehr bescheiden.

Verbaut ist eine Broadcom BCM43142 die sich mit max 65 Mb/s verbindet, aber gefühlt noch viel weniger liefert. Dies ist kein Linux Problem, sondern liegt wohl wirklich an dem schlechten Chip – Auch mit einem Windows Test ist die Performance sehr schlecht (was auch anderen Besitzern so geht).

Ein Austausch der WLAN-Karte ist leider wegen einer Whitelist im BIOS/UEFI auch nicht möglich … Danke Lenovo.

Nun musste endlich mal irgendwas getan werden.

Einzige Möglichkeit – ein USB-Stick. Der sollte natürlich möglichst klein sein (also ein Nano-Stick), möglichst 300 Mb/s übertragen können (damit es sich auch lohnt) und natürlich unter Linux laufen.

Die Auswahl wird hier schon recht dünn.
Meine Wahl viel auf den USB300WN2X2C von Startech.
Baugleich ist auch der MAXXTER ACT-WNP-UA005 (dazu später noch mehr).
Beide werden von einem lsusb als 0bda:818b erkannt.

Der Chipsatz ist ein Realtek rtl8192EU .
Für diesen gibt es zwar Linux Treiber, allerdings auch ein paar Fallstricke.
Out of the Box ging es leider nicht (aber sonst würde ich hier auch nicht schreiben ;-) )

Zuerst:
Der Treiber auf der Webseite von Startech hat die Version 4.2.2-7585
Auf der Seite von MAXXTER bekommt man auch die Version 4.3.1.1-11320

Der Treiber muss natürlich noch kompiliert werden. Leider geht das auch mit der neueren Version nur bis Kernel 3.12 problemlos. Bei einem neueren Kernel muss man patchen.

Nach etwas Recherche habe ich folgenden Patch gefunden:
http://users.telenet.be/x86_64/Patches/rtl8192eu-k3.13.patch

Und ein DKMS deb und rpm (mit dem patch) gibt es sogar auch
http://users.telenet.be/x86_64/Debian/dkms_rtl8192eu_4.3.1.1.11320.20140505_all.deb
http://users.telenet.be/x86_64/RPMs/dkms-rtl8192eu-4.3.1.1-11320.20140505.noarch.rpm

Als Arch Linux User hat es bei mir aber leider trotzdem nicht funktioniert.

Beim kompilieren bin ich immer auf folgenden Fehler gelaufen:

error:
macro "__DATE__" might prevent reproducible builds [-Werror=date-time] __DATE__,__TIME__);

Mit einem kleinen Eingriff in das Makefile lässt sich dieses Problem aber auch lösen.

Folgende Zeile muss eingefügt werden:

EXTRA_CFLAGS += -Wno-error=date-time

Dann ein einfaches make && make install und schon ist der Treiber fertig.

Jetzt noch den Treiber laden – modprobe 8192eu – und schon funktioniert der Stick.

 

Und hat sich die Mühe gelohnt? – Ein klares JA.

Er verbindet sich gleich auf 300 Mb/s , der Empfang liegt bei 99% Signalstärke (okay gleicher Raum aber beim alten war das nicht selbstverständlich) und auch die reale Übertragungsrate ist 1A.

Wer also einen kleinen WLAN-Stick sucht, der unter Linux läuft (mit ein Bisschen Aufwand) und auch wirklich eine gute Übertragungsrate hat, dem kann ich diesen Stick nur empfehlen. Kosten ~15€ .

Ich werde die Tage noch mal versuchen ein AUR Paket zu bastelln.



					

Home- und Medienserver – Nachgelegt

Hallo meine Freunde,

Hier mal ein kleines Update zum Thema Homeserver.

Nachdem ich jetzt ja längere Zeit mit dem obem genannten System gefahren bin, habe ich jetzt mal wieder ein schönes Upgrade unterzogen.

Das Intel DN2800MT ist sicherlich ein schönes Board und mit 6,5Watt TDP echt top als Heimserver im 24/7 Betrieb, aber die PowerVR Grafik setzt leider doch ein Limit für viele Bereiche und der Markt hält aktuell schönes Neues bereit.

Die Intel Celerons der J Generation sind einfach zu verlockend gewesen und so musste ich gleich zugreifen.

Eines der ersten Boards war das Gigabyte J1800N-D2H, welches ich mir dann auch gleich gekauft habe. Das Board hat ansich keine speziellen Features – CPU ist ein Intel Celeron J1800 mit zwei Kernen bei 2,4GHz. Ansonsten alles dabei was das alte Board auch hatte – VGA, HDMI, Gbit LAN, 2x SATA II - dazu kommt ein USB 3.0 Port. Die Grafik liegt zum Glück wieder bei Intel (Intel HD based on Ivy Bridge GPU) und erfreut sich so wieder auch breiter Unterstützung. TDP 10Watt.

Sehr schön (und für mich wichtig) ist der VT support der CPU.

Das Board ist völlig ok. UEFI ohne extras, aber mit den Einstellungen die man braucht – CSM läuft problemlos, so das man auch Windows oder Linux System im „legacy mode“ betreiben kann. Das zeitgleich rausgekommene Board von MSI schien hier Windows8 only zu sein.

Kostenpunkt 53€ - was will man mehr.

Aber meine Beziehung mit dem Gigabyteboard war kurz – denn es kam noch ein neues Board das alles getoppt hat.

Die Rede ist vom ASRock Q1900-ITX (Achtung – nicht die B Variante).
CPU ist hier ein Intel Celeron J1900 – Im Gegensatz hat man hier einen Quad Core mit 2,0GHz. Die Grafikeinheit kann hier etwas höher takten, aber das ist wohl eher nicht der große Unterschied.
Das Board bietet dafür 4x USB 3.0 (2x ext) und vier SATA Ports wobei zwei auf SATA III laufen. Das spart einen zusätzlichen Controller am PCIE oder bietet entsprechend bessere Datenraten (siehe unten).

Der TDP liegt auch hier bei 10Watt. Natürlich braucht man nicht unbedingt einen QuadCore, USB 3.0 könnte man auch noch per HUB weiterreichen und SATA III ist eigentlich nur bei SSDs interessant.

Aber bei gerade einmal +13€ ist die Ausstatung wirklich nicht schlecht und der freie PCIE-Port lässt auch gleich noch einmal Spielraum für etwas Neues.

Natürlich braucht man diese Extras nicht unbedingt.

SATA III macht nur Sinn im Zusammenspiel mit einer SSD – die zusätzlichen Ports sind aber immer gut.

USB 3.0 könnte man bei Bedarf auch über ein HUB erweitern – allerdings kostet das natürlich auch Geld und dann kommt man auch schnell auf den gleichen Preis.

Auch ein QuadCore ist natürlich nicht unbedingt nötig.
Für Musik und Filme tut es natürlich auch ein DualCore und beim J1800 wäre dieser sogar etwas höher getaktet. Der J1900 kann mit boost allerdings auch von 2,0GHz auf 2,41GHz takten (J1800 bis 2,58) und die GPU sogar von 688MHz auf 854MHz (J1800 799MHz).

GHZ alleine sagt aber meist nicht viel aus.

Gut, Benchmarks auch nicht, aber werfen wir doch mal einen Blick darauf.

Der Inetl Celeron J1800 hat einen Passmarkscore von 1123

Der Intel Celeron J1900 hat einen Passmarkscore von 2053

Damit liegt der J1900 auf einem Wehrt von einem Mittelklasse Core2Duo für Desktops oder einer iCore CPU der ersten Generaton im Einstiegsbereich der ersten Generation.

Für einen Heimserver / Mediaserver ist das eine wirklich sattte Leistung – und das bei einem TDP (SOC) von 10Watt.

Die gefühlte Performance ist allerdings bei beiden Systemen gut.

Auch im Betrieb als normaler Desktop mit allen extras hat man keine Laggs. Klar, es ist kein Gamingsystem.

Wenn man die CPU aber mal wirklich rechnen lässt, macht sich der QuadCore schon bemerkbar. Insofern sind die Passmarkwehrte auch nicht ganz realtitätsfremd.

Beispiel: Compilieren eines full Arch Kernels 3.14.1 .

Intel Celeron J1800 (4GB RAM) – 108m13.398s

Intel Celeron J1900 (4GB RAM) - 75m41.920s

Sorge machte mir zuerst auch noch die Temperaturentwickelung,

In einem vollem Gehäuse mit nur einer HE und ohne Lüfter (siehe oben), möchte man sein System natürlich auch nicht grillen.

Unter Last (kompilieren des der Kernel auf allen 4 Kernen) lag die Temp. Nach einer Stunde auf 59°C

Im Idle Betrieb auf 45°C .

Die Temperaturen sind 1A. Und im vergleich zu älteren Atom Serien oder AMDs E/C Prozessoren, die gerne mal auf 80°C und mehr liefen, wirklich undbedenklich.

Mein Fazit und Empfehlung für ein aktuelles Heimserversystem ist deshalb das ASRock Q1900-ITX.

Der kleine Preisaufschlag lohnt sich schon wegen der zusätzlichen Anschlüße – auch wenn man sie heute noch nicht braucht – mit jedem zusätzliche Controller oder HUB wird man die Ersparnis schon eingeholt haben.

Für einen headless Fileserver braucht man das Upgrade nicht.

Für eine Medienzentralle mit FullHD und verteielten Aufgaben im Netzwerk wird man im Moment aber kaum etwas besseres finden (das dann lautlos und klein im Wohnzimmer stehen kann).

 

Wie war das noch mal mit dem Superlativ von Lüge?

Zum benchen von SSDs findet man immer oft den gleichen Test unter Linux.
Nicht nur in diversen Foren, sonder auch bei sehr gute Informationsquellen wie ubuntuusers.de oder wiki.archlinux.org unterläuft aber der selbe schwerer Fehler.

Denn manche SSD-Controller nutzen Kompression.
So zum Beispiel der sehr verbreitete SanForce Controller SF-2281.

Und wo liegt jetzt das Problem?

Ganz einfach. Die Tests sehen immer so aus: $ dd if=/dev/zero of=tempfile …..
Nun ist es sehr,sehr einfach Nullen zu komprimieren, wie sich vermutlich jeder vorstellen kann.
Ein SSD-Controller der Kompression nutzt, hat hier ein leichtes Spiel, denn er kann alles geben was er hat.
Für einen Controller der ohne Kompression arbeitet, ist es hingegen völlig egal.

In der Realität dürfte man aber wohl davon ausgehen, dass die meisten Daten die man so händelt, nicht nur aus Nullen bestehen. Verwendet man alternativ Zufallszahlen, sieht das Ergebnis schnell ganz anders aus.

Im Folgenden mal ein kleiner Vergleich:

OCZ Agility 4 – Controller: Indilinx-Everest-2 > ohne Kompression <
Specs – Seq Read/Write: 420MBs / 410MBs , 4K IOPS Read/Write: 58K / 85K

Kingston SSDNOW V300 – Controller: SanForce SF-2281 > mit Kompression <
Specs – Seq Read/Write: 450MBs / 450MBs , 4K IOPS Read/Write: 85K / 43K

 

$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc

OCZ Agility 4:
1073741824 Bytes (1,1 GB) kopiert, 5,9588 s, 180 MB/s
Kingston SSDNOW V300:
1073741824 Bytes (1,1 GB) kopiert, 3,53624 s, 304 MB/s

VS

$ dd if=/dev/urandom of=/tmp/tempfile bs=1M count=1024 conv=fdatasync,notrunc
$ dd if=/tmp/tempfile of=tempfile bs=1M count=1024 conv=fdatasync,notrunc

OCZ Agility 4:
1073741824 Bytes (1,1 GB) kopiert, 6,05751 s, 177 MB/s
Kingston SSDNOW V300:
1073741824 Bytes (1,1 GB) kopiert, 12,5606 s, 85,5 MB/s

Hinweis: Da /dev/random bzw /dev/urandom zu langsam sind um direkt auf die SSD zu schreiben, werden die Daten vorher erst ins tempfs (RAM) geschrieben lassen und von dort dann erst auf die SSD.

(die Leseraten sind für den Test an sich zu vernachlässigen, aber für den Gesamtvergleich vielleicht interessant)
# echo 3 > /proc/sys/vm/drop_caches
$ dd if=tempfile of=/dev/null bs=1M count=1024

OCZ Agility 4:
1073741824 Bytes (1,1 GB) kopiert, 2,6659 s, 403 MB/s
Kingston SSDNOW V300:
1073741824 Bytes (1,1 GB) kopiert, 3,32878 s, 323 MB/s

Wie man sehen kann, liegt die Schreibrate bei der Kingston SSD im Standarttest sehr viel höher, da der Controller die Kompression voll ausspielen kann. Im Test mit Zufallszahlen sinkt die Schreibrate dagegen auf ein Viertel herab. Bei der Agility 4 gibt es hingegen keine Unterschiede. Was im Benchmarktest von /dev/zero noch recht mager aussah, kann sich hingegen im Vergleich bei dem von /dev/urandom sehr gut behaupten.

Natürlich ist auch dieser Benchmark wieder anfechtbar. Keine Frage.
Der gleiche Test mit einer Video Datei liefert aber zum Beispiel ziemlich die gleichen Werte.
Insofern fehlt es ,meiner Meinung nach, nicht an der entsprechenden Berechtigung, den weit verbreiteten Test von /dev/zero zu hinterfragen.

PS.: Dies soll keine Bewertung der oben genannten SSDs darstellen.

ecarux proudly presents mscan-returns

logo mscan-returns

http://ecarux.de/downloads/mscan-returns.img.xz (
Größe ~ 1.2GB , md5sum c836df3530454a7125ceb14b1e1f391f )

Ja, es ist mal wieder soweit, trotz Sommer, Sonne und Urlaub darf ich heute das neuste update des Diagnose- u. Rettungssystem MScan vorstellen.

Bedienung und Umfang sind im wesentlich die gleichen geblieben. Die Programme und Hardwareunterstützung wurde verbessert und aktualisiert.
Hinzugekommen ist eine core64 Image um exklusive 64Bit Unterstützung zu bieten.
Und es wurde UEFI Unterstützung so wie eine passende Shell eingefügt (hierfür muss der Stick als UEFI Device gebootet werden).

Die Installation erfolgt nach den alten Regeln.

Es wird ein mindestens 4GB großer USB-Stick gebraucht.
Größere Sticks gehen natürlich auch und empfehlenswert ist ein USB 3.0 Stick – auch an einem USB 2.0 Port gibt es meist noch einen ordentlichen Geschwindigkeitsschub.


Die Installation unter Linux:

1. Ladet euch das oben angegebene Image herunter.
2. Steckt euren USB-Stick ein und findet heraus als welches Device er eingebunden wurde zB. Mit

# dmesg | tail
oder

# ls -l /dev/disk/by-id/usb*

3. Schreibt das Image auf den USB-Stick mit

# xzcat mscan-returns.img.xz | sudo dd of=/dev/sdX bs=4M

(/dev/sdX ist natürlich durch das oben ermittelte Device zu ergänzen)


Die Installation unter Windows:

1. Ladet euch das oben angegebene Image herunter.
Die Datei ist komprimiert entpackt sie mittels 7zip , winrar oder ähnlichem
2. Steckt euren USB-Stick ein.
3. Ladet euch den ImageWriter herunter https://launchpad.net/win32-image-writer/0.5/0.5/+download/win32diskimager-binary.zip
Entpackt diesen und startet ihn.
4. Wählt das gerade entpackte mscan-final.img als Image aus, euren USB-Stick und klick auf schreiben.

Und fertig ist der MScan Stick.
Das schöne – es ist problemlos möglich weiter Programme, ISOs , Images und der gleichen einzufügen. Genauso bleiben alle Änderungen und Anpassungen erhalten. - Denn der MScan Stick arbeitet nicht wie eine LiveCD sondern direkt wie von einer Festplatte.

Auf dem Stick befinden sich zwei Partitionen.
Die erste ist eine 1GB große FAT32 Partition – hier gibt es Raum für DOS Programme aller Art und auch die Möglichkeit Logs , Protokolle etc mit Windows und anderen Systemen auszutauschen.
(Hinweis: Nur diese Partition ist unter Windows sichtbar)
Die zweite Partition enthält den Kern des MScan Sticks – es befindet sich hier auf einem komprimierten BTRFS Dateisystem eine Arch Linux Installation, die entsprechend auf Diagnose und Rettungsaufgaben ausgelegt ist. Die Installation kann aber nach belieben um Programme ergänzt und erweitert werden.


Was ist neu?

Vieles – aber neben den üblichen Aktualisierungen haben die meisten Änderungen eher unter der Haube stattgefunden und werden bei der grundsätzlichen Bedienung kaum auffallen.
Zusätzlich wurde eine core64 Image eingefügt um exklusive 64Bit Unterstützung zu haben.
Des weiteren hat der Stick jetzt UEFI Unterstützung und entsprechende Shell – der Stick muss hierfür aber auch als UEFI Device gebootet werden.
(Hinweis: möchte man das Bootmenü ändern und den Stick als UEFI Device nutzen, so müssen die Änderungen auch auf der ersten Partition im Ordner /EFI/grub in die grub.cfg eingetragen werden.)

Arch schneller booten

Ein kleiner Tipp am Rande für alle die Arch Linux nutzen (oder eine andere Linux Distribution mit systemd) und die Bootzeit mit einfachen mitteln etwas verkürzen möchten.

Kurze Analyse der Bootzeit

# systemd-analyze

Startup finished in 1.875s (kernel) + 33.148s (userspace) = 35.024s

# systemd-analyze blame

31.219s NetworkManager-wait-online.service
997ms NetworkManager.service
934ms avahi-daemon.service
837ms systemd-logind.service
235ms systemd-journal-flush.service
152ms alsa-restore.service
110ms systemd-
87ms polkit.service
86ms systemd-vconsole-setup.service
80ms systemd-static-nodes.service
73ms udisks2.service
73ms dev-hugepages.mount
69ms dev-mqueue.mount
66ms systemd-tmpfiles-setup.service
66ms systemd-remount-fs.service
60ms systemd-modules-load.service
46ms tmp.mount
35ms colord.service
31ms systemd-fsck@dev-sda6.service
20ms systemd-user-sessions.service
14ms systemd-random-seed-load.service
14ms wpa_supplicant.service
13ms upower.service
10ms home.mount
9ms systemd-udevd.service
9ms ntpd.service
7ms sys-kernel-config.mount
3ms scratch.mount

Man sieht, eigentlich geht alles ruckzuck, nur NetworkManager braucht ewig.
Dabei ist man ansich ja gar nicht unbedingt darauf angewiesen. Bei Kabel Netzwerken eh nicht und wenn man nicht ständig das WLAN wechselt, tut es eine statische Einrichtung auch.

Wie es geht:
Die Datei /etc/systemd/system/network.service erstellen (zB. mit nano oder einem Editor der Wahl)
Beispiel Inhalt fürs WLAN

Unit]
Description=Network Connectivity
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-wlp2s0.device
After=sys-subsystem-net-devices-wlp2s0.device

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ip link set dev wlp2s0 up
ExecStart=/usr/sbin/wpa_supplicant -B -i wlp2s0 -c /etc/wpa_supplicant/wpa_supplicant.conf
ExecStart=/sbin/dhcpcd wlp2s0

ExecStop=/sbin/dhcpcd -k wlp2s0
ExecStop=/sbin/ip addr flush dev wlp2s0
ExecStop=/sbin/ip link set dev wlp2s0 down

Dann noch die Konfigurationsdatei für wpa_supplicant erstellen die aufgerufen wird

# wpa_passphrase ssid-eueres-netzwerks passwort-fürs-netzwerk > /etc/wpa_supplicant/wpa_supplicant.conf

Jetzt können wir NetworkManager deaktivieren und den network service bei systemd eintragen.

# systemd disable NetworkManager
# systemd enable network

Ein reboot verrät uns das Ergebnis

# systemd-analyze

Startup finished in 1.895s (kernel) + 9.463s (userspace) = 11.359s

# systemd-analyze blame

8.444s network.service
953ms avahi-daemon.service
884ms systemd-logind.service
191ms systemd-journal-flush.service
124ms systemd-udev-trigger.service
120ms sys-kernel-debug.mount
116ms systemd-sysctl.service
110ms systemd-vconsole-setup.service
104ms systemd-static-nodes.service
98ms alsa-restore.service
87ms dev-hugepages.mount
87ms colord.service
83ms udisks2.service
77ms dev-mqueue.mount
69ms systemd-tmpfiles-setup.service
66ms systemd-remount-fs.service
59ms systemd-modules-load.service
37ms polkit.service
36ms tmp.mount
36ms systemd-fsck@dev-sda6.service
14ms systemd-random-seed-load.service
14ms upower.service
13ms systemd-user-sessions.service
12ms home.mount
11ms ntpd.service
11ms scratch.mount
7ms sys-kernel-config.mount
6ms systemd-udevd.service

Na wenn sich das nicht gelohnt hat.
Das Netzwerk braucht zwar immer noch am längsten aber trotzdem konnte die Bootzeit auf ein drittel gesenkt werden.
Ich denke für ein paar Minuten Handarbeit lohnt sich das auf jeden Fall.

Ein schöner Nebenefekt. Vorher hatte ich immer das Problem das Firefox die Sitzung nicht wiederherstellen konnte, jetzt funktioniert es. Vermutlich lag das Problem auch hier daran, das Firefox schon versucht hat die Seiten zu lande bevor das Netzwerk am Start war...

Die neue MScan Version ist fertig.

mscan logo

Die neue MScan Version ist fertig.
Ihr findet es unter http://ecarux.de/downloads/mscan-final.img.bz2
(Größe ~ 1.3GB , md5sum 3628db40fff345e15e817e18cb076943 )

Zum ersten pre1 Version sind einige Programme im Bereich Netzwerk dazu gekommen (u.a. nmap, kismet und passende GUIs), viele Pakete und Treiber wurden aktualisiert. Der Kernel ist jetzt in der aktuellen Version 3.4 vorhanden und XFCE in der Version 4.10.
Sicherheitslücken in Java wurden geschloßen und einige Bugs gefixt.
Zudem gibt es jetzt eine Option im Startscreen um den Stick umzupartitionieren und um so auch die volle Kapazität von USB-Sticks über 4GB zu nutzen. Die Option ist zwar noch etwas hackelig, aber funktioniert (kleines tut dazu folgt).
Die Kompression des Image wurde optimiert.
Minor Updates werde ich in Zukunft als Patches bereitstellen, damit man nicht immer komplett das ganze Image neu aufspielen muss.

Zur Installation:

Ich habe mich mit dieser Version zu einem Wechsel von der guten alten Live-CD zu einem USB-Stick entschieden. Diese bieten einfach ziemliche Vorteile, so lässt sich das System individuell konfigurieren und auch updaten. Außerdem findet man bei einigen Notebooks/Netbooks mittlerweile auch oft keine Laufwerke mehr.

Für die Installation wird ein 4GB großer USB-Stick gebraucht.
Ich denke bei einem Preis vom 4-5€ ist das recht moderat, wobei auch ca. die Hälfte an Platz für Daten und Updates so wie zusätzliche Programme frei bleibt.
(größere Sticks gehen auch, das ist kein Problem)


Die Installation unter Linux:

1. Ladet euch das oben angegebene Image herunter.
2. Steckt euren USB-Stick ein und findet heraus als welches Device er eingebunden wurde zB. Mit

# dmesg | tail

oder

# ls -l /dev/disk/by-id/usb*

3. Schreibt das Image auf den USB-Stick mit

# sudo bzcat mscan-final.img.bz2 | dd of=/dev/sdX bs=4M

(/dev/sdX ist natürlich durch das oben ermittelte Device zu ergänzen)


Die Installation unter Windows:

1. Ladet euch das oben angegebene Image herunter.
Die Datei ist komprimiert entpackt sie mittels 7zip , winrar oder ähnlichem
2. Steckt euren USB-Stick ein.
3. Ladet euch den ImageWriter herunter https://launchpad.net/win32-image-writer/0.5/0.5/+download/win32diskimager-binary.zip
Entpackt diesen und startet ihn.
4. Wählt das gerade entpackte mscan-final.img als Image aus, euren USB-Stick und klick auf schreiben.

Das System ist jetzt auf eurem Stick. Hurra.
Der Stick hat zwei Partitionen. Auf der einen mscanroot befindet sich das Hauptsystem. Diese wird allerdings nicht unter Windows angezeigt.
Die andere heißt MSCAN diese habt ihr auch unter Windows. Hier könnt ihr Daten Speichern etc. . Es befinden sich schon ein paar Daten auf dieser Partition, diese sollten nicht gelöscht werden

Wenn ihr jetzt den Stick bootet kommt eine kurze Auswahl
MScan(das Haupt Linux System)
Memtest86+ (zum Test des Arbeitsspeichers)
FreeDOS (Dos System)

Wenn ihr das MScan Linux System startet, dauert es ca. 10 sek. (je nach Hardware) bis ihr einen Desktop vor euch habt.
Unten links ein Menü (wie bei Windows), unten rechts ein Button zum herunterfahren.
Oben eine Schneelstartleiste.

Memtest86+ zum testen des Arbeitsspeichers. Der Arbeitsspeicher sollte nie unterm OS getestet werden, denn dort ist er natürlich zum Teil belegt (auch wenn es an sich möglich ist – siehe unten).

Mit FreeDos kann man auch so einiges anstelle. Ideal zum BIOS flashen und co.
Mit doszip/dz.exe könnt ihr einen NortonCommader Clone starten. Dos Programme können einfach auf der MSCAN Partition abgelegt werden und dann aufgerufen werden.



Eine kleine Programm übersicht:

(wird noch erweitert und je nach zeit mit Bedientipps ergänzt)

GUI:

ClamTK – Virusscanner
Gparted – Partitionseditor
GSmartControl – Festplatten Tester / Smart Status auslesen
Hardware Lister – Information zur Hardware
Ophlizens – zum entschlüsseln von Windows Passwörtern
Phoronix Test Suite – Umfangreiches Testprogramm für fast alles
Wireshark – Netzwerk Analyse
Thunar – Filemanager
Midori – Webbrowser
Geany – Editor
DriveMap – Übersicht über Festplattenbelegung
BackInTime – Backup Programm

non GUI:

testdisk – recovery von Partitionen und Daten
photorec – wiederherstellen von Bildern
cuda_memtest – zum testen des Grafikspeichers
memtest – Speichertest (wenn möglich memtest86 vorziehen)
secure-delet – sauberes löschen von Festplatten
stress – stresstest

Nebenbei natürlich auch noch alle bekannten Linux Tools sowie einige Programme um sich häuslich einzurichten (Office Anwendungen, Brennprogramm, etc.)

Und noch was.
Zur Konfiguration des Netzwerks einfach unten rechts das Icon mit den zwei Bildschirmen anklicken (wie bei Windows).

Soweit dann erst mal. Viel Spaß damit.
Weiteres folgt …

Installation – Update u. Bugfixes

Es scheint wohl mit neuerer Kernelversion unter Ubuntu ein paar Probleme zu geben.

Mir wurde berichtet das es nach der alten Anleitung kein Bild oder nur "Grafikmüll" zu sehen gibt. Ob sich hier direkt etwas am Kernel geändert hat oder das patchen mit dem drm Modul im Nachhinein zu dem Fehler führt, ist nicht ganz klar.

Ich biete hier deshalb jetzt nochmal eine leicht abgewandelte Installationsanleitung an.

Der Hauptunterschied ist der Kernel, welcher von mir direkt mit dem Cedarview DRM Modul gebaut wurde.
Bis auf die zusätzlich noch vorgenommene Optimierung für Intel Atom CPUs, entspricht der Kernel in allen Funktionen dem ganz normalen Ubuntu-Kernel.
Desweiteren hab ich ein aktualisiertes Paket für den vaapi Treiber mit eingebunden. Dieser entspricht der Treiberversion 1.0.3 und behebt einen Memorybug (siehe Releasenotes).

Der fett gedruckte Teil sind die Änderungen. Der Rest entspricht der bisher bekannten Anleitung.

Die Installation von Xubuntu erfolgt erst mal ganz normal.
Die Installation des Grafikkartentreiber funktioniert danach wie folgt:

# sudo add-apt-repository ppa:sarvatt/cedarview
# sudo apt-get install add-apt-key
# sudo add-apt-key 0x4c96de60854c4636
# sudo apt-get update

Hiermit wird das Repository mit den Treiber hinzugefügt und aktualisiert.

# sudo nano /etc/default/grub

Hier muss video=LVDS-1:d unter GRUB_CMDLINE_LINUX_DEFAULT eingetragen werden. Ansonsten wirde der LVDS Ausgang des Mainboard zuerst angesteuert. In der Regel wird man den Monitor aber wohl am HDMI oder VGA Ausgang angeschlossen sein.

# wget http://ecarux.de/cedargo/ubuntu/linux-image-3.2.0-37-cdv_3.2.0-37.58_i386.deb
# sudo dpkg -i linux-image-3.2.0-37-cdv_3.2.0-37.58_i386.deb

Installiert einen angepasten Kernel.

Danach einmal neu starten und den neuen Kernel booten.
Sicher gehen das der eben installierte Kernel verwendet wird. ( Kernel 3.2.0-30-cdv )

# uname -a

Etwas aufräumen

# sudo apt-get remove $(dpkg --get-selections | grep generic | awk '{print $1}')

Grafiktreiber installieren

# sudo apt-get install libva-cedarview-vaapi-driver cedarview-graphics-drivers
# wget http://ecarux.de/cedargo/ubuntu/libva-cedarview-vaapi-driver_20120820-0ubuntu1_i386.deb
# sudo dpkg -i libva-cedarview-vaapi-driver_20120820-0ubuntu1_i386.deb

Grub config neu ertellen

# sudo grub-mkconfig > /boot/grub/grub.cfg

# apt-get install gdm

Der Displamanager LightDM von Xubuntu macht leider Probleme mit dem Treiber. Mit GDM funktioniert aber alles bestens.

Danach einmal neu starten und es ist vollbracht.

Um jetzt noch volle HW Beschleunigung für die Videowidergabe zu erhalten muss nur noch vollgendes installiert werden.

# apt-add-repository ppa:sander-vangrieken/vaapi
# apt-get update
# apt-get install mplayer-vaapi

Mplayer kann jetzt mit den Parametern -vo vaapi -va vaapi gestartet werden. Bei Frontends wie gnome-mplayer oder smplayer kann diese in den Optionen übergeben.

cedarg on Ubuntu

Ein Linux System bietet sich für einem HomeServer natürlich an.
Das spart nicht nur das Geld, sondern lässt einem auch die freie Konfiguration vom Mediacenter bis zum Cloudserver.

Ein Pferdefuss ist hier allerdings der von Intel verbaute PowerVR Grafik.
Intel hat hier nicht die Hand über die Treiber – dieses Problem betrifft allerdings nicht nur Linux sondern genauso Windows.
Es gibt aktuell leider nur Treiber für Windows 7 32bit, Meego, Fedora 16 und Ubuntu 12.04.

Aufgrund der Aktualität fällt die Wahl hier auf Ubuntu 12.04. .
Besonders da es sich hier um eine LTS Version Handelt die einen noch die nächsten fünf Jahre mit Updates versorgt. Das passt.
Die Treiber müssen hier zwar trotzdem noch nachinstalliert werden (siehe unten), aber mit zwei, dreimal copy&paste ist das auch nicht zu kompliziert.
Dafür darf man sich am Ende auch über echte Full-HD HW-Beschleunigung freuen, welche Windows User bis heute noch missen dürften.

Die Ideale Lösung für Performance und Komfort bietet hier Xubunt.
KDE und Gnome laufen zwar, sind aber meiner Meinung nach für die Verwendung überladen.
Wer ein reines NAS System haben möchte, greift natürlich am besten eh gleich nach der Serverversion.

Die Installation von Xubuntu erfolgt erst mal ganz normal.
Die Installation des Grafikkartentreiber funktioniert danach wie folgt:

# sudo add-apt-repository ppa:sarvatt/cedarview
# sudo apt-get install add-apt-key
# sudo add-apt-key 0x4c96de60854c4636
# sudo apt-get update

Hiermit wird das Repository mit den Treiber hinzugefügt und aktualisiert.

# sudo nano /etc/default/grub

Hier muss video=LVDS-1:d unter GRUB_CMDLINE_LINUX_DEFAULT eingetragen werden. Ansonsten wirde der LVDS Ausgang des Mainboard zuerst angesteuert. In der Regel wird man den Monitor aber wohl am HDMI oder VGA Ausgang angeschlossen sein.

# sudo apt-get install linux-headers-generic linux-image-generic
# sudo apt-get install cedarview-drm libva-cedarview-vaapi-driver cedarview-graphics-drivers

Insatalliert den Kernel, den Treiber und kompliert das nötige Modul. Das ganze kann schon ein paar Minuten dauern.

# apt-get install gdm

Der Displamanager LightDM von Xubuntu macht leider Probleme mit dem Treiber. Mit GDM funktioniert aber alles bestens.

# sudo update-grub2

Aktualisiert Grub.

Danach einmal neu starten und es ist vollbracht.

Um jetzt noch volle HW Beschleunigung für die Videowidergabe zu erhalten muss nur noch vollgendes installiert werden.

# apt-add-repository ppa:sander-vangrieken/vaapi
# apt-get update
# apt-get install mplayer-vaapi

Mplayer kann jetzt mit den Parametern -vo vaapi -va vaapi gestartet werden. Bei Frontends wie gnome-mplayer oder smplayer kann diese in den Optionen übergeben.