Systemd mounted ein wichtiges Verzeichnis nicht mehr (Debian Jessie Mai 2016)
Nach einen Update wurde bei mir /usr nicht mehr automatisch und zur rechten Zeit eingehängt; dieser Mountpoint ist nicht ganz unwichtig ;-)
Alles meckern auf den systemd half nicht, seine Konfiguration war richtig, an der fstab habe ich auch seit einiger Zeit nichts geändert.
sysVinit lief ohne Probleme nur systemd macht zicken. Das große Netz wies wie immer Lücken auf, nach dem ich die Ergebnisse auf den letzten Monat eingrenzte,
fiehl mir die revidierte man-page von systemd.special auf.
Uups das Ding gibt es doch schon länger, wieso eine Revision???
Ein Blick in die Gegend, welche mein Problem betrifft, ergab:
initrd-fs.target
systemd-fstab-generator(3) automatically adds dependencies of
type Before= to sysroot-usr.mount and all mount points found in
/etc/fstab that have x-initrd.mount and not have noauto mount
options set.
local-fs.target
systemd-fstab-generator(3) automatically adds dependencies of
type Before= to all mount units that refer to local mount points
for this target unit. In addition, it adds dependencies of type
Wants= to this target unit for those mounts listed in /etc/fstab
that have the auto mount option set.
Was ist nun mit dem local-fs-pre.target, da sollen / und /usr eingebunden werden?? Mein /usr hat die Optionen: auto, rw, suid, nodev
Ok fahren wir das auto in die Garage und lassen nur rw, suid, nodev
Ein beherztes #>systemctl daemon-reload ## um die Generatoren anzuwerfen
und #>systemctl reboot
Nun sehet und staunet - es läuft :-)
VW-Scandal hin oder her, sowas muss doch nicht sein ,(
Samba Upgrade auf 4.2 - winbind spinnt (Debian Jessie April 2016)
apt-get will nicht upgraden da sich einige Ahängigkeiten auf 4.1 beziehen.
meine Lösung:
#> apt-get install --force-yes samba samba-common-bin samba-dsdb-modules winbind libnss-winbind libpam-winbind samba-libs winbind libwbclient0 libldb1 libsmbclient python-ldb python-samba
Danke Debian ,(
Trotz dynamischer Adresse erreichbar sein
Na gut, dynamische Adresszuweisungen sind nicht Linux-spezifisch,schuld drann sind unsere lieben Provider. Bei jeder neuen Einwahl ins Internet, einschalten des Modems aber spätestens einmal am Tag bekommt Otto Normalverbraucher eine neue IP-Adresse. Nun mag es Otto nicht stören, da gibt es aber noch solche wie Olke. Die haben sich zu Hause einen Server eingerichtet, der hält Kalender, Adressbücher, E-Mails, Lesezeichen, Browser Einstellungen.... synchron und bietet Dateizugriff aus der Fremde. Wer nun meint, dafür gibt es Google, Apple, Mozilla, Dropbox, Amazon, Flickr....... mag weiterhin ein sehr öffentliches Leben führen.
Die Anderen mögen mir folgen
Davical will sich mal wieder nicht aufsetzen lassen (Debian/Ubuntu - April 2015)
Irgentein Dist-Upgrade hat mal wieder die Installation zerschossen oder man will Davical auf einem anderen Server aufsetzen
Alles klappt ganz gut, bloß Davical ist nicht ansprechbar und die scripts funktionieren nicht.
dann machen wir eine Konsole auf und geben folgenes ein:
$> sudo bash
#> sudo -u postgres /usr/share/davical/dba/create-database.sh
#> sudo -u postgres /usr/share/davical/dba/update-davical-database --dbuser=postgres
#> exit
$> exit
jetzt sollte die Datenbank stehen :-) nur noch das Backup einspielen....
Davical versteht sich mit Android bzw. IOS nicht (Debian/Rasberian/Ubuntu - April 2015)
Ihr bekommt immer Fehler 500 im Apache
PROPFIND ..... 500 421 "-" "CalDAV Sync Adapter (Android) https://github.com/gggard/AndroidCaldavSyncAdapater Version:1.8.1"
die ausgelieferte Version von php-awl ist buggy :-(
Wenn nicht schon da, dann git installieren #>apt-get install git
in das Verzeichnis wechseln, in das ihr sonst auch eure Test-/ Programmversionen läßt z.B. $>cd ~/test
$> git clone git://repo.or.cz/awl.git # das Aktuelle holen
$> cd awl
$> make # irgentwelche doc-Fehler sind uninteressant
#> mv /usr/share/awl /usr/share/awl.org # sichern ist immer besser
#> mkdir /usr/share/awl
#> cp -R ./inc /usr/share/awl
#> cp -R ./dba /usr/share/awl
Nun kann man seinen Kalender auch wieder auf dem Handy mitschleppen :-)
Funktioniert nicht? Habt ihr schon die Legende, unten auf der Seite, gesehen :-P
Mit dem Nexus 4 kann man nicht telefonieren - kein Ton (Cyanogenmod 11 - Juli 2015)
Google nervt schon eine Weile mit dem Update auf Android 5.0 ....5,0,1....5.1, ich hab es probiert aber Google mag keine Geräte mit root-Zugriff und ich keine ohne ;-) Da dieses ohnehin das letztes Update für das Nexus 4 sein wird und ich für das "unrooten" das Handy putzen darf, gehe ich gleich auf Cyanogenmod .
Ist ja auch so schön einfach , ein Programm auf das Handy und eines auf meine Spiel-Installationspartition ( heisst Steam oder Windows oder so... zum Arbeiten jedenfalls unbrauchbar instabil ).
Ein regnerischer Sommertag, Urlaub ist auch ohne Handy schöner, also ans Werk, der ganze Spass hat keine 20min gedauert. Das Aufsetzen, Backups einspielen, Konten einrichten .... nochmal zwei Stunden. Nun bin ich froh und mit einem neuen Betriebssystem versehen; kann chatten, Mails schicken, Blitzer angucken alles schön ---- bis ein Anruf kam :( ich hörte nichts, auch beim nächsten - Ruhe pur.
Im grossen Netz ist das Problem wohl bekannt und einige Tickets wurden beim Cyanogen-Team auch schon angelegt ( und wieder abgelegt, weil angeblich unschuldig ;-). Dann gibt es noch andere Tips mit Wlan-ausmachen und neu starten, Play-Store downgraden etc., etc..
Doch auch im größten Netz findet sich hin und wieder ein Golfisch wie dieser . Ich soll also eine APP names Disable Service installieren, sie läuft nur auf "gerooteten" Geräten - hab ich.
Die App starten und durch die Menüs hangeln:
System (steht oben) -> Google Play-Dienste => CheckInService Haken entfernen
Neu Starten
Nun können mich alle wieder nerven ;-)
Die grafische Oberfläche startet obwohl man im Multiuser.target ohne selbige booten will (Debian Jessie / März 2015)
Ich bin von der Debian basierten Mint Distribution zu Debian Jessie gewechselt. War kein großes Ding, da diese auf den gleichen Quellen basieren. Ein paar Reposeries ändern und schon hatte ich Jessie ungefiltert.
(
Vorsicht wenn man reiserfs verwendet und reiserfsck über einen Mapper gestartet wird!
Dann fehlt das Program in der Ramdisk! Ein Glück das wir immer ein Rettungssystem auf den Platten haben :-|
in der Datei: /usr/share/initramfs-tools/hooks/fsck
die Zeilen
..
copy_exec /sbin/fsck
copy_exec /sbin/logsave
copy_exec /sbin/sulogin
# um die Zeile
copy_exec /sbin/reiserfsck
# erweitern
# und #>update-initramfs #ausführen
)
Genug von dieser Gemeinheit, kommen wir zur nächsten ,-)
Jessie verwendet den system daemon zum starten des Systems!
Eigentlich schon, aber die SystemV-init-Dateien sind noch voll aktiv, brauchen aber einen Header welcher die Runlevel, in denen sie laufen oder enden sollen, definiert. (siehe $>man insserv).
Debian definiert die Runlevel 2 bis 5 als Muti-User, wobei Runlevel 5 zusätzlich die grafische Oberfläche startet. Ausgehend von einer sauberen Systemd-Umgebung habe ich dann brav das /lib/systemd/system/runlevel2.target nach /etc/systemd/system/default.target verlinkt. Nach dem nächsten Booten startete wieder die grafische Oberfläche :,(
Dann gab ich Grub noch den Parameter "systemd.unit=runlevel2.target" mit auf den Weg, der Erfolg blieb aus :,( :,(
Aber das Ding mit dem Runlevel2 ging mir nicht aus dem Kopf, so untersuchte ich mal diesen Wust. Systemd abeitet hier nur als Aufgenbenverteiler für Init, damit die Prozesse parallel laufen können, der Rest ist ein aufgebohrtes SystemV. Das meiste vom Systemd liegt brach.
Dann beschäftigen wir uns mal mit dem SystemV-Teil und dem Verzeichnis /etc/init.d
Zwei Dateien sind bei mir für den Start den grafischen Oberfläche verantwortlich:
x11-common
mdm (in anderen Systemen kdm, gdm.....)
Jetzt mal x11-common im Editor betrachten:
### BEGIN INIT INFO
# Provides: x11-common
# Required-Start: $remote_fs
# Required-Stop: $remote_fs
# Default-Start: S
# Default-Stop:
### END INIT INFO
Das gefällt insserv bestimmt nicht, X11 soll immer starten aber nie enden, dann berichtigen wir das mal nach den Vorgaben von Debian - nur Runlevel 5 ist grafisch und sechs Runlevel gibt es hier.
### BEGIN INIT INFO
# Provides: x11-common
# Required-Start: $remote_fs
# Required-Stop: $remote_fs
# Default-Start: 5
# Default-Stop: 0 1 2 3 4 6
### END INIT INFO
Nun kommen wir zum Display-Manager mdm oder kdm, gdm...
### BEGIN INIT INFO
# Provides: mdm
# Should-Start: console-screen kbd acpid dbus hal network-manager
# Required-Start: $local_fs $remote_fs x11-common
# Required-Stop: $local_fs $remote_fs
# Default-Start: 5
# Default-Stop: 0 1 2 3 4 6
# Short-Description: MDM Display Manager
# Description: Debian init script for the MDM Display Manager
### END INIT INFO
sollte zum Schluß da stehen
Jetzt noch in die Runlevel eintragen lassen, erst das alte raus, bitte die Reihenfolge beachten:
#>insserv -r mdm # bzw. kdm, gdm, xdm....
#>insserv -r x11-common
# nun wieder rein:
#>insserv x11-common
#>insserv mdm # bzw. kdm, gdm, xdm....
Jetzt sollte nach dem Neustart, das bunte Zeug nicht mehr automatisch Starten :-)
Legende
$> echo "ist die Eingabe für einen normalen Nutzer"
#> echo "ist die Eingabe für root, als normaler Benutzer sudo vor den Befehl schreiben"
#> echo "oder vorher mit $>sudo bash # in die root-shell wechseln"
E-Mail ( kein Spam) an
olke
a t
olke [Punkt] de
Alle die es mögen, senden bitte
unerwünschte Werbung und sonstige Angebote an
mag_ich_nicht@spam.la
