Skip to content

ROCKPro64 - 0.9.16 mit Kernel 5.6 auf PCIe NVMe SSD

ROCKPro64
1 1 401
  • Da ich ja immer viel Spaß am Testen habe, habe ich mal eine aktuelle Version Release 0.9.16 auf eine PCIe NVMe SSD gebügelt. Wie? Das kann man hier nachlesen.

    Jetzt hat Kamil heute den u-boot fertig, der auch von PCIe booten soll. Den gibt es hier.

    Damit bootet die NVMe SSD einwandfrei, aber nur mit dem 4.4 Kernel. Mit dem Kernel 5.6 gibt es Probleme.

    Pastebin

    Ok, da Kamil mal wieder viel on ist, mal schnell nachgefragt.

    (19:30:26) FrankM: @ayufan: Boot from SPI https://pastebin.com/g6hJ5sxZ
    (19:30:49) ayufan: oh, nice, nvme boot 🙂
    (19:30:58) FrankM: Jepp 🙂
    (19:31:20) ayufan: there’s a missing rockchip-pcie in initrd
    (19:32:02) ayufan: /etc/initramfs-tools/modules needs to have pcie-rockchip-host and then do update-initramfs -u
    (19:32:53) ayufan: I do not compile it as a built-in, rather module, this is why.
    (19:35:13) ayufan: I included that in a next build

    Ok, das bekomme ich hin 🙂

    Schnell mit 4.4er Kernel gestartet. Dann

    nano /etc/initramfs-tools/modules
    

    Ans Ende

    pcie-rockchip-host
    

    eingefügt. Danach abspeichern. Dann den hier eingeben

    update-initramfs -u
    

    Neustarten, der 5.6er Kernel wird geladen und das fehlerfrei! 🤓

    Kernel

    root@rockpro64:~# uname -a
    Linux rockpro64 5.6.0-1127-ayufan-g1bd266cae93f #ayufan SMP PREEMPT Sat Apr 4 11:14:08 UTC 2020 aarch64 GNU/Linux
    

    Platte

    root@rockpro64:~# df -h
    Filesystem      Size  Used Avail Use% Mounted on
    udev            945M     0  945M   0% /dev
    tmpfs           192M  5.4M  186M   3% /run
    /dev/nvme0n1p7  459G  2.1G  438G   1% /
    tmpfs           956M     0  956M   0% /dev/shm
    tmpfs           5.0M  4.0K  5.0M   1% /run/lock
    tmpfs           956M     0  956M   0% /sys/fs/cgroup
    /dev/nvme0n1p6  112M  4.0K  112M   1% /boot/efi
    tmpfs           192M     0  192M   0% /run/user/1000
    

    Danke Kamil!

  • Forgejo Installation mit Restic nach Hetzner S3 sichern

    Restic restic linux forgejo
    2
    2
    0 Stimmen
    2 Beiträge
    305 Aufrufe
    FrankMF
    Ich habe ja im obigen Beispiel, den gesamten Ordner von der Postgres Installation gesichert. backup_pfad_postgres="/home/pguser/db-data" Ich habe dann mal ein wenig in der Dokumentation gelesen und das hier gefunden. https://www.postgresql.org/docs/current/app-pgdump.html Einfach den Ordner zu sichern, ist ja bei jeder Datenbank ein gewisses Risiko. Die Konsistenz der Daten ist nicht gesichert. Darum gibt es bei den Datenbanken auch immer Tools, mit denen man die Daten sichern kann. In der Doku steht folgendes. pg_dump — extract a PostgreSQL database into a script file or other archive file Aber wichtiger ist das hier. pg_dump is a utility for backing up a PostgreSQL database. It makes consistent backups even if the database is being used concurrently. pg_dump does not block other users accessing the database (readers or writers). Das macht also konsistente Backups. Wichtig noch zu wissen ist folgendes. pg_dump only dumps a single database. To back up an entire cluster, or to back up global objects that are common to all databases in a cluster (such as roles and tablespaces), use pg_dumpall. Ok, das scheint gut geeignet zu sein, um die Datenbank zu sichern. Aber, wie? Auf meinen Eingangsbeitrag kam es zu folgendem Dialog auf Mastodon. https://nrw.social/deck/@nebucatnetzer@social.linux.pizza/114132208440509237 Das war der Anstoß sich mit dem Thema zu beschäftigen. Und ich hatte dann folgende Lösung. podman exec -it postgres pg_dump -U postgres -f /var/lib/postgresql/data/dump.txt Ok, was mache ich hier? Wir führen einen Befehl vom Host aus gesehen, im Container aus. podman exec -it postgres Der Teil führt den folgenden Befehl im Container aus. pg_dump -U postgres -f /var/lib/postgresql/data/dump.txt pg_dump - Das Tool fürs Backup -U postgres - Der Befehl wird als User postgres ausgeführt -f /var/lib/postgresql/data/dump.txt - Das Dump File wird im Data Ordner abgelegt, den haben wir ja persistent auf dem Host. Somit kann ich das jetzt einfach in mein Backup Script einbauen und brauchen nicht mehr den ganzen Ordner zu kopieren, sondern nur noch das Dump File. Ich werde diese Änderungen in das obige Script einbauen.
  • Proxmox 8.2 released

    Proxmox proxmox linux
    1
    0 Stimmen
    1 Beiträge
    217 Aufrufe
    Niemand hat geantwortet
  • Restic v0.16.2

    Linux restic linux
    1
    0 Stimmen
    1 Beiträge
    159 Aufrufe
    Niemand hat geantwortet
  • Root-Rechte für Angreifer

    Linux linux debian
    1
    0 Stimmen
    1 Beiträge
    107 Aufrufe
    Niemand hat geantwortet
  • [V] ROCKPro64 incl. PCIe SATA-Karte

    Verschoben Archiv rockpro64
    2
    2
    0 Stimmen
    2 Beiträge
    350 Aufrufe
    FrankMF
    Verkauft!
  • Kopia 0.7.0-rc1 Kurztest

    Kopia kopia linux
    2
    2
    0 Stimmen
    2 Beiträge
    412 Aufrufe
    FrankMF
    Nachdem ich doch ziemlich lange Snapshot Zeiten hatte, habe ich Jarek mal gefragt woran das liegt. I guess you could run it in the cloud but latency will be progressively worse because it's a chatty protocol sensitive to latency Technisch verstehe ich das nicht, aber ich habe dann mal als kurzen Test auf meine lokale SSD einen Snapshot gemacht. Der war nach 2 Minuten (ca. 11GB) fertig. Der zweite Snapshot brauchte ca. 12 Sekunden. Das hört sich schon mal viel besser an, als die Stunden. Aktuell ist der Plan den Kopia-Server im Internet zu nutzen damit beerdigt. Das scheint so nicht zu funktionieren. Ich mache da noch einen kurzen Test, diesmal Lokal auf meinem NAS.
  • Rest-Server

    Verschoben Restic rest-server linux restic
    8
    0 Stimmen
    8 Beiträge
    767 Aufrufe
    FrankMF
    Dann mal eben ausprobiert. Auf meinem Server war die Version 0.9.7 selber, mit go, gebaut. Dann mache ich das auch mit der v0.10.0 so. Aber bevor ich anfange, wird die v0.9.7 gesichert. mv /usr/local/bin/rest-server /usr/local/bin/rest-server_0_9_7 So erspare ich mir im Problemfall das selber bauen. Ok, dann die neue Version bauen. git clone https://github.com/restic/rest-server.git cd rest-server go run build.go Danach befindet sich im Verzeichnis die Binärdatei rest-server Die kopieren wir jetzt cp rest-server /usr/local/bin Danach kurzer Test # rest-server --version rest-server 0.10.0 (v0.10.0-6-g037fe06) compiled with go1.11.6 on linux/amd64 Gut Version passt Dann ein Backup gestartet. Das sichert einen Teil meines Home-Verzeichnis Files: 153 new, 100 changed, 177857 unmodified Dirs: 0 new, 1 changed, 0 unmodified Added to the repo: 81.881 MiB processed 178110 files, 80.571 GiB in 0:28 snapshot 607e0027 saved Applying Policy: keep the last 3 snapshots, 3 monthly snapshots keep 5 snapshots: ID Time Host Tags Reasons Paths --------------------------------------------------------------------------------------- fa97890e 2020-07-25 21:02:05 frank-XXX monthly snapshot /home/frank 5b073bbb 2020-08-30 10:17:27 frank-XXX monthly snapshot /home/frank f7cf37ef 2020-09-06 15:13:03 frank-XXX last snapshot /home/frank 0157462c 2020-09-13 13:32:12 frank-XXX last snapshot /home/frank 607e0027 2020-09-14 08:09:34 frank-XXX last snapshot /home/frank monthly snapshot --------------------------------------------------------------------------------------- 5 snapshots remove 1 snapshots: ID Time Host Tags Paths --------------------------------------------------------------------- 3010b7cc 2020-09-06 11:39:27 frank-XXX /home/frank --------------------------------------------------------------------- 1 snapshots 1 snapshots have been removed, running prune counting files in repo building new index for repo [1:34] 100.00% 17351 / 17351 packs So weit funktioniert das genau wie vorher. Im Changelog stand ja was von Subfoldern. Das betrifft mich nicht, weil ich für jeden User genau ein Verzeichnis habe. So mit alles Gut Dann warte ich mal morgen ab, ob die täglichen Backups der Server rund laufen.
  • Projekt NAS - BIOS Update 1.25.0

    Linux linux
    1
    0 Stimmen
    1 Beiträge
    682 Aufrufe
    Niemand hat geantwortet