Funktionsbereites FHEM "from scratch" in 12 Schritten und weniger als 15 Minuten

[betateilchen]

Voraussetzungen für den heute real durchgeführten Test mit Stoppuhr:

• Raspberry Pi 3 - Model B
• Sandisk MicroSD 8GB
• RASPBIAN JESSIE LITE - Release date:2016-05-10 - Kernel version:4.4 von raspberrypi.org
• Beschreiben der SD Karte erfolgte auf einem MacBook Air mittels dd/li]
  

1. Image herunterladen (03:11), entpacken (00:20) und auf SD Karte schreiben (01:45) ^*


2. optional: WLAN konfigurieren (00:30)

• SD Karte irgendwo mounten
• /etc/wpa_supplicant/wpa_supplicant.conf bearbeiten

EDIT vom 14.08.2017:

• bei aktuellen raspbian Versionen genügt es, die wpa_supplicant.conf in das /boot Verzeichnis der neu erstellten SD Karte zu legen

3. SD Karte in Raspberry stecken und starten  (00:30)


4. ssh auf den Raspberry (00:10)

EDIT vom 14.08.2017:

• bei aktuellen raspbian Versionen muss eine leere Datei mit dem Namen ssh in das /boot Verzeichnis der neu erstellten SD Karte gelegt werden, damit SSH überhaupt freigegeben wird.

5. Zusätzlich benötigte Pakete installieren (03:03)

Code Auswählen Erweitern


   apt-get update

   apt-get -y install perl-base libdevice-serialport-perl libwww-perl libio-socket-ssl-perl libcgi-pm-perl libjson-perl
   sqlite3 libdbd-sqlite3-perl libtext-diff-perl libtimedate-perl libmail-imapclient-perl libgd-graph-perl libtext-csv-perl
   libxml-simple-perl liblist-moreutils-perl ttf-liberation libimage-librsvg-perl libgd-text-perl libsocket6-perl
   libio-socket-inet6-perl libmime-base64-perl libimage-info-perl libarchive-extract-perl libusb-1.0-0-dev git subversion telnet



6. Aktuelles fhem aus SVN holen (00:30)

Code Auswählen Erweitern


   cd /opt
   svn checkout https://svn.fhem.de/fhem/trunk/fhem fhem



7. Benutzer fhem anlegen und fhem Rechte anpassen (00:30)

Code Auswählen Erweitern


   useradd --system --home /opt/fhem --gid dialout --shell /bin/false fhem
   chown -R fhem:dialout /opt/fhem



8. init-Skript an die richtige Stelle kopieren und ausführbar machen (00:20)

Code Auswählen Erweitern


   cp /opt/fhem/contrib/init-scripts/fhem.3 /etc/init.d/fhem
   chmod a+x /etc/init.d/fhem



9. init-Skript bearbeiten (wichtig!) (00:15)

   Die folgenden Zeilen in der /etc/init.d/fhem müssen entfernt oder auskommentiert werden:

Code Auswählen Erweitern


   if test "$2" != "noaptmark"; then
      apt-mark hold fhem > /dev/null
   fi



10. init-Skript in rc-Steuerung aufnehmen (00:15)

Code Auswählen Erweitern


   update-rc.d fhem defaults

   

11. Raspberry neu starten (00:20)


12. mit fhem verbinden und einen cmdalias für update anlegen, damit das update künftig direkt aus svn erfolgt (00:30)

Code Auswählen Erweitern


   define alias_update cmdalias update AS { `svn update /opt/fhem/` }
   save



Fertig

• raspi-config und apt-get upgrade können im Nachgang durchgeführt werden.
• Die gleichen Schritte funktionieren auch auf anderen Einplatinencomputern, dann natürlich mit dem jeweils passenden Image.

^* Weil Nachfragen zu der kurzen Zeit für das Schreiben des Images kamen:

Code Auswählen Erweitern


sh-3.2# dd bs=1m if=2016-05-10-raspbian-jessie-lite.img of=/dev/rdisk2
1322+0 records in
1322+0 records out
1386217472 bytes transferred in 105.653068 secs (13120466 bytes/sec)


[betateilchen]

Bei meinen "tatsächlichen" Installationen geht das Ganze noch schneller, da ich die Punkte 5-12 alle in ein Skript gesteckt habe, das nach dem erstmaligen Verbinden per SSH auf dem Zielgerät ausgeführt wird. In dem Skript sind die Punkt 12 und 11 natürlich vertauscht. Das "define" wird per echo in die fhem.cfg geschrieben und das save ist dann noch gar nicht nötig, da fhem zu diesem Zeitpunkt noch nicht läuft.

Code Auswählen Erweitern


#!/bin/bash

apt-get update && apt-get -y install perl-base libdevice-serialport-perl libwww-perl libio-socket-ssl-perl libcgi-pm-perl libjson-perl sqlite3 libdbd-sqlite3-perl libtext-diff-perl libtimedate-perl libmail-imapclient-perl libgd-graph-perl libtext-csv-perl libxml-simple-perl liblist-moreutils-perl ttf-liberation libimage-librsvg-perl libgd-text-perl libsocket6-perl libio-socket-inet6-perl libmime-base64-perl libimage-info-perl libarchive-extract-perl libusb-1.0-0-dev git subversion

cd /opt && svn checkout svn://svn.code.sf.net/p/fhem/code/trunk/fhem fhem

useradd --system --home /opt/fhem --gid dialout --shell /bin/false fhem
chown -R fhem:dialout /opt/fhem

cp /opt/fhem/contrib/init-scripts/fhem.3 /etc/init.d/fhem
sed -i /noaptmark/d /etc/init.d/fhem
sed -i /hold/d      /etc/init.d/fhem
sed -i /^fi$/d      /etc/init.d/fhem
chmod a+x /etc/init.d/fhem
update-rc.d fhem defaults

echo 'define alias_update cmdalias update AS { `svn update /opt/fhem/` }' >> /opt/fhem/fhem.cfg

reboot


Tipp: Wer Probleme beim Auschecken per svn hat, beispielsweise weil er hinter einer Firewall oder einem Proxy sitzt, wo svn:// als Protokoll geblockt wird, kann beim svn checkout auch einfach http:// anstatt svn:// verwenden.

[kvo1]

Hallo Udo,

danke für die coole Anleitung.

Hätte da mal eine "angrenzente Fragen" (etwas on top).

Gibt es für den RPI keine Perl-Version v5.20.2 ?  Habe nach update & upgrade immer noch v5.14.2 

[Otto123]

Bei meinem RPI 3 ist es mit Jessie die Version Perl     : v5.20.2

Ich glaube mit update & upgrade wird Perl nicht aktualisiert. --> cpan und dann upgrade?

Gruß Otto

[kvo1]

Hallo Otto,
danke.
Ich habe 2 CT´s , einer mit  Jessie oder andere mit Wheezy. Beide haben aber Version Perl     : v5.20.2

Dennach scheint es Version Perl     : v5.20.2 ja auch für Wheezy (was auf einem RPI läuft) zu geben !

grus nach Leizig
Klaus

[kvo1]

Hallo Otto,
danke.
Ich habe 2 CT´s , einer mit  Jessie oder andere mit Wheezy. Beide haben aber Version Perl     : v5.20.2

Dennach scheint es Version Perl     : v5.20.2 ja auch für Wheezy (was auf einem RPI läuft) zu geben !

grus nach Leizig
Klaus

--> cpan und dann upgrade?

..und das versteh ich zugegeben leider nicht wirklich 

[betateilchen]

..und das versteh ich zugegeben leider nicht wirklich 

Du musst nicht traurig sein, der Vorschlag war eh unsinnig. Wenn schon, solltest Du den raspi über ein dist-upgrade aktualisieren und nicht anfangen, Dich mit cpan rumzuschlagen.

Code Auswählen Erweitern


apt-get dist-upgrade


Welche perl Version in einer Distribution enthalten ist, entscheidet der publisher der Distribution. Man kann prinzipiell das perl alleine updaten, aber das ist nichts für Anfänger, die einfach nur mit ihrem raspi arbeiten wollen und auf ein stabil funktionierendes System angewiesen sind.

Im akuellen raspbian ist perl in der Version 5.20 enthalten.

Code Auswählen Erweitern


udo@fhem-rpi3:~ $ perl -v

This is perl 5, version 20, subversion 2 (v5.20.2) built for arm-linux-gnueabihf-thread-multi-64int
(with 81 registered patches, see perl -V for more detail)


[Wernieman]

cpan und Dist-Upgrade sind sogar zusammen etwas ... tödlich. dist-upgrade aktuallisiert alles, was dem System an Packeten bekannt ist. Die per cpan installierten Perl-Module sind aber dem System NICHT bekannt. Also sind diese alle veraltet ....

Deshalb auch per cpan nur im Notfall ein Perl-Modul installieren.

[kvo1]

apt-get dist-upgrade

hatte ich natürlich schon gemacht !

Dann wird das wohl an meinem zu alten System liegen !

Code Auswählen Erweitern

pi@lmsraspi ~ $ perl -v

This is perl 5, version 14, subversion 2 (v5.14.2) built for arm-linux-gnueabihf-thread-multi-64int
(with 89 registered patches, see perl -V for more detail)


Vielleicht lasse ich das einfach bei v5.14.2 , oder gibt es wichtige Gründe auf v5.20.2 upzudaten ?

[Wernieman]

welche Version hast Du denn?

Code Auswählen Erweitern

cat /etc/issue
cat /proc/version
uname -a
lsb_release -a

[Otto123]

Du musst nicht traurig sein, der Vorschlag war eh unsinnig. Wenn schon, solltest Du den raspi über ein dist-upgrade aktualisieren und nicht anfangen, Dich mit cpan rumzuschlagen.

Sorry, irgendwo habe ich auf die Schnelle gefunden, dass es so gehen soll. Man sollte eben nichts ungeprüft weiter posten. Normalerweise mache ich das auch nicht - war mir wieder eine Lehre.  Es gibt kein Smily mit Asche auf dem Haupt.

Aus meiner Sicht gibt es keinen Grund Perl extra zu aktualisieren. Ich glaube die Chance, dass dabei etwas nicht mehr geht ist genauso hoch wie auf Jessie zu gehen und dann geht auch noch alles. 
Und auf Jessie gehen ist sicher viel viel schneller, hat betateilchen ja eindrucksvoll beschrieben.

Ich glaube allerdings auch dist-upgrade ist "mühsam". Ich finde ein aktuelles Image und anschließend per Script alles drauf ziehen (mit apt-get update und apt-get upgrade) ist viel schneller und sauberer. Auf den Rest an Aktualität können sicher die meisten verzichten.
Und außerdem weiß man dann auch immer wie backup und restore funktioniert 

Schönen Abend aus der Sonne in Leipzig 

Otto

[kvo1]

Hallo Wernieman,

welche Version hast Du denn?

Code Auswählen Erweitern

cat /etc/issue
cat /proc/version
uname -a
lsb_release -a

Code Auswählen Erweitern

cat /etc/issue
Raspbian GNU/Linux 7 \n \l

Code Auswählen Erweitern

cat /proc/version
Linux version 4.1.19-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #858 SMP Tue Mar 15 15:56:00 GMT 2016

Code Auswählen Erweitern

uname -a
Linux lmsraspi 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux

Code Auswählen Erweitern

lsb_release -a
-bash: lsb_release: Kommando nicht gefunden.

Danke

[Wernieman]

@Otto:
Wollten wir nicht mal ein Bierchen trinken? 

Generell:
es gibt grooooße Unterschiede zu "apt-get update" und "apt-gt dist-upgrade".

Bei ersteren werden nur die Updates (Security) der Installierten Distri upgedatet, beim 2. die darunterliegende Distribution. Mann sollte sich nicht auf 1. verlassen, da jede Distri nur eine begrenzte Updatezeit hat. Wenn diese verstrichen ist, gibt es keine security-updates mehr!

BTW:
Auch bei Ubuntu LTS besteht die Security-Update-Zeit nur fürs "main", alles andere hat eine viel kürzere Updatezeit.

@kvo1:
Meines Beschränkten Wissens nach, ist dieses aktuell noch gut. Allerdings solltest Du Dich (wie viele andere) schon nächstes Jahr überlegen, ob eventuell ein upgrade zu neueren Versionen sinnvoll ist ...

[kvo1]

@kvo1:
Meines Beschränkten Wissens nach, ist dieses aktuell noch gut. Allerdings solltest Du Dich (wie viele andere) schon nächstes Jahr überlegen, ob eventuell ein upgrade zu neueren Versionen sinnvoll ist ...

wird wohl so kommen, zumal ich schon einen CT mit Jessie habe ! Danke für Mühe !

[frank]

feine anleitung, besonders das "24h-svn-update". 

[frank]

ich musste heute meinen pi3, den ich nach dieser anleitung erfolgreich aufgesetzt hatte, vom strom trennen, da ich nicht mehr über wlan zugreifen konnte (das ist aber erst einmal hoffentlich ein anderes thema). das problem ist, dass fhem nicht mehr automatisch starten will.

das fhem-init-script ist vorhanden

Code Auswählen Erweitern

-rwxr-xr-x  1 root root 1.5K Jul 10 12:01 fhem
und ich kann es auch über

Code Auswählen Erweitern

root@raspberrypi:/home/pi# /etc/init.d/fhem start
starten, stoppen oder den status erfragen.

soweit ich bisher verstanden habe, wird mit punkt 10. dieser anleitung

Code Auswählen Erweitern

   update-rc.d fhem defaults
der automatische start des scripts dem system bekannt gemacht.

ich denke, wenn ich diesen befehl erneut ausführe, dass das automatische starten von fhem wieder funktionieren würde. bevor ich das tue, würde ich aber gerne herausfinden, ob es wirklich daran liegt, um eventuell verstehen zu können, warum der start nicht mehr funktioniert.

meine frage ist also: wo und/oder wie finde ich infos auf meinem pi, was hier falsch laufen könnte?

gruss frank

[Wernieman]

Welche Version von welcher Distri hast Du am Laufen?

Eventuell könntest Du auch mittlerweile eine "systemd"-Version haben ...

[Hollo]

...meine frage ist also: wo und/oder wie finde ich infos auf meinem pi, was hier falsch laufen könnte?

Wenn das init-Script vorhanden ist und Du alles nach Anleitung gemacht hast, sollten auch die Einträge in den verschiedenen Runlevel vorhanden sein.

Du könntest das z.B. mal mit einem Blick in /etc/rc2.d kontrollieren; da sollte es dann ein @S16fhem (wobei die Zahl evtl. auch anders sein könnte) geben.

Wenn Du die Kiste neu gestartet hast und es da Probleme gab, findest Du evtl. auch Hinweise, wenn Du mal /var/log/syslog kontrollierst.

P.S.: Du solltest zunächst den Tipp von Wernieman klären... nutzt Du sysvinit oder systemd..?
 

[frank]

also im prinzip alles wie in der anleitung mit jessie lite. ausser der sd karte, da ich nur eine 32GB hatte. 

Code Auswählen Erweitern

root@raspberrypi:/home/pi# cat /etc/debian_version
8.0
root@raspberrypi:/home/pi# cat /proc/version
Linux version 4.4.11-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #888 SMP Mon May 23 20:10:33 BST 2016
root@raspberrypi:/home/pi# cat /etc/issue
Raspbian GNU/Linux 8 \n \l

root@raspberrypi:/home/pi# uname -a
Linux raspberrypi 4.4.11-v7+ #888 SMP Mon May 23 20:10:33 BST 2016 armv7l GNU/Linux


systemd habe ich nie "wissentlich" genutzt. ich hatte hier lediglich eine anleitung gesehen, ich glaube auch von betateilchen, und habe sie aber nicht benutzt, da mir die vor-/nachteile unklar waren/sind. vor ca. 1 monat hat der autostart bei tests auch problemlos funktioniert. seitdem musste nicht neu gestartet werden. und nun "essig".

rc2.d

Code Auswählen Erweitern

root@raspberrypi:/home/pi# ls -ahl /etc/rc2.d
total 12K
drwxr-xr-x  2 root root 4.0K Jul 10 13:27 .
drwxr-xr-x 84 root root 4.0K Aug 22 16:32 ..
-rw-r--r--  1 root root  677 Apr  6  2015 README
lrwxrwxrwx  1 root root   18 May 27 13:06 S01bootlogs -> ../init.d/bootlogs
lrwxrwxrwx  1 root root   16 May 27 13:15 S01dhcpcd -> ../init.d/dhcpcd
lrwxrwxrwx  1 root root   14 Jul 10 12:02 S01fhem -> ../init.d/fhem
lrwxrwxrwx  1 root root   14 May 27 13:06 S01motd -> ../init.d/motd
lrwxrwxrwx  1 root root   17 May 27 13:07 S01rsyslog -> ../init.d/rsyslog
lrwxrwxrwx  1 root root   22 May 27 13:09 S01triggerhappy -> ../init.d/triggerhappy
lrwxrwxrwx  1 root root   14 May 27 13:07 S02cron -> ../init.d/cron
lrwxrwxrwx  1 root root   14 May 27 13:13 S02dbus -> ../init.d/dbus
lrwxrwxrwx  1 root root   24 May 27 13:14 S02dphys-swapfile -> ../init.d/dphys-swapfile
lrwxrwxrwx  1 root root   13 May 27 13:13 S02ntp -> ../init.d/ntp
lrwxrwxrwx  1 root root   15 Jul 10 13:27 S02rsync -> ../init.d/rsync
lrwxrwxrwx  1 root root   13 May 27 13:42 S02ssh -> ../init.d/ssh
lrwxrwxrwx  1 root root   22 May 27 13:13 S03avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx  1 root root   19 May 27 13:14 S03bluetooth -> ../init.d/bluetooth
lrwxrwxrwx  1 root root   18 May 27 13:13 S04plymouth -> ../init.d/plymouth
lrwxrwxrwx  1 root root   18 May 27 13:13 S04rc.local -> ../init.d/rc.local
lrwxrwxrwx  1 root root   19 May 27 13:13 S04rmnologin -> ../init.d/rmnologin
das sollte dann wohl ok sein.

in /var/log/syslog sind allerdings haufenweise einträge mit systemd, bsp:

Code Auswählen Erweitern

Aug 27 11:45:39 raspberrypi systemd[1]: Started /etc/rc.local Compatibility.

und nun? mal sehen, ob ich hier noch was finde.

[frank]

syslog sagt nach reboot folgendes

Code Auswählen Erweitern

Aug 27 14:26:52 raspberrypi systemd[1]: Starting LSB: FHEM server...
Aug 27 14:26:52 raspberrypi fhem[395]: Starting fhem...
Aug 27 14:26:53 raspberrypi systemd[1]: Started LSB: FHEM server.

und systemctl

Code Auswählen Erweitern

root@raspberrypi:/home/pi# systemctl status fhem.service
● fhem.service - LSB: FHEM server
   Loaded: loaded (/etc/init.d/fhem)
   Active: active (exited) since Sat 2016-08-27 14:26:53 CEST; 43min ago
  Process: 395 ExecStart=/etc/init.d/fhem start (code=exited, status=0/SUCCESS)

Aug 27 14:26:51 raspberrypi fhem[395]: Starting fhem...
Aug 27 14:26:53 raspberrypi systemd[1]: Started LSB: FHEM server.

allerdings kommt gleichzeitig

Code Auswählen Erweitern

root@raspberrypi:/home/pi# /etc/init.d/fhem status
fhem is not running

fhem scheint nicht zu laufen, da meine hzgsventile alle "eingeschlafen" sind. und über den browser komme ich auch nicht an fhem.

wie muss ich das verstehen? hat systemd das fhem-script "gekapert", aber über systemd kann das fhem-script fhem nicht starten? was sollte ich jetzt tun? grübel, grübel... die fritzbox wirft mir schon komische blicke rüber. 

[frank]

obwohl es keine fhem.service unit-datei gab, hat systemd immer die fhem-script datei gestartet, seltsam... .

ich habe es jetzt so gelöst, dass ich systemd "richtig" eingebunden habe. autostart funktioniert jetzt wieder, obwohl systemd noch etwas meckert, wie hier beschrieben => https://forum.fhem.de/index.php/topic,54271.msg485358.html#msg485358.

könnte es sein, dass durch installation von cpan mit anschliessender installation eines sip-moduls über cpan so etwas passiert? apt-get hatte in diesem fall leider nicht funktioniert, da auf eine "tote" adresse zugegriffen wurde.

danke für die unterstützung.

[Wernieman]

Eigentlich nicht ... cpan hat den Nachteil, das bei einem Update des Systemes alles über cpan NICHT upgedatet wird ...

Was mich aber wundert:

apt-get hatte in diesem fall leider nicht funktioniert, da auf eine "tote" adresse zugegriffen wurde.

So etwas hatte ich noh nie .. bist Du Dir sicher, das apt funktioniert?
Welche "Quellen" hast Du eingebunden?

[frank]

Und wenn Du das passende Modul zur Distri nimmst?

Code Auswählen Erweitern

apt-get install libnet-sip-perl

Code Auswählen Erweitern

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libnet-dns-perl libnet-ip-perl
The following NEW packages will be installed:
  libnet-dns-perl libnet-ip-perl libnet-sip-perl
0 upgraded, 3 newly installed, 0 to remove and 25 not upgraded.
Need to get 330 kB/583 kB of archives.
After this operation, 1,406 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Err http://mirrordirector.raspbian.org/raspbian/ jessie/main libnet-dns-perl armhf 0.81-2
  404  Not Found [IP: 5.153.225.207 80]
E: Failed to fetch http://mirrordirector.raspbian.org/raspbian/pool/main/libn/libnet-dns-perl/libnet-dns-perl_0.81-2_armhf.deb  404  Not Found [IP: 5.153.225.207 80]

E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

sonst funktioniert apt immer, nur hier nicht. über cpan wurde dann wie wild kopiert und kompiliert. das hat mich stutzig gemacht.

[Wernieman]

welche Sourcen hast Du eingebunden?

Code Auswählen Erweitern

cat /etc/apt/sources.list

[frank]

alles original

Code Auswählen Erweitern

root@raspberrypi:/home/pi# cat /etc/apt/sources.list
deb http://mirrordirector.raspbian.org/raspbian/ jessie main contrib non-free rpi
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
#deb-src http://archive.raspbian.org/raspbian/ jessie main contrib non-free rpi

[Wernieman]

Ich kenne jetzt die möglichen Sourcen für RasPi nicht, aber könntest Du einen "anderen Anbieter" einbinden?

[frank]

das überfordert leider meinen derzeitigen wissensstand. 
trotzdem schön, jetzt zu wissen, dass man da dran drehen könnte. 

edit:
ich habe mal die adresse auf das hauptarchiv gesetzt. brachte nichts, also wieder zurück.

Code Auswählen Erweitern

E: Unable to locate package libnet-sip-perl

da immer libnet-dns-perl hängen blieb, probierte ich es solo, worauf zusätzlich der entscheidende hinweis kam:

Code Auswählen Erweitern

E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
nach apt-get update hat es jetzt funktioniert. 

hier gibt es zur not eine liste aller mirrors für raspbian https://www.raspbian.org/RaspbianMirrors. ich denke mit dem mirrordirector sollte das aber "überflüssig" sein.

viel wichtiger wäre allerdings zu wissen, warum systemd den autostart von fhem gekapert hat.

gruss frank

[Wernieman]

Sorry, kann Dir da aus der ferne schlecht Debugtips geben.

[Paddinho]

2. optional: WLAN konfigurieren (00:30)

   - SD Karte irgendwo mounten
   - /etc/wpa_suppliant/wpa_suppliant.conf bearbeiten

wäre schön wenn du den Mount-Befehl hinschreiben könntest.
Ich krieg es unter OSX nicht hin die SD-Karten zu mounten um auf das Verzeichnis zugreifen zu können

ein diskutil list gibt folgendes aus:

Code Auswählen Erweitern

/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            999.3 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *15.9 GB    disk1
   1:             Windows_FAT_32 boot                    66.1 MB    disk1s1
   2:                      Linux                         1.3 GB     disk1s2

folgendes funktiont nicht:

Code Auswählen Erweitern

sudo mount -t msdos /dev/disk1s2 /users/xxx/sd
mount_msdos: Unsupported sector size (0)

/dev/disk1s1 lässt sich zwar über diesen Befehl mounten, allerdings handelt es sich hierbei nicht um die korrekte Partition

Ich vermute mal das Problem liegt am Dateisystem (Parameter -t), allerdings weiß ich nicht was ich hier angeben soll.

[betateilchen]

wäre schön wenn du den Mount-Befehl hinschreiben könntest.
Ich krieg es unter OSX nicht hin die SD-Karten zu mounten um auf das Verzeichnis zugreifen zu können
...
Ich vermute mal das Problem liegt am Dateisystem (Parameter -t), allerdings weiß ich nicht was ich hier angeben soll.

Es ist in diesem Fall völlig egal, was Du als Dateisystemt angibst, es wird nicht funktionieren, denn OSX kann von Haus aus nicht auf Linux Dateisysteme wie ext4 zugreifen. Man benötigt dazu Fremdsoftware z.B. Paragon ExtFS. Aber auch solche Tools sind mit Vorsicht zu genießen, wenn man tatsächlich in das "fremde" Dateisystem auch schreiben möchte.

Bei mir auf dem MacBook läuft ein Debian Jessie in einer VMware, damit kann ich Linux Dateisysteme einwandfrei bearbeiten.

[Paddinho]

Bei mir auf dem MacBook läuft ein Debian Jessie in einer VMware, damit kann ich Linux Dateisysteme einwandfrei bearbeiten.

ok, danke für die Antwort.
Werd mir über über Parallels Desktop auch mal eine Linux-VM einrichten und ausprobieren...

[Otto123]

2. optional: WLAN konfigurieren (00:30)

   - SD Karte irgendwo mounten
   - /etc/wpa_suppliant/wpa_suppliant.conf bearbeiten

Hallo,

ich möchte ich hier gerne aktuell etwas ergänzen, was Schritt 2. dieser Anleitung ungemein vereinfacht.
Seit irgendeiner der letzten Raspbian Versionen braucht man die wpa_suppliant.conf einfach nur ins /boot/ Verzeichnis zu legen.
Also nach dem Schreiben des Jessie Images auf die SD Card - noch vor dem ersten Start. Kein extra mounten.
Vorlage:

Code Auswählen Erweitern

country=DE
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
    ssid="<Netzwerkname>"
    psk="<Netzwerkschlüssel>"
}

Damit (und der leeren ssh Datei am gleichen Ort) gelingt es auch headless den Zero W in Betrieb zu nehmen. 

Gruß Otto

[papa]

Das SVN ist jetzt unter https://svn.fhem.de/fhem/trunk/fhem.
Kannst Du bitte mal den ersten Beitrag aktualisieren. Sonst muss ich beim nächsten Mal wieder nachdenken