linux-nerds.org

Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.

Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).

NanoPI R2S - Snapshot aktualisieren

NanoPi R2S

3 Beiträge 2 Kommentatoren 317 Aufrufe

FrankM

schrieb am

Was macht man, wenn man mal einen aktuellen neuen Snapshot installieren möchte?

Achtung, danach ist fast alles weg und man fängt wieder von vorne an!!

Vorbereitungen

Wir wählen das Upgrade Image, aktuell an Position 560, vorletzte Spalte.

opkg update
opkg install wget
cd /tmp
wget --no-check-certificate http://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-friendlyarm_nanopi-r2s-
squashfs-sysupgrade.img.gz

Upgrade

# sysupgrade -v /tmp/openwrt-rockchip-armv8-friendlyarm_nanopi-r2s-squashfs-sysupgrade.img.gz 
   Thu Dec 17 19:29:04 UTC 2020 upgrade: Reading partition table from bootdisk...
   Thu Dec 17 19:29:04 UTC 2020 upgrade: Reading partition table from image...
   Thu Dec 17 19:29:05 UTC 2020 upgrade: Saving config files...
   etc/config/dhcp
   etc/config/dropbear
   etc/config/firewall
   etc/config/luci
   etc/config/network
   etc/config/rpcd
   etc/config/system
   etc/config/ttyd
   etc/config/ucitrack
   etc/config/uhttpd
   etc/dropbear/dropbear_ed25519_host_key
   etc/dropbear/dropbear_rsa_host_key
   etc/group
   etc/hosts
   etc/inittab
   etc/luci-uploads/.placeholder
   etc/opkg/keys/0b26f36ae0f4106d
   etc/opkg/keys/1035ac73cc4e59e3
   etc/opkg/keys/5151f69420c3f508
   etc/opkg/keys/72a57f2191b211e0
   etc/opkg/keys/792d9d9b39f180dc
   etc/opkg/keys/9ef4694208102c43
   etc/opkg/keys/b2d571e0880ff617
   etc/opkg/keys/b5043e70f9a75cde
   etc/opkg/keys/c10b9afab19ee428
   etc/opkg/keys/dace9d4df16896bf
   etc/opkg/keys/dd6de0d06bbd3d85
   etc/opkg/keys/f94b9dd6febac963
   etc/passwd
   etc/profile
   etc/rc.local
   etc/shadow
   etc/shells
   etc/shinit
   etc/sysctl.conf
   Thu Dec 17 19:29:05 UTC 2020 upgrade: Commencing upgrade. Closing all shell sessions.
   Connection to 192.168.178.33 closed by remote host.
   Connection to 192.168.178.33 closed.

Danach dann wieder

opkg install luci

und /etc/config/network und /etc/config/firewall bearbeiten. Einmal durchstarten und fertig.

Quelle: https://fabianlee.org/2017/02/04/openwrt-upgrading-to-the-latest-snapshot-build/ Thank you!

T Offline

T Offline
Thrakath1980
schrieb am zuletzt editiert von

#2

Hi, danke für deine prompte Antwort. Hab leider keine Mailnotification bekommen, muss ich gleich mal nachsehen. Kann man den FriendlyWRT Snapshot so auch auf OpenWRT aktualisieren? Und gibt es irgendeine Chance dann seine Settings zu behalten? Bekomme leider beim FriendlyWRT meinen USB Wifi nicht zum Laufen, obwohl Treiber wohl drauf sind, wird er nicht angezeigt.
F 1 Antwort Letzte Antwort
0
F Offline

F Offline
FrankM
antwortete auf Thrakath1980 am zuletzt editiert von

#3

@thrakath1980 Das kann ich Dir leider nicht beantworten. Denke aber, das es sinnvoll ist neu anzufangen. Welche Settings meinst Du?

Ich würde mal /etc/config sichern. Da sollte das Meiste ja drin sein.

Notifications? Hmm, ich hoffe das das funktioniert. Ich schau zur Sicherheit mal nach.
Im Fediverse -> @FrankM@nrw.social
1. NanoPi R5S
2. Quartz64 Model B, 4GB RAM
3. Quartz64 Model A, 4GB RAM
4. RockPro64 v2.1
1 Antwort Letzte Antwort
0

F

Konsolentext in Englisch
Geplant Angeheftet Gesperrt Verschoben Linux linux
1

0 Stimmen

1 Beiträge

42 Aufrufe

Niemand hat geantwortet
F

NanoPi R4S - eingetroffen
Geplant Angeheftet Gesperrt Verschoben NanoPi R4S nanopir4s
3

0 Stimmen

3 Beiträge

459 Aufrufe

F

Mal ein Screenshot von den Temperaturen mit OpenWrt.

d086e090-9c05-4a9d-8a86-fcf5d423d4f6-grafik.png
F

NanoPi R2S - OpenWRT VLAN
Geplant Angeheftet Gesperrt Verschoben NanoPi R2S nanopir2s openwrt linux
11

0 Stimmen

11 Beiträge

1k Aufrufe

F

@thrakath1980 Ok, du meinst die FriendlyArm Variante von OpenWRT. Ich denke, da sollte man besser alles neu machen. Leider ist das bei OpenWRT nicht so einfach zu updaten/upgraden wie z.B. bei einem Linux Kernel. Ich habe es mal runtergeladen, wenn ich mal Zeit habe, schau ich mal rein.
F

NanoPi R2S - OpenWRT
Geplant Angeheftet Gesperrt Verschoben NanoPi R2S nanopir2s openwrt linux
6

0 Stimmen

6 Beiträge

520 Aufrufe

F

@thrakath1980 Ich wollte noch auf ein Thema zurück kommen. Das Original OpenWRT auf dem R2S ist ja ein Snapshot. Den kann man ohne Probleme aktualisieren. Unten ist dann ein Haken mit "Keep settings...."

Gerade probiert, ging einwandfrei. Netzwerkeinstellungen und Firewall Settings blieben erhalten.
F

NanoPi R4S
Geplant Angeheftet Gesperrt Verschoben NanoPi R4S nanopir4s
10

0 Stimmen

10 Beiträge

869 Aufrufe

F

Kleiner Tipp, FriendlyARM anschreiben und nach schnellerem Versand fragen (keine Optionen im Online Shop) Hat mich 10$ gekostet, kam mit FedEX und hat am 29.1 China verlassen. Am 05.02.2021 bei mir 😉
F

NanoPi R2S - Firewall mit VLan und DHCP-Server
Geplant Angeheftet Gesperrt Verschoben NanoPi R2S nanopir2s linux
2

0 Stimmen

2 Beiträge

722 Aufrufe

F

Nachdem ich die Tage feststellen musste, das irgendwas mit dem Gerät nicht stimmte, bekam keine DNS Auflösung über die Konsole, habe ich das heute mal eben neuinstalliert.

Armbian ist ja immer was spezielles 🙂 Hat sich bis heute nix dran geändert.....

Ok, dann heute mal eben ein neues Image erstellt. Download Gewählt habe ich das Armbian Buster.

Image auf die SD-Karte, eingeloggt. Alles wie oben erstellt und abgespeichert. Neustart, geht wieder alles. 😍
root@192.168.3.15's password: _ _ _ ____ ____ ____ | \ | | __ _ _ __ ___ _ __ (_) | _ \|___ \/ ___| | \| |/ _` | '_ \ / _ \| '_ \| | | |_) | __) \___ \ | |\ | (_| | | | | (_) | |_) | | | _ < / __/ ___) | |_| \_|\__,_|_| |_|\___/| .__/|_| |_| \_\_____|____/ |_| Welcome to Debian GNU/Linux 10 (buster) with Linux 5.9.11-rockchip64 System load: 2% Up time: 11 min Memory usage: 10% of 978M IP: 192.168.3.15 192.168.1.1 192.168.2.1 CPU temp: 61°C Usage of /: 5% of 29G Last login: Sun Dec 6 12:28:10 2020 from 192.168.3.213 Kernelversion root@nanopi-r2s:~# uname -a Linux nanopi-r2s 5.9.11-rockchip64 #20.11.1 SMP PREEMPT Fri Nov 27 21:59:08 CET 2020 aarch64 GNU/Linux ip a oot@nanopi-r2s:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether b2:b5:10:38:9e:76 brd ff:ff:ff:ff:ff:ff inet 192.168.3.15/24 brd 192.168.3.255 scope global dynamic eth0 valid_lft 6360sec preferred_lft 6360sec inet6 2a02:908:xxxxxx/64 scope global dynamic mngtmpaddr valid_lft 7196sec preferred_lft 596sec inet6 fe80::b0b5:10ff:fe38:9e76/64 scope link valid_lft forever preferred_lft forever 3: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b2:b5:10:38:9e:96 brd ff:ff:ff:ff:ff:ff 4: lan0.100@lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether b2:b5:10:38:9e:96 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global lan0.100 valid_lft forever preferred_lft forever inet6 fe80::b0b5:10ff:fe38:9e96/64 scope link valid_lft forever preferred_lft forever 5: lan0.200@lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether b2:b5:10:38:9e:96 brd ff:ff:ff:ff:ff:ff inet 192.168.2.1/24 brd 192.168.2.255 scope global lan0.200 valid_lft forever preferred_lft forever inet6 fe80::b0b5:10ff:fe38:9e96/64 scope link valid_lft forever preferred_lft forever
Vom Notebook aus funktioniert auch alles. So weit bin ich zufrieden. Jetzt mal langsam anfangen, der Kiste IPv6 beizubringen. Oje, nicht gerade mein Lieblingsthema...

Bis der NanoPi R4S hier ankommt und ein vernünftiges Image hat, vergeht ja noch was Zeit...
F

NanoPi R2S
Geplant Angeheftet Gesperrt Verschoben NanoPi R2S arm nanopir2s
6

0 Stimmen

6 Beiträge

1k Aufrufe

F

Ok, die Netwerkkonfiguration will nicht so wie ich. 😕

Der Netzwerkmanager ist das Problem! Da ich den auf einem headless System nicht brauche, deaktivieren wir diesen.
nano /etc/NetworkManager/NetworkManager.conf
Da steht folgendes drin
[main] dns=default rc-manager=file plugins=ifupdown,keyfile [ifupdown] managed=true
Die letzte Zeile ändern wir in
[ifupdown] managed=false
Danach ein Neustart. Und siehe da, meine doppelten IP-Adressen sind auch weg.
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether b2:b5:10:38:9e:76 brd ff:ff:ff:ff:ff:ff inet 192.168.3.12/24 brd 192.168.3.255 scope global dynamic eth0 valid_lft 7116sec preferred_lft 7116sec inet6 2a02:908:1268:1d50:b0b5:xxxx:xxxx:xxxx/64 scope global dynamic mngtmpaddr valid_lft 7185sec preferred_lft 585sec inet6 fe80::b0b5:10ff:fe38:xxxx/64 scope link valid_lft forever preferred_lft forever
Zur Kontrolle, eben nochmal neugestartet und nachgeschaut. Perfekt, passt jetzt.

Das Firewall Script in den Autostart und dann mal die Tage schaue, wie er sich so macht.
F

Kopia - HTTP/S Server
Geplant Angeheftet Gesperrt Verschoben Kopia kopia linux
3

0 Stimmen

3 Beiträge

1k Aufrufe

F

Ich hatte ein paar Probleme, die ich mir teilweise nicht erklären kann 🤔

Ich möchte den Kopia Server gerne über systemd steuern.
SystemD [Unit] Description=Kopia Server After=syslog.target After=network.target [Service] Type=simple User=kopia Group=kopia ExecStart=/usr/bin/kopia server --tls-cert-file /home/kopia-server/fullchain.pem --tls-key-file /home/kopia-server/privkey.pem --htpasswd-file /home/kopia-server/.htpasswd --address <IPv4>:51515 Restart=always RestartSec=5 [Install] WantedBy=multi-user.target
Danach
systemctl daemon-reload systemctl start kopia-server
Mit
systemctl status kopia-server
kann man sich den Status anzeigen lassen.
Client Rechner
Auf dem Client, der das Backup zum Server schicken soll, machen wir dann folgendes.
USER@HOSTNAME:~$ kopia repo connect server --url=https://<DOMAIN>:51515 --override-username=USER --override-hostname=HOSTNAME Enter password to open repository: Connected to repository API Server. NOTICE: Kopia will check for updates on GitHub every 7 days, starting 24 hours after first use. To disable this behavior, set environment variable KOPIA_CHECK_FOR_UPDATES=false Alternatively you can remove the file "/home/frank/.config/kopia/repository.config.update-info.json".
Danach steht die Verbindung und wir können Backups hochschieben.
kopia snapshot create $HOME
Damit wird das Homeverzeichnis gesichert. Das initiale Backup, hat 30 Minuten gebraucht.
created snapshot with root kb9e50ff5xxxxxxxxxx265d40a5d0861 and ID cda5c0ffxxxxxxxxxxxxxxa4cb4a367b in 30m28s
Ein späteres Backup, sieht so aus.
USER@HOSTNAME:~$ kopia snapshot create $HOME Snapshotting USER@HOSTNAME:/home/frank ... * 0 hashing, 51 hashed (324.8 MB), 8524 cached (6.6 GB), 0 uploaded (0 B), 0 errors 100.0% Created snapshot with root kc20a4xxxxxxxxxxxx745c6c7b37c and ID d7a96eaxxxxxxxxxxx0961018eacffa in 3m12s
Nach 3 Minuten durch. Zu diesem Zeitpunkt hat sich aber auch nicht wirklich was geändert!
Fazit
Das Tool macht immer noch einen sehr guten Eindruck. Die Geschwindigkeit ist sehr gut. Die Anleitung ist leider unzureichend. Da gibt es so viele Möglichkeiten, da braucht es sehr lange, bis man da mal durchsteigt. Zum Glück, ist das was man normalerweise braucht, recht überschaubar. Bis zum produktiven Einsatz braucht das aber bei mir noch eine Menge mehr Tests.

Was ich noch testen möchte
Verzeichnis mounten Backup testweise wieder herstellen (zumindestens teilweise)
Der Test läuft mit Standard Einstellungen, also z.B. ohne Kompression. Das sollte man dann auch mal testen..

Bitte achtet auf gleiche Versionen auf dem Clienten, wie auf dem Server. Ich meine da ein paar Probleme festgestellt zu haben...