Raspberry Stretch update

Begonnen von AnBad, 07 Juni 2019, 06:39:39

Vorheriges Thema - Nächstes Thema

AnBad

Hallo,
ich habe vor einigen Tagen auf meinem Rasberry ein Systemupdate des bereits installierten Stretch gemacht. Dabei hat es mir tats. einige Funktionen in FHEM "auseinander gehauen".

Nun muss ich mittels Sicherheitskopie das gesamte System inkl. FHEM wieder herstellen. Das ist soweit kein Problem.

Doch welche update-Befehle lässt bzw. kann den Raspberry/Stretch machen lassen, ohne das was passiert? Oder lässt man das System am besten generell mehrere Jahre unangetastet.

sudo rpi-update
sudo apt-get update
sudo apt-get upgrade
sudo full-upgrade


Vielen Dank!!
Grüße
Michael

Frank_Huber

Was hat es denn alles zerlegt?
War es das Jessie auf Stretch update?

Gesendet von meinem Telekom Puls mit Tapatalk


CoolTux

Was genau macht denn der Befehl full-update. Ist ja kein apt-get Befehl.
Zerlegen sollte es, sofern sauber durchgelaufen, gar nichts. Zu mindest nicht die apt-get Befehle.
Was dieses full-update macht wäre aber Interessant. Eventuell macht das ein Distributionsupdate.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

rr725

hab es vor geraumer zeit auch machen wollen- auf Streich zu gehen.....
bei mir lief anschliessend auch diverses nicht mehr. da ich auch einen Apache Server installiert hatte liefen auch keine php Scripte mehr
man wurde echt gezwungen sich intensivst mit dem Changelog zu befassen. es dauerte ewig bis ich den Punkt fand, dass intern die Ports geändert wurden.
und da gab es mehrere Sachen.
ich bin auf  geblieben und fahre darauf hier und da ein Update.
obwohl..... meine  Installation läuft seit geraumer zeit stabil und zuverlässig. da es mit  in letzter zeit auch div. Probleme nach den FHEM Updates gab (spez. mit den homematicmodulen) habe ich mir vorgenommen die Finger davon zu lassen und nur noch Sicherungen anzulegen.

dkreutz

Meinem gesunden Raspbian-Halbwissen nach ist ein
sudo rpi-update
nur in äußerst seltenen Fällen angesagt (wennn man die neuesten Kernel-Entwicklungen haben möchte, die noch nicht im stable-Release sind).

sudo full-upgrade müsste wohl eher sudo apt-get full-upgrade lauten und ist eine Variante von sudo apt-get dist-upgrade.
Raspberry Pi3B+ (Bullseye) / JeeLink868v3c (LaCrosse), nanoCUL433 (a-culfw V1.24.02), HM-MOD-UART (1.4.1), TEK603, MapleCUL / diverse Sensoren/Sender/Aktoren von Technoline, Intertechno, Shelly, Homematic und MAX!, Froggit Wetterstation, Luftdaten.info / Autor des fhem-skill für Mycroft.ai

Wernieman

sudo rpi-update
sudo apt-get update
sudo apt-get upgrade
sudo full-upgrade

rpi-update - Installiert "Develop"-RasPi Kernel. Da die Standard Kernel auch über ein "apt-get upgrade" kommen ... wozu?
apt-get update - Aktualisiert nur die Packetdatenbank, also unkritisch
full-upgrade - wie meine Vorredner schreiben .. was ist das?

apt-get upgrade - Genau das Aktualisiert die Pakete. Im Normalfall unkritisch, man sollte sich aber VORHER angucken, WAS upgedatet wird.

Prinzipiell ist eher ein anderes Problem, wen man Module per CPAN installiert hat. Wenn dann "apt-get upgrade" ein update von perl macht ....... muß man alle per cpan-installierte Pakete nachträglich updaten. ich gehe davon aus (Aktuell scheint meine Glaskugel zu funktionieren), das Du genau in diese Falle gegangen bist.

Prinzipiell:
- Ein Normales Update sollte unkritisch sein. Ein Sprung der Distribution dagegen ...
- Keine Updates sind aus Sicherheitssicht, Software ist nicht Fehlerfrei, keine Lösung.

- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Frank_Huber

Zitat von: CoolTux am 07 Juni 2019, 07:18:55
Was genau macht denn der Befehl full-update. Ist ja kein apt-get Befehl.
Zerlegen sollte es, sofern sauber durchgelaufen, gar nichts. Zu mindest nicht die apt-get Befehle.
Was dieses full-update macht wäre aber Interessant. Eventuell macht das ein Distributionsupdate.
Bei Jessie --> Stretch kann es durch den Kernbel Update das WiringPI und damit GPIO zerlegen.
Lösung ist dann manuell auf nen alten Kernel zurück.
Hatte ich mal echt Freude damit vor langer Zeit. :-)

Beta-User

Wundert mich irgendwie, dass dazu noch keiner was gesagt hat:
Zitat von: AnBad am 07 Juni 2019, 06:39:39
Oder lässt man das System am besten generell mehrere Jahre unangetastet.
Das ist dann eine super Idee, wenn das ein Inselsystem ist, ohne jegliche Anbindung an die Außenwelt. Ansonsten gilt: Updates haben ihren Sinn!

updates nicht zu machen, ist daher m.E. keine Option. Daher ist auch
Zitat von: Frank_Huber am 07 Juni 2019, 08:30:47
Lösung ist dann manuell auf nen alten Kernel zurück.
m.E. nicht etwas, was als "Lösung" bezeichnet werden sollte.

Keine Lösung, aber ein Weg, solche Probleme zu vermeiden, ist der strikte Grundsatz, Logik und Hardware möglichst weitgehend zu trennen, also insbesondere: Keine Pi-GPIO's nutzen (außer für RTC und ggf. Aufsteck-Interfaces).

Empfehlung daher: Bei der Gelegenheit entsprechend säubern und - was auch immer du da angeschlossen hast - auslagern auf externe Hardware (Arduino, 1-wire-Komponenten, notfalls ESP's (das hat aber andere Nachteile, daher ausdrücklich das notfalls!)).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Frank_Huber

Zitat von: Beta-User am 07 Juni 2019, 09:22:14
Wundert mich irgendwie, dass dazu noch keiner was gesagt hat:Das ist dann eine super Idee, wenn das ein Inselsystem ist, ohne jegliche Anbindung an die Außenwelt. Ansonsten gilt: Updates haben ihren Sinn!

updates nicht zu machen, ist daher m.E. keine Option. Daher ist auch m.E. nicht etwas, was als "Lösung" bezeichnet werden sollte.

Keine Lösung, aber ein Weg, solche Probleme zu vermeiden, ist der strikte Grundsatz, Logik und Hardware möglichst weitgehend zu trennen, also insbesondere: Keine Pi-GPIO's nutzen (außer für RTC und ggf. Aufsteck-Interfaces).

Empfehlung daher: Bei der Gelegenheit entsprechend säubern und - was auch immer du da angeschlossen hast - auslagern auf externe Hardware (Arduino, 1-wire-Komponenten, notfalls ESP's (das hat aber andere Nachteile, daher ausdrücklich das notfalls!)).

Ich muss ergänzen dass das zwar die Lösung war damit es wieder schnell lief, die Systeme wurden dann aber auf Jessie neu installiert wo das Problem nicht auftrat.
Habe jetzt genau dafür eine separate Instanz wo Updates sowohl von fhem als auch vom OS getestet werden.
Von diesem einen Vorfall abgesehen hatte ich keine Probleme mit den GPIO und würde es wohl wieder so aufsetzen. :)
Aber da gehen die Meinungen auseinander.

Beta-User

Zitat von: Frank_Huber am 07 Juni 2019, 09:43:07
Von diesem einen Vorfall abgesehen hatte ich keine Probleme mit den GPIO und würde es wohl wieder so aufsetzen. :)
Aber da gehen die Meinungen auseinander.
Klar, das ist nur meine Meinung (gebildet aber auch vor dem Hintergrund mancher unliebsamer eigener Erfahrungen, die sich in vielen Beiträgen hier recht gut spiegeln)...

Ich habe die genannten eigenen Erfahrungen dann als Anlaß genommen, mich in andere Optionen einzuarbeiten, die am Ende dann auch nicht schwieriger sind, als die Konfiguration von PI-GPIO's (die btw. auch das System ganz schön ausbremsen können - je nach Konfiguration).

Kommt aber drauf an, was man genau benötigt, für Ausgänge würde ich als einsteigerfreundliche Option z.B. RS485-Boards ins Rennen werfen, für Zählereingänge: ArduCounter (oder für beides: 1wire, ist aber deutlich teurer) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Frank_Huber

Zitat von: Beta-User am 07 Juni 2019, 10:00:20
Klar, das ist nur meine Meinung (gebildet aber auch vor dem Hintergrund mancher unliebsamer eigener Erfahrungen, die sich in vielen Beiträgen hier recht gut spiegeln)...

Ich habe die genannten eigenen Erfahrungen dann als Anlaß genommen, mich in andere Optionen einzuarbeiten, die am Ende dann auch nicht schwieriger sind, als die Konfiguration von PI-GPIO's (die btw. auch das System ganz schön ausbremsen können - je nach Konfiguration).

Kommt aber drauf an, was man genau benötigt, für Ausgänge würde ich als einsteigerfreundliche Option z.B. RS485-Boards ins Rennen werfen, für Zählereingänge: ArduCounter (oder für beides: 1wire, ist aber deutlich teurer) .
Sind bei mir ganz gewöhnliche Taster und Relais. Eine Abkopplung mittels Optokoppler entwerfe ich gerade. das kommt zum Schutz bald noch dazu.
Hatte aber auch ohne noch keinen Defekt.
Es gibt immer viele Möglichkeiten zum Ziel zu kommen und jeder hat seine Vorlieben. :-)
Muss man dann eben immer auch für den speuziellen Einsatzzweck abwägen.

AnBad

Hallo Leute,

ich habe jetzt meine Raspbian/FHEM-Backup wieder hergestellt und folgende Updates Dank! Eurer Infos durchgeführt.

Unkritische Update durchführen:
cpan -u
sudo apt-get update
sudo reboot


Eher mit Vorsicht:
sudo apt-get upgrade
sudo reboot


Auf dem ersten Blick scheint es ohne Probleme funktioniert zu haben.

Was nicht komplett funktioniert hat, ist in FHEM in die Befehlszeile eingeben:
update

Hier zeigt mein Weblink "htmlCode { WeatherAsHtmlD("Wetter") }" zu DarkSkyAPI statt 1+5 Tage Vorausschau eine Vorausschau für 1+5 Stunden an...? Ich weiß, gar nicht mehr, wie ich dies damals installiert habe, und was jetzt zu tun ist. Tipp?

Und noch was, vlt habt ihr eine Beschreibung/Link, wie man ein Backup einer Datenback mariaDB wiederherstellt. Die Daten werden jede Nacht von DbRep auf einen USB gesichert. Aber Restore, wie? :-???

Vielen Dank soweit, und einen schönen Pfingstfeiertag!!

Michael


MadMax-FHEM

Da gibt es ein Attribut wo du das mit der Vorschau einstellen kannst...

Müsste beim DarkskyWeather das Attribut forecast sein...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Wernieman

a)
Ein System sollte so eingerichtet sein, das ein "reboot" ohne Probleme läuft ... sonst hast Du ein Poblem.

Um es anders Auszurücken:
Kein reboot testen ist kritisch

b)
apt-get update
ist kein Update .. sondern aktuallisiert nur die Datenbank der Packete ...

c)
cpan -u
sollte NACH "apt-get upgrade" erfolgen.
Bein beim upgrade ein neues PERL kommt, hast Du wieder das Problem, das cpan nicht mehr aktuell ist.

Und ein update mit cpan ist je nach Perl-Packet auch nicht immer Unkritich. Also immer gucken, WAS den aktuallisiert wird ...
d)
Bitte nach einem Update und erfolgreichen test etwas aufräumen:
apt-get autoremove
apt-get autoclean
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Frank_Huber



Zitat von: Wernieman am 08 Juni 2019, 12:28:33
apt-get autoclean

Wo liegt denn da der Unterschied zu apt-get clean[/clean]

Gesendet von meinem Doogee S60 mit Tapatalk


AnBad

Hi,
also gucken, was bei update cpan unkritisch ist, dass kann ich als relativer Laie nicht. Ich muss da einfach durch....

Habe es mir jetzt auf folgende Schritte geändert, die ich dann zukünftig immer mal durchführen werden:

Eher mit Vorsicht:
sudo apt-get upgrade
sudo reboot
cpan -u


Unkritische Parket-Update durchführen:
sudo apt-get update
Sudo reboot



Bereinigung:
apt-get autoremove
apt-get autoclean


in FHEM:
update

So OK?

Danke
Michael

Wernieman

Zitat aus der "Man-Page"
Zitatautoclean (und der auto-clean Alias seit 1.1)
           Wie clean bereinigt autoclean das lokale Depot von
           heruntergeladenen Paketdateien. Der Unterschied besteht darin, dass
           es nur Pakete entfernt, die nicht mehr heruntergeladen werden
           können und größtenteils nutzlos sind. Dies erlaubt es, einen
           Zwischenspeicher über eine lange Zeitspanne zu betreiben, ohne dass
           er unkontrolliert anwächst. Die Konfigurationsoption
           APT::Clean-Installed wird installierte Pakete vor der Löschung
           bewahren, wenn sie auf »off« gesetzt ist.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

claudio-fhem

Zitat von: AnBad am 08 Juni 2019, 13:54:12


So OK?

Danke
Michael

Ähm, nein, steht doch ein paar Posts weiter oben, apt update updated nur deine DATENBANK, kein einziges Paket. Wirklich Updates werden installiert mit apt upgrade nach dem apt update...

Vielen Dank und Grüße!

claudio