VU+ 4K Kernel Update (kompilieren) und Backup

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • VU+ 4K Kernel Update (kompilieren) und Backup

      Hallo Zusammen!

      Ziele:
      1. Backup des Kernel (der Partitionen kernel, initrd ggf. splash), sodass diese mittels USB-Stick wieder geflashed [5] werden können.
      2. Kernel mit Namespace-Support kompilieren und installieren (am liebsten über USB-Stick flashen [5])

      Frage und Beschreibung zum Ziel 1: Backup Kernel und Installation mittels USB-Stick

      Ich habe mir gestern erstmals eine VU+ Ultimo 4K angeschaut und leider festgestellt, dass der Linux-Kernel kein Network-Namespace-Support besitzt (siehe C-Befehl unshare[1] und vuultimo4k_defconfig):

      $ strace ip netns add nsnet01
      ---
      unshare(CLONE_NEWNET) = -1 EINVAL (Invalid argument)
      ---

      Also muss ich den Kernel neu kompilieren und updaten. Vorher möchte ich von diesen ein Backup erstellen, falls etwas schief geht und ich diesen wieder per USB-Stick zurück flashen muss. Doch wo liegt der Kernel bei einer VU+ 4K? Die Antwort liefert die postinst-Skript der ipk-Datei: kernel-image-3.14.28-1.12 [2].

      Das postinst-Skript installiert die zImage mittels "dd if=/tmp/zImage of=/dev/mmcblk0p1" auf die erste Partition:

      $ fdisk -l /dev/mmcblk0
      Number Start (sector) End (sector) Size Code Name
      1 2048 34815 16.0M 0700 kernel
      2 34816 67583 16.0M 0700 initrd
      3 67584 71679 2048K 0700 splash
      4 71680 7632895 3692M 0700 rootfs


      Die Partitionen scheinen den Installationsdaten kernel_auto.bin, initrd_auto.bin, splash_auto.bin und rootfs.tar.bz2 der vuplus-image-vuultimo4k-20181023024554_usb.zip für die Installation zu entsprechen.

      Frage zu 1: Kann ich die Partitionen so backupen, sodass ich wieder die Installationsdaten kernel_auto.bin, initrd_auto.bin, splash_auto.bin und rootfs.tar.bz2 bekomme (dd- und tar-Befehl, oder Backup-Funktion im Forntend [4])?

      Zusatzfrage 1.1 Kann man auf der USB-Stick-Installation eigentlich die rootfs.tar.bz2 weglassen, sodass nur der Kernel installiert wird? (Das Risiko das die Kernel-Module im rootfs abweichen können ist mir bewusst)

      Frage und Beschreibung zum Ziel 2: kompilieren des Kernel und erstellen der bin-Dateien für die USB-Stick Installation

      Ich habe ein Debian Jessie als Entwicklungsumgebung gewählt (ja ist etwas alt, aber die Pakete der VU+ auch!) mit folgenden Paketen:
      $ apt install build-essential git diffstat texi2html subversion gawk chrpath sshpass libglib2.0-dev libncurses5-dev

      Besorgen der Quellen [6] zum erstellen der VU+ Image:
      git clone git://code.vuplus.com/git/openvuplus_3.0.git
      cd openvuplus_3.0
      make image MACHINE=vuultimo4k


      Nach einer weile bekomme ich fogenden Fehler und das war's:
      Spoiler anzeigen
      ---
      ERROR: Fetcher failure: Fetch command failed with exit code 128, output:
      Cloning into bare repository '/home/dev/openvuplus_3.0/sources/git2/anonscm.debian.org.collab-maint.libdca.git'...
      fatal: unable to connect to anonscm.debian.org:
      anonscm.debian.org[0: 194.177.211.202]: errno=Connection refused
      anonscm.debian.org[1: 2001:648:2ffc:deb::211:202]: errno=Network is unreachable

      ERROR: Function failed: Fetcher failure for URL: 'git://anonscm.debian.org/collab-maint/libdca.git;protocol=git'. Unable to fetch URL from any source.
      ERROR: Logfile of failure stored in: /home/dev/openvuplus_3.0/build/vuultimo4k/tmp/work/armv7ahf-vfp-neon-oe-linux-gnueabi/libdca/libdca-0.0.5-5-r1-opt1/temp/log.do_fetch.30991
      ERROR: Task 4458 (/home/dev/openvuplus_3.0/meta-openvuplus/recipes-support/libbluray/libdca_0.0.5-5.bb, do_fetch) failed with exit code '1'
      ---

      Also habe ich versucht nun den Kernel zu erstellen, aber wie macht man das richtig? Ich habe folgendes versucht [7]:
      $ cd openvuplus_3.0/build/vuultimo4k/
      $ source bitbake.env
      $ bitbake -c menuconfig virtual/kernel


      Dort habe ich CONFIG_NET_NS auf y gestellt!
      $ bitbake -f -c compile virtual/kernel

      Der Kernel wird kompiliert. Aber ich glaube nicht, dass das nicht richtig mache. Es entsteht definitiv eine zImage aber keine ipk-Datei! Und ich will ja eigentlich die kernel_auto.bin und initrd_auto.bin für den USB-Stick haben.

      Frage zu 2: Was muss ich tun damit ich den Kernel als kernel_auto.bin und initrd_auto.bin kompilieren kann und in welchen Verzeichnis liegen zu Schluss die Dateien?

      Quellen:
      [1] unshare(1) — manpages-de — Debian testing — Debian Manpages
      [2] opkg download kernel-image-3.14.28-1.12
      [3] Vu+ Update
      [4] [Erledigt] vu+ solo backup auf usb stick
      [5] VTi Installation – Vu+ WIKI
      [6] Vu+ Update
      [7] Kernel Building - Openembedded.org

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von hgdo ()

    • Ist dir klar, dass dies ein Forum für das VTi-Image ist und dass du daher zum Original-Image nicht viel Hilfe erwarten solltest?

      Warum willst du viel Arbeit und Energie in ein Image stecken, das nur rudimentären Ansprüchen genügt?
    • Hallo hgdo,

      bisher kenne ich mit den Images nicht aus und danke dir für dein Hinweis zum unterschiedlichen Image.

      Ich benötige deine Beratung. Hat den die VTi Image Namespace-Support und woher bekomme ich den Quellcode (falls dieser nicht enthalten ist)?
    • Hallo hmmmdada,

      danke dir für deine Hilfe!

      Versuche einfach einmal mit SSH dich auf der Box anzumelden und ein virtualles Netzwerk-Interface mit dem Namespace nsnet01 zu erzeugen.

      1. Schritt iproute2 installieren:
      opkg install iproute2

      2. Schritt virtuelles Netzerk-Interface erzeugen:
      ip netns add nsnet01

      Es darf keine Fehlermeldung kommen wie z.B.: Failed to create a new network namespace "nsnet01": Invalid argument

      Falls es ohne Fehlermeldung durchgegangen ist, kannst du dir das Interface anschauen:
      ip netns list

      Als letztes wieder das Interface entfernen mit:
      ip netns delete nsnet01

      Danke dir schon einmal!!!!
    • manti7 schrieb:

      Hat den die VTi Image Namespace-Support und woher bekomme ich den Quellcode
      Das ist closed source, also gar nicht.
    • Ich downloade gerade die VTi-Image 13.0.9 herunter, denn diese scheint doch einige Vorteile zu haben.

      Doch der VTi-Kernel kann es wie man von @hmmmdada sieht auch nicht! Gibt es denn für die VTi-Image irgendeine Entwickler-Webseite? Auch wenn es Closed Source ist, so muss es doch eine Seite geben auf diesen Bugs reported werden?
    • Die Entwickler lesen hier im Forum mit.

      Akuell ist übrigens VTi 13.0.12. Das findest du hier: vuplus-support.org/wbb4/vtisof…Ti%2013.0.X/VTi%2013.0.12
      In die Database kommen keine neuen Images mehr.

      Nebenbei: wozu braucht man auf dem Receiver ein virtualles Netzwerk-Interface?

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von hgdo ()

    • Dann habe ich noch eine kleine Bitte an @hgdo. Da du als Moderator die Entwickler kennst, wäre es schön wenn du sie auf folgende Anfrage hinweisen könntest:

      Anfrage zu Aktivierung vom Network Namespace Support im Kernel (Kernel Flag CONFIG_NET_NS : General setup -> Namespaces support)

      Hintergrund: Der Network Namespace Support binded Programme an bestimmte Netzwerk-Interfaces. So lassen sich Anwendungen in einen VPN-Tunnel sperren und so der Traffik geziehlt über andere Wege führen. Ich möchte sicherstellen, dass eine Anwendung niemals ohne VPN kommunizieren kann. Aus diesem Grund stelle ich die Anfrage für die Network Namespaces.

      Außerdem wäre von Ihnen als Entwickler zu entscheiden, ob nicht sogar alle Namespaces (UTC, IPC, User, PID und Network) sinnvoll wären. Denn so könnte man sogar Docker, LXC oder nsjail einsetzten. Deren Vorteile hinreichend bekannt sind.
    • Hi!
      Ist das zulässig? Und wenn, gehört es zum guten Ton? Der Linux-Kern ist ja auch Open Source. Diesen ganzen Enigma-Kram, der kann ja closed source sein und bleiben, aber der Kernel? Finde ich mega unfair.