Bitcoin auf Talfahrt

Der Bitcoin jetzt seine Talfahrt in die richtige Richtung fort, nach unten ūüôā

Der Niedergang

Der seit einer Woche anhaltende Trend best√§tigt sich auch heute, dem Bitcoin geht es schlecht. Von 9.000 ‚ā¨ auf 4.800 ‚ā¨ in nur einer Woche bedeutet, was jeder ahnen konnte: Die Blase ist geplatzt. 40% Wertverlust ist schon eine Marke. Die Verlustkurven reisen tiefe L√ľcken in den Graphen, trotzdem scheint sich der wertlose Digitaltiger immer wieder dagegen stemmen zu wollen.

Der Kurs der letzten 10 Stunden (Stand 10:30 Uhr)¬† ist das auch von Extremen gepr√§gt. Gegen 2 Uhr waren es noch Spitzen von 5.700 ‚ā¨, die dann binnen 4 Stunden auf das erste Tagestief von 4.850 ‚ā¨ zusammenbrachen, nur um von noch steilere Kursanstiege auf 5.300 ‚ā¨ gefolgt zu werden.

Aber alles k√§mpfen nutzte nichts, um 9 Uhr brach der Kurs auf 4.800 ‚ā¨ ein. Die derzeitige Kurserholung auf 5.000 ‚ā¨ ist auch nur ein Zwischenschritt, bis die n√§chste Schneeballebene zum Verkauf schreitet.

Fazit

Wer jetzt nicht verkauft, ist selbst Schuld, wenn er als Kollateralschaden im Schneeballsystem endet.

Kommentar

Man mu√ü den Spekulanten eins lassen, sie haben den Kurs von Nichts in $ ausgedr√ľckt bekommen und sehr vielen Menschen sehr viel Geld abgenommen, ohne daf√ľr einen Gegenwert zu liefern, falls der Gegenwert nicht der Spa√ü am Daytrading war. Der reale Gegenwert eines Bitcoins ist n√§mlich 0, genau wie der reale Wert eines 500 ‚ā¨ Scheins*. Da aber mehr als 300 Millionen Menschen an den ‚ā¨ glauben, ist sein Gegenwert realer als es der Bitcoin je sein konnte.Au√üerdem ist der ‚ā¨ an reale Werte gekoppelt, denn ich kann daf√ľr Immobilien und G√ľter kaufen und verkaufen.

Nicht einmal die Bitcoinkonferenzen haben am Ende den Bitcoin als Zahlungsmittel akzeptiert. Nat√ľrlich nur wegen der hohen Transaktionsgeb√ľhren, die als einzige verl√§ssliche Zahl steigen m√ľssen. Das haben selbst die Sch√∂pfer des Bitcoins so vorhergesehen.

Von den noch vor wenigen Wochen erhofften Gewinnen durch den Handel mit Derivaten an den „echten“ B√∂rsen, ist jetzt nat√ľrlich nichts mehr zu erwarten. Das waren nur die Versuche der abgeh√§ngten Spekulanten an dem Schneeballsystem mitzuverdienen. Bei den Verlusten des Bitcoins, d√ľrfte der Keks gegessen sein.

*) Der Schein hat tats√§chlich durch seine Produktionskosten und Materialien einen Wert > 0, aber nicht viel dr√ľber ūüėČ

Update 16:30 Uhr:

Die Talfahrt blieb ein Strohfeuer im Zuge des Grauen-Montags an den Amerikanischen B√∂rsen. Mit Stand 16:30 w√ľrde der Bitcoin mit einem Plus von 7% gegen√ľber dem Stand von 0.00 Uhr dastehen. Am Trend zum totalen Wertverlust √§ndert sich damit aber nicht. Bin mal gespannt, wie es bei den Zockern weitergeht. Als Soap-Opera ist das ja kaum zu √ľberbieten ūüôā

Wenn Cinnamon ständig crashed

Warum immer in der Weihnachtszeit ? Die sollte doch so friedlich sein. Mein Laptop war anderer Meinung. Vor zwei Wochen erst auf Fedora 26 aktualisiert und seit Mittwoch crasht Cinnamon in Endlosschleife in seinen R√ľckfallmodus, ohne irgendeine brauchbare Spur zu hinterlassen. Na gut, Challenge Accepted!

Die Versuchsreihe

Zunächst mal sollte man checken, ob man vielleicht ein neues Update bekommen hat und dies das Problem löst. Tat es nicht, weil keines kam.

Ok, jetzt m√ľ√üte man doch mal nachsehen, was da unter der Haube los ist. Also „journalctl -xe | grep -i cinnamon“ eingegeben und … nichts.

Ok, versuchen wir es ohne den Filter : „journalctl -xe“ und siehe da, jede Menge rote Crashmeldungen in diversen Libs, aber leider kein Hinweis, was da der Ausl√∂ser sein k√∂nnte. Auch 1 Stunde sp√§ter, und diverse andere Logs und Webseiten sp√§ter, senkte sich vom Baum der Erkenntnis die rote Kartenfrucht herab.

Der Reinstall

Ein klares Signal, einen Reinstall durchzuf√ľhren, also als Root eingegeben:

dnf reinstall „cinnamon*“

Und wieder in Cinnamon einloggen… args.. gleiches Ergebnis. Hmm.. da hat es wohl noch mehr zerlegt… uff. Also, ‚ dnf reinstall „*“ ‚ eingegeben, also die ersten 80 Pakete bereits runter geladen waren, wollte ich aber doch noch mal etwas anderes austesten.

adduser -s /bin/bash testuser
passwd testuser

Und dann mal als Testuser einloggen. Oh… Das geht ja … Da ist dann wohl doch nur die Session defekt. Dann hauen wir die halt weg:

rm -rf ./.config/cinnamon-session ./.local/share/cinnamon ./.cinnamon

Danach ist der Account so jungfr√§ulich, da√ü Cinnamon alles wieder sauber anlegt und oh Wunder, dann geht es auch wieder mit dem Login ūüėÄ

Man mu√ü nat√ľrlich alles neu einstellen,aber das ist ein kleiner Preis. Was meine Session/Einstellungsdaten genau getroffen hatte, wird man wohl nie erfahren ūüėČ

 

Der GAU – Festplattenausfall und wie man Ihn behebt

„Wenn die Hardware versagt,und das Filesystem mit in den Abgrund zieht.“

Es war ein lauer Sonntagmittag, der Stream des Chaosradios ergo√ü sich von Radio Fritz, der Frachter in EVE flog seine Route, als pl√∂tzlich …¬† ‚Äěcan’t create tempfile in /tmp/gluster-x34234.tmp‚Äú auf der Konsole¬† erschien. Das Ende vom Lied, die Festplatte hatte versagt:

 

 

 

 

 

 

Beim Rebooten startete das System nicht mehr mit dem Hinweis, daß die Superblöcke der Partionen/Filesysteme beschädigt wären.

/var/log/messages-20170402:Apr  2 15:05:32 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:10 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:29 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:30 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:34 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:44 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:47 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:49 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:49 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:09:46 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:09:58 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:11:34 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:21:39 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:25:56 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!

Ein Mounten der Bootpartition war nicht mehr möglich, weil der Superblock defekt war. Im Endergebnis waren zwei Filesysteme der SSD defekt.

Wie konnte das passieren ?

Wenn man Google nach den im Screenshot gezeigten Fehlern befragt, zeichnet sich sehr schnell ab, daß die meisten auf ein Versagen der Stromzufuhr tippen. Das kann man aber wohl ausschliessen, da dabei als erstes die Grafikkarte ausgegangen wäre.

Da ich einige Tage vorher von Fedora 24 auf Fedora 25 umgestiegen bin, und damit auch ein neuer 4.10er Kernel zum Einsatz kam, ist es viel wahrscheinlicher, daß eine Treiber-HW-Kernel-Inkompatibilität vorlag. Das gabs bei Kernel 3.11 und 3.18 schon einmal.

Wie komme ich jetzt darauf ?

Das kommt daher, daß ich an dem besagten 2. April  das Stromversagen akzeptiert habe und daher die Stromverbindungen erneuert hatte. Einige Tage später, knallte die gleiche Platte wieder weg, ohne das jemand auch nur in  die Nähe der Stecker gekommen wäre. Seit Kernel 4.10.8-200 tritt das Problem nicht mehr auf. Es lag also vermutlich nicht am Strom, sondern an der Kernel-Treiber-HW Kombination.

Filesystem läßt sich nicht mounten

Es waren also zwei Filesysteme defekt. Dummerweise System-Root und die Bootpartition, wobei es die Bootpartition besonders schwer getroffen hatte:

kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!

Der den Fehler sieht, spart sich am besten gleich den Reperaturversuch und mountet die Platte mit der NOCHECK Option im Readonlymodus und kopiert die noch vorhandenen Files auf ein Backupmedium. Danach dann die Platte frisch formatieren und Daten wieder drauf spielen. Alles andere d√ľrfte Zeitverschwendung sein. (siehe PDF)

Die Systempartition ließ sich im Gegensatz zur Bootplatte recht einfach mit fsck.ext4 reparieren. Daher liegt das Augenmerk des Beitrags auch auf dem Thema: Wie man eine neue Bootpartition aufbaut.

Da ich aus dem Problem und seiner L√∂sung gleich einen Vortrag f√ľr unsere LUG gemacht habe, k√∂nnt Ihr Euch jetzt alle n√∂tigen Schritte in einem PDF herunterladen. Ich werde daher auch nur grob auf die einzelnen L√∂sungswege eingehen. Im PDF sind auch Reparaturanweisungen mit fsck, dumpefs, mke2fs¬† enthalten. Ich empfehle dringend das PDF an einem zug√§nglichen Ort aufzubewahren, ggf. auch als Offlinekopie ūüėČ

Wie man eine Bootpartition neu aufbaut

Wir nehmen einfach mal an, da√ü die Bootpartition komplett hin√ľber ist, was bei dem oben aufgef√ľhrten Bug wohl auch der Fall ist. Mein Rettungsversuch mit fsck f√ľhrte zum totalen Datenverlust, weil einige Inodes doppelt und dreifach belegt waren( vermute ich mal).

Deswegen ist oftmals nur eine neue Partition bzw. ein Reformatieren der Partition der letzte Ausweg.

Da das Formatieren die UUIDs einer Partition ändert, stimmen die Daten auf der Systemplatte nicht mehr.

Um der Sache jetzt folgen zu k√∂nnen, m√ľ√üt Ihr zwei Dinge wissen:

  1. Was UUIDs und BLKIDs  sind
  2. Wie die im System benutzt werden um Partition zu referenzieren.

zu 1)

UUIDs werden von LUKS verschl√ľsselten Festplatten benutzt und sind ziemlich lange, aber eindeutige IDs.

$ lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sr0                                            11:0    1  1024M  0 rom   
sdc                                             8:32   0 111,8G  0 disk  
‚Ēú‚ĒÄsdc2¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬† 8:34¬†¬† 0 103,7G¬† 0 part ¬†
‚Ēā ‚ĒĒ‚ĒÄluks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa 253:0¬†¬†¬† 0 103,7G¬† 0 crypt /
‚Ēú‚ĒÄsdc3¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬† 8:35¬†¬† 0¬†¬† 7,6G¬† 0 part ¬†
‚Ēā ‚ĒĒ‚ĒÄluks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a 253:1¬†¬†¬† 0¬†¬† 7,6G¬† 0 crypt [SWAP]
‚ĒĒ‚ĒÄsdc1¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬† 8:33¬†¬† 0 525,5M¬† 0 part¬† /boot
sda                                             8:0    0   1,8T  0 disk  
‚Ēú‚ĒÄsda4¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬† 8:4¬†¬†¬† 0¬†¬†¬†¬† 1K¬† 0 part ¬†
‚Ēú‚ĒÄsda2¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬† 8:2¬†¬†¬† 0¬† 78,1G¬† 0 part ¬†
‚Ēā ‚ĒĒ‚ĒÄluks-6d45b281-c56c-40f0-acf7-c3058d4d6913 253:3¬†¬†¬† 0¬† 78,1G¬† 0 crypt 
‚Ēú‚ĒÄsda5¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬† 8:5¬†¬†¬† 0¬†¬† 1,8T¬† 0 part ¬†
‚Ēā ‚ĒĒ‚ĒÄluks-7881f602-9462-497d-810a-7d6111ad6085 253:2¬†¬†¬† 0¬†¬† 1,8T¬† 0 crypt /sata_home
‚Ēú‚ĒÄsda3¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬† 8:3¬†¬†¬† 0¬†¬† 7,8G¬† 0 part ¬†
‚Ēā ‚ĒĒ‚ĒÄluks-384d6b27-6263-4d53-bfce-e7e5bcd221b9 253:4¬†¬†¬† 0¬†¬† 7,8G¬† 0 crypt 
‚ĒĒ‚ĒÄsda1

BLKid sind die IDs der Filesystem selbst, also von / , von /home oder /boot . Ein Ext3/4, BTRS usw. Filesystem erzeugt beim Formatieren eine BLKID f√ľr sich dieses Filesystem. Jedesmal, wenn die Partition neu formatiert wird, gibt es eine neue Nummer.

$ blkid
/dev/sda1: UUID="aee1b027-ebd7-4ad9-a0ea-0fc881193708" TYPE="ext4" PARTUUID="000c4469-01"
/dev/sda2: UUID="6d45b281-c56c-40f0-acf7-c3058d4d6913" TYPE="crypto_LUKS" PARTUUID="000c4469-02"
/dev/sda3: UUID="384d6b27-6263-4d53-bfce-e7e5bcd221b9" TYPE="crypto_LUKS" PARTUUID="000c4469-03"
/dev/sda5: UUID="7881f602-9462-497d-810a-7d6111ad6085" TYPE="crypto_LUKS" PARTUUID="000c4469-05"
/dev/sdc1: LABEL="Boot" UUID="221608f2-5914-4619-9ef7-6dfddf233fd4" TYPE="ext4" PARTUUID="0000a3dd-01"
/dev/sdc2: UUID="ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa" TYPE="crypto_LUKS" PARTUUID="0000a3dd-02"
/dev/sdc3: UUID="ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a" TYPE="crypto_LUKS" PARTUUID="0000a3dd-03"
/dev/mapper/luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa: UUID="e62edbbe-a1ae-4242-bca5-1249d6f2df67" TYPE="ext4"
/dev/mapper/luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a: UUID="46da0d80-21fb-45b7-8567-ba047de66cb6" TYPE="swap"
/dev/mapper/luks-7881f602-9462-497d-810a-7d6111ad6085: UUID="196a4455-7ccb-40e4-bc71-7b2929f29225" TYPE="ext4"
/dev/mapper/luks-6d45b281-c56c-40f0-acf7-c3058d4d6913: UUID="0fd1b33c-5a2e-421a-a872-7bfc784ea2cf" TYPE="ext4"
/dev/mapper/luks-384d6b27-6263-4d53-bfce-e7e5bcd221b9: UUID="0bb5a502-f854-4e40-a3bd-08c3a2e6bf22" TYPE="swap"

zu 2)
Jetzt schauen wir uns mal /etc/fstab und den Bootentry im Grub an :

$ cat /etc/fstab 

/dev/mapper/luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa /           ext4    defaults,x-systemd.device-timeout=0 1 1
UUID=221608f2-5914-4619-9ef7-6dfddf233fd4 /boot                   ext4    defaults        1 2
/dev/mapper/luks-7881f602-9462-497d-810a-7d6111ad6085 /sata_home  ext4    defaults,x-systemd.device-timeout=0 1 2
/dev/mapper/luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a swap        swap    defaults,x-systemd.device-timeout=0 0 0

Wie man in der FSTAB sehen kann, soll /boot √ľber die BLKID eingebunden werden.

Warum macht man das ?

Ganz einfach, weil die BLKID ( BlockID ) eindeutig ist, egal an welchem Port eines Controllers die Platte angebunden ist. Selbst wenn die per USB ins System eingeh√§ngt ist, kann man diese Partition referenzieren. Das alt bekannte Problem von fr√ľher, wenn sich die Plattenreihenfolge ge√§ndert hat, da√ü dann eine andere Platte das Bootdevice war, entf√§llt damit.

Wieso ist /boot √ľber BLK referenziert und / mit einer LUKS ID ?

Weil Boot nicht verschl√ľsselt ist. Das geht zwar auch, aber dann wird es haarig ūüėČ

Da in der FSTAB die BLKID enthalten ist und sich nach erneuten Anlegen des Filesystems eine neue BLKID ergibt, muß man also vor dem ersten Boot die /etc/fstab anpassen, sonst bootet der Rechner nicht mehr.

Der Grub-Booteintrag:

menuentry 'Fedora (4.10.6-200.fc25.x86_64) 25 (Twenty Five)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.10.6-200.fc25.x86_64-advanced-e62edbbe-a1ae-4242-bca5-1249d6f2df67' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='hd2,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 --hint-efi=hd2,msdos1 --hint-baremetal=ahci2,msdos1  221608f2-5914-4619-9ef7-6dfddf233fd4
        else
          search --no-floppy --fs-uuid --set=root 221608f2-5914-4619-9ef7-6dfddf233fd4
        fi
        linux /vmlinuz-4.10.6-200.fc25.x86_64 root=UUID=e62edbbe-a1ae-4242-bca5-1249d6f2df67 ro vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a rd.luks.uuid=luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa  rhgb quiet splash audit=0 rd.driver.blacklist=nouveau nouveau.modeset=0 
        initrd /initramfs-4.10.6-200.fc25.x86_64.img
}

Wie man hier unschwer erkennen kann, kommt die BLKID auch im Bootentry vom Bootloader vor, was verst√§ndlich ist, weil der sonst nicht wei√ü welche Platte er booten sollte ūüėČ

Zudem sind hier die zum Systemstart zu entschl√ľsselnden¬† LUKS Partitionen enthalten. Zudem ist die ROOT Partition mit angegeben, die auch √ľber die BLKID referenziert wird.

Wie stellen wir jetzt aber die Bootpartition wieder her ?

Am einfachsten mit einer LiveCD vom gleichen Distributor . Dann formatieren wir die Bootpartition, so da√ü diese leer ist und legen uns die BLKID bereit. Folgende Schritte f√ľhren dann zum Ziel:

  1. Systempartition mounten
  2. DEV und PROC in die Systempartition mounten
  3. BOOT in die Systemplatte mounten
  4. CHROOT in die Systemplatte machen
  5. Bisherige Kernel finden
  6. Kernel neu installieren

Das sieht dann so aus ( nat√ľrlich haben Sie andere Partitionen als ich: SDC2 ist Root, SDC1 ist Boot ). Vorher zum Rootuser werden ( su root ) :

mount /dev/sdc2 /media
mount -t devtempfs devtempfs   /media/dev
mount -t procfs procfs /media/proc
mount -t ext4 /dev/sdc1 /media/boot
chroot /media/

Jetzt befinden wir uns im System des normalen Rechners, so da√ü wir alles so tun k√∂nnen, als wenn er normal gebootet h√§tte ( ohne Desktop nat√ľrlich ) . Wir bekommen die Kernel raus die drauf waren :

rpm -qa | grep kernel-core

und installieren die neu:

dnf reinstall kernel-core-*

Das sind nat√ľrlich Anweisungen f√ľr Fedora/RedHat Systeme, hier bitte die passenden f√ľr Eure Distribution w√§hlen. Nat√ľrlich kann man das Raussuchen der Kernels auch weglassen, da ist ja nur eine Info f√ľr Euch, damit Ihr seht, ob es stimmt. Nun noch die GRUB Boot Konfiguration neu erzeugen und der Rechner sollte wieder starten:

grub2-install /dev/sdc
grub2-mkconfig -o /boot/grub2/grub.cfg

Das Anpassen von /etc/fstab sollte man nat√ľrlich jetzt auch machen, sonst gehts nicht ūüėČ

Wer unerfindliche Probleme mit seinem GRUB Bootentry hat, dem könnte der Beitrag helfen. Ich mußte auch Linux16 durch Linux ersetzen, damit es wieder funktioniert.

Ich kann allen nur nochmal nahe legen, das PDF unten auf einem USB Stick zu sichern, damit Ihr das im Notfall parat habt. Au√üerdem sind in dem PDF noch viele andere Infos zum Thema aufgef√ľhrt und einige intensiver heraus gearbeitet.

PDF zum Download: LUGBS-Filesystemmeltdown

LibreOffice doch keine Alternative zu OpenOffice ?

Wer von LibreOffice entt√§uscht ist und lieber OpenOffice benutzen will, ich kann es verstehen. Man sollte ja annehmen, da√ü LibreOffice als „das“ gepflegtere Officepaket weniger Probleme h√§tte, ergo auch „kompatibler“ ist. Leider ist das nicht so. Meine Fedora LibreOfficeversion konnte genau „gar kein“ Dokument √∂ffnen und ist dabei auch noch laufend abgeschmiert. Da das Update von Fedora 23 auf 24 auch noch meine OpenOffice Installation ungefragt durch LibreOffice ersetzt hat, ist es Zeit f√ľr einen Neustart.

Erstmal weg mit der Zwangsbegl√ľckung

Zun√§chst l√∂schen wir mal LibreOffice, weil es sich mit einer RPM basierten Installation von OpenOffice beissen w√ľrde:

dnf erase "libreoffice*"

Dann laden wir uns OpenOffice von einem Mirror herunter:

http://ftp-stud.hs-esslingen.de/pub/Mirrors/ftp.apache.org/dist/openoffice/4.1.3/binaries/de/Apache_OpenOffice_4.1.3_Linux_x86-64_install-rpm_de.tar.gz
http://ftp-stud.hs-esslingen.de/pub/Mirrors/ftp.apache.org/dist/openoffice/4.1.3/binaries/de/Apache_OpenOffice_4.1.3_Linux_x86_langpack-rpm_de.tar.gz

In der Version ist der letzte Hotfix auch drin, also kann das ohne weiteres installiert werden.

Dazu legt Ihr am besten einen leeren Ordner an, z.B. Programme/OpenOffice :

tar xzvf Apache_OpenOffice_4.1.3_Linux_x86_langpack-rpm_de.tar.gz
tar xzvf Apache_OpenOffice_4.1.3_Linux_x86-64_install-rpm_de.tar.gz

Dann wechselt hier in das Verzeichnis „de/RPMS“ (cd de/RPMS) und f√ľhrt den Befehl aus:

sudo dnf install *x86_64.rpm ./desktop-integration/openoffice4.1.3-redhat-menus-4.1.3-9783.noarch.rpm

Das installiert die 64Bit Version von OpenOffice. Wer die 686er Version braucht, muß das etwas anpassen.

Kaum das OpenOffice korrekt installiert ist, kann man auch wieder Excel 2007 Dokumente öffnen, die man leider im Geschäftsleben braucht.

Jetzt die Fragen an Euch:

Welche Probleme habt Ihr mit Eurem Officepaket ?
Funktioniert Libre bei Euch sauber, oder seid Ihr auch auf OpenOffice angewiesen ?Misf√§llt Euch der Startbildschirm von Libre auch so wie mir ? Der sieht irgendwie „Billig“ aus.

Ich bin gespannt auf Euren Input.