[GELÖST] Update leider nicht möglich
Moderatoren: jmaus, Co-Administratoren
-
- Beiträge: 117
- Registriert: 08.06.2019, 13:25
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Salzburg
- Hat sich bedankt: 9 Mal
- Danksagung erhalten: 3 Mal
[GELÖST] Update leider nicht möglich
Hallo zusammen,
ich verwende derzeit die Version 3.47.10.20190713 der RaspiMatic.
Leider schaffe ich es seit der letzten Version 3.47.15.xxx schon nicht mehr ein Update über die WebUI durchzuführen.
Habe es mit der rpi3.zip sowie auch dem "Umstiegs-Image" ccu3.tgz versucht. Bei beiden dasselbe Verhalten.
Man kann die hochzuladende Datei auswählen und den Upload beginnen. Dann sieht man unten links im Browser auch die Prozente hochzählen und die Dialog zum Warten erscheint. Doch die Prozente gehen langsam hoch bis 100% und dann... nichts. Jetzt sollte ja dann irgendwann der AGBs akzeptieren Dialog kommen über den man dann die Installation anstarten kann. Doch der kommt auch nach ner Stunde nicht.
Habs jetzt auch schon über das Recoverysystem versucht. Dort kann ich die Zip noch hochladen. Doch mMn macht er das nicht fertig, denn der Upload beendet sich nach ca. 10 Sekunden (in der Zeit kann der Upload nie und nimmer fertig sein) und der Browser verliert die Verbindung. Lt. System-LED (dauerhaft Magenta) ist die CCU noch im Recovery-Modus. Ich komme aber nicht mehr drauf. Habe auch hier wieder ne Weile gewartet ob noch was passiert und irgendwann den Strom gekappt. Die CCU fährt dann wieder normal in den natürlich nicht gepatchten Stand hoch. (na wenigstens das )
Was ich beim letzten .15er Update schon bemerkt hatte war, dass das /usr/local/tmp Verzeichnis recht groß war und der entsprechende Mountpoint fast voll. Somit hat der unzip wohl nicht funktioniert.
Das seltsame jetzt ist aber, dass die CCU mMn überhaupt nichts mehr macht, nach dem Upload. Mit top sieht man ca. 1-2% Grundlast. Ich sehe aber nix von gzip oder Ähnlichem. Der müsste doch irgendwas machen, oder nicht?
ich verwende derzeit die Version 3.47.10.20190713 der RaspiMatic.
Leider schaffe ich es seit der letzten Version 3.47.15.xxx schon nicht mehr ein Update über die WebUI durchzuführen.
Habe es mit der rpi3.zip sowie auch dem "Umstiegs-Image" ccu3.tgz versucht. Bei beiden dasselbe Verhalten.
Man kann die hochzuladende Datei auswählen und den Upload beginnen. Dann sieht man unten links im Browser auch die Prozente hochzählen und die Dialog zum Warten erscheint. Doch die Prozente gehen langsam hoch bis 100% und dann... nichts. Jetzt sollte ja dann irgendwann der AGBs akzeptieren Dialog kommen über den man dann die Installation anstarten kann. Doch der kommt auch nach ner Stunde nicht.
Habs jetzt auch schon über das Recoverysystem versucht. Dort kann ich die Zip noch hochladen. Doch mMn macht er das nicht fertig, denn der Upload beendet sich nach ca. 10 Sekunden (in der Zeit kann der Upload nie und nimmer fertig sein) und der Browser verliert die Verbindung. Lt. System-LED (dauerhaft Magenta) ist die CCU noch im Recovery-Modus. Ich komme aber nicht mehr drauf. Habe auch hier wieder ne Weile gewartet ob noch was passiert und irgendwann den Strom gekappt. Die CCU fährt dann wieder normal in den natürlich nicht gepatchten Stand hoch. (na wenigstens das )
Was ich beim letzten .15er Update schon bemerkt hatte war, dass das /usr/local/tmp Verzeichnis recht groß war und der entsprechende Mountpoint fast voll. Somit hat der unzip wohl nicht funktioniert.
Das seltsame jetzt ist aber, dass die CCU mMn überhaupt nichts mehr macht, nach dem Upload. Mit top sieht man ca. 1-2% Grundlast. Ich sehe aber nix von gzip oder Ähnlichem. Der müsste doch irgendwas machen, oder nicht?
Zuletzt geändert von n300 am 22.09.2019, 13:15, insgesamt 1-mal geändert.
- jmaus
- Beiträge: 9864
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 464 Mal
- Danksagung erhalten: 1882 Mal
- Kontaktdaten:
Re: Update leider nicht möglich
Na was heisst denn jetzt konkret knapper Speicherplatz? Zeig mal her deine "df -h" Ausgabe. Weil du brauchst logischerweise mindestens rund 1,5 bis 2 GB freien speicherplatz auf /usr/local oder er kann eben die Updates nicht durchführen, egal ob im normalen oder recovery Modus.
RaspberryMatic 3.75.7.20240420 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
-
- Beiträge: 117
- Registriert: 08.06.2019, 13:25
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Salzburg
- Hat sich bedankt: 9 Mal
- Danksagung erhalten: 3 Mal
Re: Update leider nicht möglich
Hi Jens,
bei mir hat das FS für /usr/local gleich nur 2GB insgesamt. Nach dem Aufräumen schauts wie folgt aus.
Als das Ganze beim 1. Versuch vor ein paar Wochen schief ging, war der Freespace sicher schon auf 200MB runter.
Hab ich da aus dem tmp-Verzeichnis vielleicht zu viel "bereinigt"?
bei mir hat das FS für /usr/local gleich nur 2GB insgesamt. Nach dem Aufräumen schauts wie folgt aus.
Code: Alles auswählen
# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 975.9M 498.2M 410.5M 55% /
devtmpfs 479.9M 0 479.9M 0% /dev
tmpfs 484.4M 0 484.4M 0% /dev/shm
tmpfs 484.4M 108.0K 484.3M 0% /tmp
tmpfs 484.4M 88.0K 484.3M 0% /run
tmpfs 484.4M 492.0K 483.9M 0% /var
tmpfs 484.4M 0 484.4M 0% /media
/dev/mmcblk0p3 2.0G 393.3M 1.6G 20% /usr/local
/dev/mmcblk0p1 255.7M 39.4M 216.4M 15% /boot
/dev/sda1 29.4G 1.9G 27.6G 6% /media/usb1
Hab ich da aus dem tmp-Verzeichnis vielleicht zu viel "bereinigt"?
-
- Beiträge: 3978
- Registriert: 12.07.2009, 20:01
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 176 Mal
- Kontaktdaten:
Re: Update leider nicht möglich
2GB ist aber sehr wenig - ich denke zu wenig Wie groß ist denn die SD Karte?
-
- Beiträge: 117
- Registriert: 08.06.2019, 13:25
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Salzburg
- Hat sich bedankt: 9 Mal
- Danksagung erhalten: 3 Mal
Re: Update leider nicht möglich
gute Frage, ich hab die CCU3 leider noch nicht zerlegt bis jetzt. Aber ich denke das wird wohl ne 4er oder 8er sein.
Falls ich sie tauschen muss hätte ich an sowas hier gedacht -> https://www.amazon.de/Samsung-MB-MJ32GA ... 3W74P&th=1
Da ich jetzt nicht so der Linux-Pro bin. Gibts hier in SSH irgendein Equivalent zum diskpart, oder Ähnliches?
EDIT:
Hier mal der fdisk -l Output:
Kommt das nur mir so vor, oder sind da von den 8GB nur 3,25 formatiert?
Falls ich sie tauschen muss hätte ich an sowas hier gedacht -> https://www.amazon.de/Samsung-MB-MJ32GA ... 3W74P&th=1
Da ich jetzt nicht so der Linux-Pro bin. Gibts hier in SSH irgendein Equivalent zum diskpart, oder Ähnliches?
EDIT:
Hier mal der fdisk -l Output:
Code: Alles auswählen
# fdisk -l
Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram1: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram2: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram3: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram4: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram5: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram6: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram7: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram8: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram9: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram10: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram11: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram12: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram13: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram14: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram15: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/mmcblk0: 7.4 GiB, 7948206080 bytes, 15523840 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xdeedbeef
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 1 524288 524288 256M c W95 FAT32 (LBA)
/dev/mmcblk0p2 524289 2621440 2097152 1G 83 Linux
/dev/mmcblk0p3 2621441 6815744 4194304 2G 83 Linux
Disk /dev/sda: 29.5 GiB, 31625052160 bytes, 61767680 sectors
Disk model: Transcend 32GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8dc0fd5a
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 61767679 61765632 29.5G c W95 FAT32 (LBA)
-
- Beiträge: 3978
- Registriert: 12.07.2009, 20:01
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 176 Mal
- Kontaktdaten:
Re: Update leider nicht möglich
fdisk behauptet das jedenfalls Ich hätte jetzt vermutet RaspberryMatic dehnt die Partition beim ersten Start automatisch auf die vollen Devicegröße aus, da müsste mal Jens was zu sagen. Ansonsten sollte vergrößern auch händisch kein Problem sein, mal Stackoverflow konsultieren
- jmaus
- Beiträge: 9864
- Registriert: 17.02.2015, 14:45
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Dresden
- Hat sich bedankt: 464 Mal
- Danksagung erhalten: 1882 Mal
- Kontaktdaten:
Re: Update leider nicht möglich
Genau so ist es. eQ3 hat im Standardimage leider eine andere Art der Grundpartitionierung gewählt um das /usr/local nicht zu groß werden zu lassen. Wenn du allerdings bereits RaspberryMatic nutzt würde ich dir empfehlen nun mal ein Backup zu machen, dann danach in der WebUI einen Factory Reset auszulösen, dann sollte RaspberryMatic beim nächsten Booten die Partition auf die maximale SD Kartengröße vergrößern. Dann kannst du danach dein Backup wieder einspielen und dann sollte die /usr/local Partition entsprechend größer sein. Danach kannst du dann das RaspberryMatic update versuchen erneut einzuspielen.
RaspberryMatic 3.75.7.20240420 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal /
-
- Beiträge: 117
- Registriert: 08.06.2019, 13:25
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Salzburg
- Hat sich bedankt: 9 Mal
- Danksagung erhalten: 3 Mal
Re: Update leider nicht möglich
Spitze Leute, danke euch beiden. Werde ich mir die Tage, wenn mal Zeit ist machen. Dann weiß ich ja jetzt woran es lag.
Eine Frage noch. Was haltet ihr von oben verlinkter microSD? Ich weiß, dass der ganze Formfaktor nicht das Gelbe vom Ei ist. Aber man kann ja versuchen Schaden zu begrenzen, wenn man schon mal austauscht
Eine Frage noch. Was haltet ihr von oben verlinkter microSD? Ich weiß, dass der ganze Formfaktor nicht das Gelbe vom Ei ist. Aber man kann ja versuchen Schaden zu begrenzen, wenn man schon mal austauscht
-
- Beiträge: 3978
- Registriert: 12.07.2009, 20:01
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 176 Mal
- Kontaktdaten:
Re: Update leider nicht möglich
Ich benutz die Samsung Evo Plus und kann bisher nix schlechtes berichten. Die "welche SD für den Pi Frage" ist eine dieser Fragen wo Du von 10 Leuten 11 Meinungen bekommst Hab mal gehört dass die High Endurance Dinger eigentlich weniger gut geeignet seien weil sie weniger Wear Leveling machen würden (sind halt eigentlich für kontinuierliches (Über-)Schreiben in Überwachungs- und Dash-Cams und sowas ausgelegt) - aber ob das stimmt - keine Ahnung, Quelle hab ich auch vergessen. Ansonsten einfach mal Google fragen
-
- Beiträge: 3302
- Registriert: 07.01.2015, 23:26
- Wohnort: Scheeßel
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 11 Mal
Re: Update leider nicht möglich
Ich nutze Intenso Professional UHS-I MicroSD Karten und habe damit kein Probleme.
Habe einige davon seit ca. 3-4 Jahren in diversen Kameras zusätzlich zum NAS und da wird durchgehend aufgezeichnet.
Aber auch in 3 Raspis laufen die super.
Die machen ca. 55MB/s lesen und 85 MB/s schreiben.
Bisher ist noch keine gestorben.
Habe einige davon seit ca. 3-4 Jahren in diversen Kameras zusätzlich zum NAS und da wird durchgehend aufgezeichnet.
Aber auch in 3 Raspis laufen die super.
Die machen ca. 55MB/s lesen und 85 MB/s schreiben.
Bisher ist noch keine gestorben.