Group Details Private

Publishers

Publishers

Member List

  • RE: ROCKPro64 - Debian Bullseye

    Ich wollte gerade eine Installation auf einer PCIe SATA-Karte testen, da meckert die Installation über Kernel-Module die fehlen. Grund ist wohl mein zu altes Image! Also merken, immer ein aktuelles bauen zum Testen!

    Ein paar Gedanken von heute nachmittag.

    • Die Installation auf der PCIe SATA-Karte war erfolgreich.
    • Ein Booten von der SSD war erfolglos

    Interessanterweise taucht beim Updaten dann irgendwoher dieses File auf

    /dtbs/5.7.0-1-arm64
    

    Warum wird das dann nicht bei der Installation mit angelegt? Da sind noch so einige DDinge, die mir nicht vollständig klar sind. Mal etwas intensiver reinschauen und evt. mal auf der Mailingliste nachfragen.

    posted in ROCKPro64
  • RE: ROCKPro64 - Debian Bullseye

    Ok, ich bin faul 🙂

    Kamil macht das elegant so!

    /etc/default/extlinux

    # Configure timeout to choose the kernel
    # TIMEOUT="10"
    
    # Configure default kernel to boot: check all kernels in `/boot/extlinux/extlinux.conf`
    # DEFAULT="kernel-4.4.126-rockchip-ayufan-253"
    
    # Configure additional kernel configuration options
    APPEND="$APPEND root=LABEL=linux-root rootwait rootfstype=ext4"
    

    und

    update-extlinux.sh

    #!/bin/bash
    
    TIMEOUT=""
    DEFAULT=""
    APPEND="rw"
    APPEND="$APPEND panic=10"
    APPEND="$APPEND init=/sbin/init"
    APPEND="$APPEND coherent_pool=1M"
    APPEND="$APPEND ethaddr=\${ethaddr} eth1addr=\${eth1addr} serial=\${serial#}"
    APPEND="$APPEND cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1"
    
    set -eo pipefail
    
    . /etc/default/extlinux
    
    echo "Creating new extlinux.conf..." 1>&2
    
    mkdir -p /boot/extlinux/
    exec 1> /boot/extlinux/extlinux.conf.new
    
    echo "timeout ${TIMEOUT:-10}"
    echo "menu title select kernel"
    [[ -n "$DEFAULT" ]] && echo "default $DEFAULT"
    echo ""
    
    emit_kernel() {
      local VERSION="$1"
      local APPEND="$2"
      local NAME="$3"
    
      echo "label kernel-$VERSION$NAME"
      echo "    kernel $MOUNT_PREFIX/vmlinuz-$VERSION"
      if [[ -f "/boot/initrd.img-$VERSION" ]]; then
        echo "    initrd $MOUNT_PREFIX/initrd.img-$VERSION"
      fi
      if [[ -f "/boot/dtb-$VERSION" ]]; then
        echo "    fdt $MOUNT_PREFIX/dtb-$VERSION"
      else
        if [[ ! -d "/boot/dtbs/$VERSION" ]]; then
          mkdir -p /boot/dtbs
          cp -au "/usr/lib/linux-image-$VERSION" "/boot/dtbs/$VERSION"
        fi
        echo "    devicetreedir $MOUNT_PREFIX/dtbs/$VERSION"
      fi
      echo "    append $APPEND"
      echo ""
    }
    
    if findmnt /boot >/dev/null; then
      # If we have `/boot` the files are in `/`
      MOUNT_PREFIX=
    else
      # If we don't have `/boot` mount the files are in `/boot`
      MOUNT_PREFIX=/boot
    fi
    
    linux-version list | linux-version sort --reverse | while read VERSION; do
      emit_kernel "$VERSION" "$APPEND"
      emit_kernel "$VERSION" "$APPEND memtest" "-memtest"
    done
    
    exec 1<&-
    
    echo "Installing new extlinux.conf..." 1>&2
    mv /boot/extlinux/extlinux.conf.new /boot/extlinux/extlinux.conf
    

    Ok, das müssten wir etwas anpassen an die verschlüsselte Installation. Hmm, ich denke, Kamil weiß besser wie das geht. Ich passe die bestehende Installation an. Was passt nicht?

    root=LABEL=linux-root    
    

    Das hatten wir ja angepasst

    root=/dev/debian-vg/root
    

    Das mit dem Label sieht wesentlich besser aus. Also verpassen wir dem Root einen Label.

     root@debian:~# blkid
     /dev/sda1: UUID="3148cc20-1c11-43f1-84e4-a3292c1b2611" BLOCK_SIZE="1024" TYPE="ext2" PARTUUID="5e85abe9-0580-45d7-b33d-9e54416bd2fc"
     /dev/sda2: UUID="36d2f400-74b6-4ea2-8934-69051d163a61" TYPE="crypto_LUKS" PARTUUID="74c8e221-818c-4330-b436-a96e0f968e07"
     /dev/mapper/sda2_crypt: UUID="soZ8T5-iRs3-OQ4g-5t0c-cjLz-u0Un-xtCJ21" TYPE="LVM2_member"
     /dev/mapper/debian--vg-root: UUID="ad866237-a016-4a52-a7ce-fbf1c431c69d" BLOCK_SIZE="4096" TYPE="ext4"
     /dev/mapper/debian--vg-swap_1: UUID="5351e892-1516-4b42-9c1e-ff41baa6c26c" TYPE="swap"
    

    Wir sehen, das Root hat kein Label. Also erzeugen wir eines.

    e2label /dev/mapper/debian--vg-root linux-root
    

    Kontrolle

    /dev/sda1: UUID="3148cc20-1c11-43f1-84e4-a3292c1b2611" BLOCK_SIZE="1024" TYPE="ext2" PARTUUID="5e85abe9-0580-45d7-b33d-9e54416bd2fc"
    /dev/sda2: UUID="36d2f400-74b6-4ea2-8934-69051d163a61" TYPE="crypto_LUKS" PARTUUID="74c8e221-818c-4330-b436-a96e0f968e07"
    /dev/mapper/sda2_crypt: UUID="soZ8T5-iRs3-OQ4g-5t0c-cjLz-u0Un-xtCJ21" TYPE="LVM2_member"
    /dev/mapper/debian--vg-root: LABEL="linux-root" UUID="ad866237-a016-4a52-a7ce-fbf1c431c69d" BLOCK_SIZE="4096" TYPE="ext4"
    /dev/mapper/debian--vg-swap_1: UUID="5351e892-1516-4b42-9c1e-ff41baa6c26c" TYPE="swap"
    

    Nun kann man die Dateien vom Kamil so lassen wie sie sind. Ein

    ./update-extlinux.sh
    

    aktualisiert jetzt /boot/extlinux/extlinux.conf automatisch! Netter Nebeneffekt der Spielerei ist, das jetzt auf einmal der angeschlossene Lüfter läuft 🙂 Er lädt jetzt auch das 5.7 dtbs File!

    Aktuelle extlinux.conf

    timeout 10
    menu title select kernel
    
    label kernel-5.7.0-1-arm64
        kernel /vmlinuz-5.7.0-1-arm64
        initrd /initrd.img-5.7.0-1-arm64
        devicetreedir /dtbs/5.7.0-1-arm64
        append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4
    
    label kernel-5.7.0-1-arm64-memtest
        kernel /vmlinuz-5.7.0-1-arm64
        initrd /initrd.img-5.7.0-1-arm64
        devicetreedir /dtbs/5.7.0-1-arm64
        append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4 memtest
    
    label kernel-5.6.0-2-arm64
        kernel /vmlinuz-5.6.0-2-arm64
        initrd /initrd.img-5.6.0-2-arm64
        devicetreedir /dtbs/5.6.0-2-arm64
        append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4
    
    label kernel-5.6.0-2-arm64-memtest
        kernel /vmlinuz-5.6.0-2-arm64
        initrd /initrd.img-5.6.0-2-arm64
        devicetreedir /dtbs/5.6.0-2-arm64
        append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4 memtest
    

    Gut, somit können wir jetzt den Kernel einfach aktualisieren. Und passen die ganze Sache ein wenig an Kamils Arbeitsweise an. Jo, ich habe mich da mittlerweile ein wenig dran gewöhnt 🙂

    Jetzt muss ich nur nochmal nachschauen, wie Kamil das automatisch macht, wenn der installiert wird!?

    posted in ROCKPro64
  • RE: ROCKPro64 - Debian Bullseye

    Und dran denken, wenn ein neuer Kernel kommt, muss die Datei

    /boot/extlinux/extlinux.conf
    

    bearbeitet werden. Hier mit Kernel 5.7.0-1

    timeout 10
    menu title select kernel
    
    label kernel-5.7.0-1
        kernel /vmlinuz-5.7.0-1-arm64
        initrd /initrd.img-5.7.0-1-arm64
        devicetreedir /dtbs/5.6.0-1137-ayufan-ge57f05e7bf8f
        append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=/dev/debian-vg/root rootwait rootfstype=ext4
    
    label kernel-5.6.0-1137-ayufan-ge57f05e7bf8f-memtest
        kernel /vmlinuz-5.6.0-1137-ayufan-ge57f05e7bf8f
        initrd /initrd.img-5.6.0-1137-ayufan-ge57f05e7bf8f
        devicetreedir /dtbs/5.6.0-1137-ayufan-ge57f05e7bf8f
        append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4 memtest
    posted in ROCKPro64
  • RE: ROCKPro64 - Debian Bullseye

    Kleine Ergänzung zur verschlüsselten Installation.

    Die Eingabe des Passwortes geht nur über die UART-Schnittstelle. Am ROCKPro64 erfolgt keine Passwortabfrage, sprich auf dem Monitor erscheint nichts. Eine verdeckte Eingabe mit einer USB-Tastatur bringt auch nichts. Die Eingabe kann NUR mittels UART erfolgen. Hmm?

    posted in ROCKPro64
  • RE: Mobian

    Heute ist mir im WIKI aufgefallen, das der u-boot nicht automatisch aktualisiert wird.

    Due to the way u-boot is packaged in Debian, it isn't automatically updated as a bootloader update is a sensitive operation, and mostly device-dependent.

    Da aber im u-boot recht viele wichtige Sachen eingestellt werden, z.B. DRAM Geschwindigkeit, wäre es wohl sinnvoll das zu machen.

    Dafür gibt es den folgenden Befehl

    u-boot-install-pinephone
    

    Beispiel

    root@mobian:~# u-boot-install-pinephone
    Installing u-boot to /dev/mmcblk2...
    grep: .config: Datei oder Verzeichnis nicht gefunden
    FIT description: Configuration to load ATF and SCP before U-Boot
    Created:         Sun Jul  5 08:45:48 2020
     Image 0 (uboot)
      Description:  U-Boot (64-bit)
      Created:      Sun Jul  5 08:45:48 2020
      Type:         Standalone Program
      Compression:  uncompressed
      Data Size:    407000 Bytes = 397.46 KiB = 0.39 MiB
      Architecture: AArch64
      Load Address: 0x4a000000
      Entry Point:  unavailable
     Image 1 (atf)
      Description:  ARM Trusted Firmware
      Created:      Sun Jul  5 08:45:48 2020
      Type:         Firmware
      Compression:  uncompressed
      Data Size:    45445 Bytes = 44.38 KiB = 0.04 MiB
      Architecture: AArch64
      OS:           ARM Trusted Firmware
      Load Address: 0x00044000
     Image 2 (scp)
      Description:  SCP Firmware
      Created:      Sun Jul  5 08:45:48 2020
      Type:         Firmware
      Compression:  uncompressed
      Data Size:    13420 Bytes = 13.11 KiB = 0.01 MiB
      Architecture: OpenRISC 1000
      OS:           Unknown OS
      Load Address: 0x00050000
     Image 3 (fdt_1)
      Description:  sun50i-a64-pinephone-1.0
      Created:      Sun Jul  5 08:45:48 2020
      Type:         Flat Device Tree
      Compression:  uncompressed
      Data Size:    29180 Bytes = 28.50 KiB = 0.03 MiB
      Architecture: Unknown Architecture
     Image 4 (fdt_2)
      Description:  sun50i-a64-pinephone-1.1
      Created:      Sun Jul  5 08:45:48 2020
      Type:         Flat Device Tree
      Compression:  uncompressed
      Data Size:    29176 Bytes = 28.49 KiB = 0.03 MiB
      Architecture: Unknown Architecture
     Image 5 (fdt_3)
      Description:  sun50i-a64-pinephone-1.2
      Created:      Sun Jul  5 08:45:48 2020
      Type:         Flat Device Tree
      Compression:  uncompressed
      Data Size:    29164 Bytes = 28.48 KiB = 0.03 MiB
      Architecture: Unknown Architecture
     Default Configuration: 'config_1'
     Configuration 0 (config_1)
      Description:  sun50i-a64-pinephone-1.0
      Kernel:       unavailable
      Firmware:     atf
      FDT:          fdt_1
      Loadables:    uboot
                    scp
     Configuration 1 (config_2)
      Description:  sun50i-a64-pinephone-1.1
      Kernel:       unavailable
      Firmware:     atf
      FDT:          fdt_2
      Loadables:    uboot
                    scp
     Configuration 2 (config_3)
      Description:  sun50i-a64-pinephone-1.2
      Kernel:       unavailable
      Firmware:     atf
      FDT:          fdt_3
      Loadables:    uboot
                    scp
    Writing sunxi-spl
    4+0 Datensätze ein
    4+0 Datensätze aus
    32768 bytes (33 kB, 32 KiB) copied, 0,006429 s, 5,1 MB/s
    Writing u-boot FIT image
    67+1 Datensätze ein
    67+1 Datensätze aus
    555887 bytes (556 kB, 543 KiB) copied, 0,00343555 s, 162 MB/s
    

    Danach neustarten und fertig!

    posted in Software
  • RE: NodeBB - v1.14.0 posted in NodeBB
  • RE: checkmk - Dockerinstallation

    Sichern der Backup Daten aus der CheckMK Installation

    rsync -av /var/lib/docker/volumes/monitoring/_data/backup/ /media/NAS/Dokumente/Sicherungen/checkmk
    posted in Linux
  • RE: Bananapi A20, Debian Buster+grup und Booten von SSD

    Das oben beschriebene bringt nicht den Erfolg, ich habe heute Morgen beim Kaffee mal etwas Zeit investiert, es ist viel einfacher. Das Image auf die SD-Karte UND die HDD schreiben. Beides einstecken und booten.

    Der Bootvorgang der SD-Karte enthält einen u-boot der die HDD erkennt, sofern sie ein bootbares Betriebssystem enthält!

    Problem gelöst - viel Spaß!

    Kleine Anmerkung. Der Bootvorgang sieht total gruselig aus. Der BPi ist lausig langsam. Gut das ich hier keinen mehr im Einsatz habe. Tipp: Kauf dir einen ROCKPro64, dann hat man mit dem SOC auch Spaß 😉 So, jetzt schnell den BPI ausmachen 🙂

    root@bpi-iot-ros-ai:~# df -h
    Filesystem      Size  Used Avail Use% Mounted on
    udev            448M     0  448M   0% /dev
    tmpfs           100M  5.4M   95M   6% /run
    /dev/sda2       6.7G  3.9G  2.5G  62% /
    tmpfs           499M     0  499M   0% /dev/shm
    tmpfs           5.0M  4.0K  5.0M   1% /run/lock
    tmpfs           499M     0  499M   0% /sys/fs/cgroup
    tmpfs           499M  4.0K  499M   1% /tmp
    tmpfs           100M   24K  100M   1% /run/user/1000
    /dev/mmcblk0p1  253M  174M   79M  69% /media/pi/BPI-BOOT
    

    Das Dateisystem wird beim ersten Start auch nicht angepasst - einfach gruselig.

    posted in BananaPi
  • NodeBB - v1.14.0

    Released v1.14.0

    Quelle: https://community.nodebb.org/topic/14880/nodebb-1-14-0-distance-won-t-keep-us-from-moving-forward

    Ein Forum habe ich hochgezogen, alles ok.

    posted in NodeBB
  • RE: Bananapi A20, Debian Buster+grup und Booten von SSD

    Hast du da schon was versaut bei Dir? Ok, von vorne.

    Ich habe das Image installiert, ja hier lag noch ein BPI M1 rum 🙂

    df -h

    pi@bpi-iot-ros-ai:/media/pi/BPI-BOOT$ df -h
    Filesystem      Size  Used Avail Use% Mounted on
    udev            448M     0  448M   0% /dev
    tmpfs           100M  5.4M   95M   6% /run
    /dev/mmcblk0p2  6.7G  3.9G  2.5G  62% /
    tmpfs           499M     0  499M   0% /dev/shm
    tmpfs           5.0M  4.0K  5.0M   1% /run/lock
    tmpfs           499M     0  499M   0% /sys/fs/cgroup
    tmpfs           499M  4.0K  499M   1% /tmp
    tmpfs           100M   20K  100M   1% /run/user/1000
    /dev/mmcblk0p1  253M  174M   79M  69% /media/pi/BPI-BOOT
    

    BOOT Partition = /media/pi/BPI-BOOT

    cd /media/pi/BPI-BOOT
    

    Inhalt

    pi@bpi-iot-ros-ai:/media/pi/BPI-BOOT$ ls -lha
    total 48M
    drwxr-xr-x 5 pi   pi   3.0K Jan  1  1970 .
    drwxr-xr-x 3 root root 4.0K Sep 18  2019 ..
    -rw-r--r-- 1 pi   pi     45 Jun 27  2019 .bpi
    -rw-r--r-- 1 pi   pi    19K Jun 27  2019 COPYING.linux
    drwxr-xr-x 3 pi   pi    512 Jul 29  2019 EFI
    -rw-r--r-- 1 pi   pi   8.2M Aug  3  2019 ISPBOOOT.BIN
    -rw-r--r-- 1 pi   pi   1.5K Jun 27  2019 LICENCE.broadcom
    drwxr-xr-x 8 pi   pi    512 Aug 22  2019 bananapi
    -rw-r--r-- 1 pi   pi    24K Jun 27  2019 bcm2708-rpi-b-plus.dtb
    -rw-r--r-- 1 pi   pi    23K Jun 27  2019 bcm2708-rpi-b.dtb
    -rw-r--r-- 1 pi   pi    23K Jun 27  2019 bcm2708-rpi-cm.dtb
    -rw-r--r-- 1 pi   pi    24K Jun 27  2019 bcm2708-rpi-zero-w.dtb
    -rw-r--r-- 1 pi   pi    23K Jun 27  2019 bcm2708-rpi-zero.dtb
    -rw-r--r-- 1 pi   pi    25K Jun 27  2019 bcm2709-rpi-2-b.dtb
    -rw-r--r-- 1 pi   pi    27K Jun 27  2019 bcm2710-rpi-3-b-plus.dtb
    -rw-r--r-- 1 pi   pi    26K Jun 27  2019 bcm2710-rpi-3-b.dtb
    -rw-r--r-- 1 pi   pi    25K Jun 27  2019 bcm2710-rpi-cm3.dtb
    -rw-r--r-- 1 pi   pi    39K Jun 27  2019 bcm2711-rpi-4-b.dtb
    -rw-r--r-- 1 pi   pi    52K Jun 27  2019 bootcode.bin
    -rw-r--r-- 1 pi   pi    181 Jun 27  2019 cmdline.txt
    -rw-r--r-- 1 pi   pi   1.8K Aug  4  2019 config.txt
    -rw-r--r-- 1 pi   pi   6.6K Jun 27  2019 fixup.dat
    -rw-r--r-- 1 pi   pi   6.0K Jun 27  2019 fixup4.dat
    -rw-r--r-- 1 pi   pi   3.0K Jun 27  2019 fixup4cd.dat
    -rw-r--r-- 1 pi   pi   9.0K Jun 27  2019 fixup4db.dat
    -rw-r--r-- 1 pi   pi   9.0K Jun 27  2019 fixup4x.dat
    -rw-r--r-- 1 pi   pi   2.6K Jun 27  2019 fixup_cd.dat
    -rw-r--r-- 1 pi   pi   9.6K Jun 27  2019 fixup_db.dat
    -rw-r--r-- 1 pi   pi   9.6K Jun 27  2019 fixup_x.dat
    -rw-r--r-- 1 pi   pi    145 Jun 21  2019 issue.txt
    -rw-r--r-- 1 pi   pi   4.8M Jun 27  2019 kernel.img
    -rw-r--r-- 1 pi   pi   5.1M Jun 27  2019 kernel7.img
    -rw-r--r-- 1 pi   pi   5.4M Jun 27  2019 kernel7l.img
    drwxr-xr-x 2 pi   pi    15K Aug  4  2019 overlays
    -rw-r--r-- 1 pi   pi   2.8M Jun 27  2019 start.elf
    -rw-r--r-- 1 pi   pi   2.7M Jun 27  2019 start4.elf
    -rw-r--r-- 1 pi   pi   745K Jun 27  2019 start4cd.elf
    -rw-r--r-- 1 pi   pi   4.5M Jun 27  2019 start4db.elf
    -rw-r--r-- 1 pi   pi   3.6M Jun 27  2019 start4x.elf
    -rw-r--r-- 1 pi   pi   670K Jun 27  2019 start_cd.elf
    -rw-r--r-- 1 pi   pi   4.7M Jun 27  2019 start_db.elf
    -rw-r--r-- 1 pi   pi   3.7M Jun 27  2019 start_x.elf
    -rw-r--r-- 1 pi   pi   316K Aug  6  2019 u-boot.img
    

    Die Datei cmdline.txt lautet

    dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
    

    Somit würde ich das genauso machen, wie im oben verlinkten Artikel. Das ROOT System mittels dd auf die angeschlossene HDD. Dann die cmdline.txt anpassen.

    dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/sda1 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
    

    Danach den BPi neustarten - Fertig!

    posted in BananaPi