Posts by Bastelfritz17

FYI: ich hab's jetzt probiert -> funzt . Genauer: der "SD Card Copier" hat beim Kopieren auf die SSD aus der urspünglich 32 GB-Partition eine so groß gemacht wie Platz ist (bei mir jetzt ca. 500 GB). Beim zurück Kopieren 500 GB SSD -> SD-Card hat es keine Probleme gegeben ... die Card läuft (Partition natürlich wieder 32 GB klein)!

---

Ich hatte allerdings heute ziemlich viel Zeit mit der Aktion verbraten: erst fiel mir eine 60 GB SSD in die Hände, die bis vor ca. 3 Monaten an einem Notebook ein Debian-Zweitsystem via externem Gehäuse booten konnte...

• erst mal ans Notebook angesteckt und versucht von der SSD zu booten - Leseprobleme! Beim 2 Versuch ging's dann irgendwie ... das war jetzt schon mein 2. Fall, wo es Probleme mit einer SSD gab, die einige Zeit stromlos in der Lade lag.
• Dann (mit anderem Adapter) und GParted die Partition-Table neu erstellt, versucht zu klonen ... schien vorerst ok gegangen zu sein - allerdings bootete die SSD nicht ("mmc1: Controller never released inhibit bit(s)")...
• ... dann anderer Adapter genommen; es folgten noch ein paar Versuche, mal hing das Ding mit einer Meldung, die mir nichts sagte; dann stieg GParted beim Formatieren mit ext4 aus während sich die SSD auf einem (anderen) Debian-System formatieren ließ; das Klonen am Raspi ging dann aber auch wieder schief...

... letztendlich hab' ich die SSD zurück in das Gehäuse getan, in dem sie urspünglich steckte - damit funktionierte das Klonen SD-Card -> SSD anstandslos und auf Anhieb, auch läuft das System damit jetzt von der SSD wie geschmiert.

Woran es da jetzt zwischendurch hakte, bleibt mir ein Rätsel ... Hauptsache es läuft jetzt.

LG

Danke!

Hi,

ich hätte da mal eine Frage ... angenommen, ich kopiere mittels der eingebauten Funktion SD-Card Copier (wie hier unter 5. beschrieben) das System von der 32 GB SD-Card auf eine SSD...

• gehe ich recht in der Annahme, dass auch auf einer 500 GB SSD die Partition dann auch nur 32 GB groß angelegt wird?
• Könnte ich - nach x Monaten und xx Updates bzw. wenn ich die 500 GB SSD für etwas anders benötige - das System von der SSD auf demselben Weg wieder zurück auf die 32 GB SD-Card transferieren? Passt das dann noch?

Thx

Eine einzelne Datei aus einer CloneZilla-Sicherung wiederherstellen geht so nicht, der umständliche Weg wäre hier beschrieben - das möchte ich mir bitte ersparen. Sollte es notwendig sein, lese ich die Oktober-Sicherung zurück und mach' die Updates neu.

Aber warum sollte das jetzt nicht funktionieren(?) - jetzt steht eh das drin, was auch hier empfohlen wird (bis auf die Zeile mit den backports).

Warum hast Du Bedenken? Was genau vor dieser (sinnlosen) Aktion meinerseits drin stand, weiß ich nicht - ich könnte allerdings ein CloneZilla-Image vom Oktober 24 zurück lesen (vielleicht lässt sich auch die sources.list aus dem *.img heraus lesen? *) ).

*) Nachtrag: scheint nicht so einfach zu sein.

Quote

myuser@debian:~$ cat /etc/apt/sources.list
#deb cdrom:[Debian GNU/Linux 12.7.0 _Bookworm_ - Official amd64 NETINST with firmware 20240831-10:38]/ bookworm contrib main non-free-firmware

deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
deb http://deb.debian.org/debian-security/ bookworm-security main contrib non-free non-free-firmware
deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware

# deb http://deb.debian.org/debian/ bookworm main non-free-firmware
# deb-src http://deb.debian.org/debian/ bookworm main non-free-firmware

# deb http://security.debian.org/debian-security bookworm-security main non-free-firmware
# deb-src http://security.debian.org/debian-security bookworm-security main non-free-firmware

# bookworm-updates, to get updates before a point release is made;
# see https://www.debian.org/doc/manuals/de…s_and_backports

# deb http://deb.debian.org/debian/ bookworm-updates main non-free-firmware
# deb-src http://deb.debian.org/debian/ bookworm-updates main non-free-firmware

# This system was installed using small removable media
# (e.g. netinst, live or single CD). The matching "deb cdrom"
# entries were disabled at the end of the installation process.
# For information about how to configure apt package sources,
# see the sources.list(5) manual.
myuser@debian:~$

Display More

Am Raspi hab' ich die Eingeben gemacht:

Quote

myuser@raspberrypi:~ $ systemctl status rpi-eeprom-update.service
● rpi-eeprom-update.service - Check for Raspberry Pi EEPROM updates
Loaded: loaded (/lib/systemd/system/rpi-eeprom-update.service; enabled; preset: enabled)
Active: active (exited) since Mon 2025-01-27 07:22:53 CET; 2h 23min ago
Process: 584 ExecStart=/usr/bin/rpi-eeprom-update -s -a (code=exited, status=0/SUCCESS)
Main PID: 584 (code=exited, status=0/SUCCESS)
CPU: 229ms

Jän 27 07:22:53 raspberrypi rpi-eeprom-update[584]: BOOTLOADER: up to date
Jän 27 07:22:53 raspberrypi rpi-eeprom-update[584]: CURRENT: Mo 15 Apr 2024 13:12:14 UTC (1713186734)
Jän 27 07:22:53 raspberrypi rpi-eeprom-update[584]: LATEST: Mo 15 Apr 2024 13:12:14 UTC (1713186734)
Jän 27 07:22:53 raspberrypi rpi-eeprom-update[584]: RELEASE: default (/usr/lib/firmware/raspberrypi/bootloader-2711/default)
Jän 27 07:22:53 raspberrypi rpi-eeprom-update[584]: Use raspi-config to change the release.
Jän 27 07:22:53 raspberrypi rpi-eeprom-update[584]: VL805_FW: Using bootloader EEPROM
Jän 27 07:22:53 raspberrypi rpi-eeprom-update[584]: VL805: up to date
Jän 27 07:22:53 raspberrypi rpi-eeprom-update[584]: CURRENT: 000138c0
Jän 27 07:22:53 raspberrypi rpi-eeprom-update[584]: LATEST: 000138c0
Jän 27 07:22:53 raspberrypi systemd[1]: Finished rpi-eeprom-update.service - Check for Raspberry Pi EEPROM updates.
myuser@raspberrypi:~ $ systemctl cat rpi-eeprom-update.service
# /lib/systemd/system/rpi-eeprom-update.service
[Unit]
Description=Check for Raspberry Pi EEPROM updates
After=boot-firmware.mount

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/rpi-eeprom-update -s -a

[Install]
WantedBy=multi-user.target
myuser@raspberrypi:~ $ cat /etc/default/rpi-eeprom-update
FIRMWARE_RELEASE_STATUS="default"
myuser@raspberrypi:~ $ cat /usr/bin/rpi-eeprom-update | grep -i BOOTLOADER_AUTO_UPDATE_MIN_VERSION:
BOOTLOADER_AUTO_UPDATE_MIN_VERSION="${BOOTLOADER_AUTO_UPDATE_MIN_VERSION:-1599135103}"
BOOTLOADER_AUTO_UPDATE_MIN_VERSION="${BOOTLOADER_AUTO_UPDATE_MIN_VERSION:-1725975630}"
min_ver=${BOOTLOADER_AUTO_UPDATE_MIN_VERSION:-0}
myuser@raspberrypi:~ $

Display More

Am Debian-System hab' ich die sources.list wieder korrigiert entsprechend Deiner Einträge im vorheriigen Posting.

Thx

Leider nein:

Quote

myuser@raspberrypi:~ $ sudo rpi-eeprom-update
BOOTLOADER: up to date
CURRENT: Mo 15 Apr 2024 13:12:14 UTC (1713186734)
LATEST: Mo 15 Apr 2024 13:12:14 UTC (1713186734)
RELEASE: default (/usr/lib/firmware/raspberrypi/bootloader-2711/default)
Use raspi-config to change the release.

VL805_FW: Using bootloader EEPROM
VL805: up to date
CURRENT: 000138c0
LATEST: 000138c0

Display More

????

Btwy - ich habe gestern irrtümlich die Aktionen aus #8 zuerst auf meinem Debian-System durchgeführt (in Putty die IP#n verwechselt) - ich hoffe das macht nix. Ich glaube die Einträge in der sources.list waren vorher (fast) so wie ich sie jetzt eingetragen habe ('contrib' dürfte nicht drin gestanden haben).

Auch hier:

Quote

myuser@raspberrypi:~ $ apt policy rpi-eeprom
rpi-eeprom:
Installiert: 27.0-1
Installationskandidat: 27.0-1
Versionstabelle:
*** 27.0-1 500
500 http://archive.raspberrypi.com/debian bookworm/main arm64 Packages
500 http://archive.raspberrypi.com/debian bookworm/main armhf Packages
100 /var/lib/dpkg/status

Display More

Danke! Auf jeden Fall ist jetzt wieder mal Zeit die SD-Card zu backuppen...

LG

Uuuuups! Danke!

Danke ... habe getan wie vorgeschlagen ... es sind mir beim Upgrade keine Fehlermeldungen mehr aufgefallen. Allerdings gibt's im root immer noch ein paar Verzeichnisse, die mit '~' beginnen - siehe screenshot.

Passt das jetzt - oder doch (noch) nicht?

Thx

Bitte erkläre einem DAU was da genau zu vergleichen bzw. zu korrigieren ist. Und was dann angeworfen werden muss, damit die '~'-Verzeichnisse wieder normal gedreht werden.

Thx

Danke ... und was genau mache ich jetzt dagegen (am Raspi & am Debian-Server)?

Quote

myuser@raspberrypi:~ $ cat /etc/apt/sources.list
deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
deb http://deb.debian.org/debian-security/ bookworm-security main contrib non-free non-free-firmware
deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
# Uncomment deb-src lines below then 'apt-get update' to enable 'apt-get source'
#deb-src http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
#deb-src http://deb.debian.org/debian-security/ bookworm-security main contrib non-free non-free-firmware
#deb-src http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
myuser@raspberrypi:~ $ uname -a
Linux raspberrypi 6.6.62+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.62-1+rpt1 (2024-11-25) aarch64 GNU/Linux
myuser@raspberrypi:~ $

Display More

---------------

P.S.: ich hab' ja noch einen Debian-Server - da hab' ich jetzt auch mal geschaut: auch dort gibt's diese Verzeichnisse mit einem '~' vorher dran ... auch da hab' ich vor ein paar Tagen upgedatet (aber nicht auf de nOutput geschaut).

Hi,

habe soeben einmal via SSH ein Update/Upgrade angestoßen - 72 Files wollten upgedatet werden.

Im Protokoll lese ich allerdings :

Quote

Entpacken von rpi-eeprom (27.0-1) über (26.7-1) ...
dpkg: Warnung: Altes Verzeichnis »/lib/firmware/raspberrypi/bootloader-2712/latest« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/lib/firmware/raspberrypi/bootloader-2712/default« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer

......

rpi-connect.service is a disabled or a static unit not running, not starting it.
rpi-connect-wayvnc.service is a disabled or a static unit not running, not starting it.

....

Anbei der gesamte Output des Upgrades als *.txt. Weiters fällt auf, dass die Verzeichnisse '~bin', '~lib' und '~sbin' ein '~' vorne dran haben - sollte da nicht ein '/' sein?

Hab' ich mir da ein Problem eingetreten?

Thx

Ich bin mir da eigentlich nicht sicher, ob der TO für Hausautomatisation überhaupt einen 5er benötigt - wozu die viele Rechenleistung und so viel RAM (bei entsprechendem Stromverbrauch)? Tut es ein 3er oder 4er nicht auch?

Lesestoff: DIY Smart Home: 7 offene Plattformen für kreative Geister

Hier anscheinend dasselbe Problem - mit Lösung ... link

LG

@ DistroEx: danke fürs Aufmerksammachen - da war ich tatsächlich am falschen Dampfer.

Habe nun - wie von hyle in #12 angeregt - die autostart angelegt (bzw. wieder aktiviert) sowie den Eintrag in die cmdline.txt aus #20 hinzugefügt ... nun warte ich, was passiert. Nachdem sich ja erst langfristig zeigt, ob das "Schwarzer-Bildschirm-Problem-nach-langem-Bildschirm-Aus" nun erledigt ist, kann ich mich diesbezüglich erst mittelfristig rühren und Bescheid geben.

Danke und Frohes Fest inzwischen

LG

@ Ovrgre: danke - werde ich mir anschauen. Das könnte IMHO das Problem erledigen, dass nach ein paar Tagen "Poweroff" des Bildschirms dann auch vom RasPi nur Schwarz kommt. Ein "richtiger" Screensaver, der (einstellbar) nach xx Minuten auf Standy und nach yy Minuten ganz abdreht, wird das wohl nicht in Gang setzen.

Habe bei den specs des Eizo Foris geschaut, welche HDMI-Version da läuft - hab' keine Details gefunden. Ich werd's mal - wegen des Baujahres des BS - mit 0 versuchen.

Melde mich in ein paar Tagen, weil ich ja das Langzeitverhalten testen muss.