[GELÖST] Update leider nicht möglich

[n300]

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?

[jmaus]

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.

[n300]

Hi Jens,

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

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"?

[hobbyquaker]

2GB ist aber sehr wenig - ich denke zu wenig Wie groß ist denn die SD Karte?

[n300]

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:

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)

Kommt das nur mir so vor, oder sind da von den 8GB nur 3,25 formatiert?

[hobbyquaker]

Kommt das nur mir so vor, oder ist sind da von den 8GB nur 3,25 formatiert?

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]

gute Frage, ich hab die CCU3 leider noch nicht zerlegt bis jetzt. Aber ich denke das wird wohl ne 4er oder 8er sein.
[...]
Kommt das nur mir so vor, oder ist sind da von den 8GB nur 3,25 formatiert?

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.

[n300]

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

[hobbyquaker]

Was haltet ihr von oben verlinkter microSD?

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

[nicolas-eric]

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.