Skip to content

Quartz64 - Modell B - Manjaro Rootverzeichnis ändern

Quartz64
  • Der Plan, da die SD-Karte ja aktuell nicht so der Burner ist, das Rootverzeichnis zu verschieben. Da die Platte am USB3-Port sehr gute Daten liefert, benutzen wir mal diese.

    Hardware

    • Quartz64 Modell B
    • Festplattenmodell: Samsung SSD 970 EVO 500GB am USB3-Port

    Software

    Auf der Standardinstallation fehlt rsync

    pacman -S rsync
    

    SSD mounten

    Die SSD wird ja vom Manjaro gemountet nach Media. Mal auf sicher entfernen klicken. Ich setze voraus, das die SSD formatiert ist und ein ext4 Dateisystem hat.

    Wir erzeugen ein Verzeichnis

    mkdir /mnt/sda
    

    Wir mounten das Verzeichnis

    mount /dev/sda1 /mnt/sda
    

    Rootverzeichnis kopieren

    Wir kopieren das Rootverzeichnis von der SD-Karte auf die SSD.

     rsync -ax / /mnt/sda
    

    Bootverzeichnis mounten

    Nachdem das Rootverzeichnis auf der SSD liegt, müssen wir Manjaro auch mitteilen, das es dieses Rootverzeichnis nutzen soll.

    Dazu brauchen wir die Boot-Partition der SD-Karte

    mkdir /mnt/boot
    

    Danach schauen wir uns kurz die Struktur an

    fdisk -l
    Gerät           Anfang     Ende Sektoren  Größe Typ
    /dev/mmcblk0p1   62500  1000000   937501 457,8M Microsoft Basisdaten
    /dev/mmcblk0p2 1000001 62333918 61333918  29,2G Linux-Dateisystem
    
    • p1 ist die Boot-Partition
    • p2 ist die Root-Partition

    Wir mounten die Boot-Partition

    mount /dev/mmcblk0p1 /mnt/boot
    

    Wir wechseln das Verzeichnis

    cd /mnt/boot
    

    Inhalt

    [root@frank-pc boot]# ls -lha
    insgesamt 36M
    drwxr-xr-x 4 frank frank   16K  1. Jan 1970  .
    drwxr-xr-x 5 root  root   4,0K  4. Jun 11:17 ..
    drwxr-xr-x 3 frank frank  8,0K 30. Mai 06:07 dtbs
    drwxr-xr-x 2 frank frank  8,0K  3. Jun 16:50 extlinux
    -rw-r--r-- 1 frank frank  172K  7. Apr 20:03 idbloader.img
    -rw-r--r-- 1 frank frank   27M  7. Apr 21:28 Image
    -rw-r--r-- 1 frank frank  7,8M 30. Mai 06:08 initramfs-linux.img
    -rw-r--r-- 1 frank frank 1022K  7. Apr 20:03 u-boot.itb
    

    extlinux.conf anpassen

    Uns interessiert das extlinux Verzeichnis

    [root@frank-pc boot]# ls -lha extlinux/
    insgesamt 32K
    drwxr-xr-x 2 frank frank 8,0K  3. Jun 16:50 .
    drwxr-xr-x 4 frank frank  16K  1. Jan 1970  ..
    -rw-r--r-- 1 frank frank  448  4. Jun 11:49 extlinux.conf
    

    Die Datei extlinux.conf enthält die relevanten Informationen.

    LABEL Manjaro ARM
    KERNEL /Image
    FDT /dtbs/rockchip/rk3566-quartz64-b.dtb
    #APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 root=PARTUUID=14c62b3d-d803-4d00-bd55-d0fa406c20e0 rw rootwait earlycon loglevel=7 audit=0 splash plymouth.ignore-serial-consoles
    APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 root=PARTUUID=032af10e-1655-e545-99d1-af2bb1c43033 rw rootwait earlycon loglevel=7 audit=0 splash plymouth.ignore-serial-consoles
    

    Hier seht ihr meine geänderte Version. In der auskommentierten Zeile steht der Originalinhalt. Wenn was schief läuft, kann man diese Zeile einfach wieder aktivieren. Man sieht, man muss nur die PARTUUID ändern. Kein Hexenwerk 🙂

    [root@frank-pc boot]# blkid
    /dev/nvme0n1p1: UUID="57285d5c-4252-4448-a936-1412a786bf34" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="bd856e70-94c0-3345-a9d6-7ff080b5a2e0"
    /dev/mmcblk0p1: SEC_TYPE="msdos" LABEL_FATBOOT="BOOT_MNJRO" LABEL="BOOT_MNJRO" UUID="3965-3827" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="primary" PARTUUID="e9d3fd70-ae93-45e2-9071-7e4606447125"
    /dev/mmcblk0p2: LABEL="ROOT_MNJRO" UUID="6fd80f31-8069-4c15-947b-252cdfbe680a" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="primary" PARTUUID="14c62b3d-d803-4d00-bd55-d0fa406c20e0"
    /dev/sda1: UUID="e2ba3d08-5481-4117-b980-447d4253afdb" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="032af10e-1655-e545-99d1-af2bb1c43033"
    /dev/zram0: LABEL="zram0" UUID="cd8cab6b-21d7-4453-82b1-2a8e62200e62" TYPE="swap"
    

    Hier sieht man diese, kopiert sich die PARTUUID von sda1 und trägt diese in die extlinux.conf ein. Fertig! Danach einmal neustarten.

    Kontrolle

    Nach dem Neustart schauen wir ob das funktioniert hat.

    [root@frank-pc boot]# df -h
    Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
    dev             1,7G       0  1,7G    0% /dev
    run             1,9G    1,2M  1,9G    1% /run
    /dev/sda1       458G     22G  413G    5% /
    tmpfs           1,9G       0  1,9G    0% /dev/shm
    tmpfs           1,9G     45M  1,8G    3% /tmp
    tmpfs           374M     44K  374M    1% /run/user/1000
    /dev/mmcblk0p1  458M     41M  418M    9% /mnt/boot
    /dev/mmcblk0p2   29G    4,7G   23G   17% /run/media/frank/ROOT_MNJRO
    /dev/nvme0n1p1  458G     17G  418G    4% /run/media/frank/57285d5c-4252-4448-a936-1412a786bf34
    

    Wir achten auf den Eintrag für das Rootverzeichnis.

     /dev/sda1       458G     22G  413G    5% /
    

    Das Rootverzeichnis ist jetzt auf der SSD am USB3-Port. Da man auch aktuell nicht von irgendwas anderem Booten kann außer SD-Karte und eMMC, bieten sich diese Vorgehensweise an wenn man **ein relativ flottes System haben möchte.

    Viel Spaß!**

  • In /etc/fstab den Eintrag zu ändern, könnte auch sinnvoll sein.

    # Static information about the filesystems.
    # See fstab(5) for details.
    
    # <file system> <dir> <type> <options> <dump> <pass>
    #PARTUUID=14c62b3d-d803-4d00-bd55-d0fa406c20e0   /   ext4     defaults    0   1
    PARTUUID=032af10e-1655-e545-99d1-af2bb1c43033   /   ext4     defaults    0   1
    
  • Da gab es doch gestern noch einen bösen Fehler, als ich vom Kernel Linux 5.17.0-2 auf Linux 5.17.0-3 aktualisiert habe, war das System danach kaputt. Hmm, ich habe dann versucht das zu untersuchen und war zu der Erkenntnis gekommen, das das Boot Verzeichnis nicht korrekt gemountet war. Konnte es aber nicht selber lösen 😞

    Dan hat das dann heute erledigt, wenn man jetzt das Image installiert, dann ist auch das Boot Verzeichnis korrekt gemountet.

    [root@frank-pc ~]# df -h
    Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
    dev             1,7G       0  1,7G    0% /dev
    run             1,9G    1,2M  1,9G    1% /run
    /dev/sda1       458G    4,5G  430G    2% /
    tmpfs           1,9G       0  1,9G    0% /dev/shm
    tmpfs           1,9G    9,6M  1,9G    1% /tmp
    /dev/mmcblk0p1  458M     41M  417M    9% /boot
    tmpfs           374M     44K  374M    1% /run/user/1000
    /dev/mmcblk0p2   59G    3,7G   52G    7% /run/media/frank/ROOT_MNJRO
    

    Dann sollte das auch klappen, wenn man wie ich aktuell das Root Verzeichnis auf die SSD am USB3 Port gelegt hat.

  • Quartz64 - Modell B - Stromverbrauch

    Quartz64 - B
    1
    2
    0 Stimmen
    1 Beiträge
    127 Aufrufe
    Niemand hat geantwortet
  • Quartz64 - Modell B - Temperaturen

    Quartz64 - B
    1
    2
    0 Stimmen
    1 Beiträge
    119 Aufrufe
    Niemand hat geantwortet
  • Qurtz64 - Modell B - GPIO

    Quartz64 - B
    1
    1
    0 Stimmen
    1 Beiträge
    93 Aufrufe
    Niemand hat geantwortet
  • Quartz64 - Peter Geis Entwicklungsumgebung

    Images
    3
    1
    0 Stimmen
    3 Beiträge
    171 Aufrufe
    FrankMF
    Das Ergebnis [image: 1638087100769-screenshot_20211128_090851.png] Peters Image benutzt ein Debian Buster 10 root@quartz64:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster Kernel root@quartz64:~# uname -a Linux quartz64 5.16.0-rc2 #1 SMP PREEMPT Sat Nov 27 03:43:14 UTC 2021 aarch64 GNU/Linux Gut an diesem Image vom Peter ist der funktionierende PCIe Port Nicht so gut ist das Image, wenn man längerfristig damit arbeiten möchte. Der Aufbau ist dafür nicht wirklich gut geeignet. Wenn man das möchte, dann benutzt man lieber das Manjaro Image. Das wird gepflegt und man bekommt alle Änderungen und Patches auch geliefert. Ich hoffe, das die PCIe Patches auch bald im Manjaro Image ankommen, doch dafür müssen diese Upstream sein weil das Manjaro diesen Kernel nutzt (linux-rc). Und wie ich heute Morgen gelesen habe, es besteht Hoffnung für einen funktionierenden USB3-Port
  • Quartz64 - Missing SPI ?

    Verschoben Quartz64
    1
    1
    0 Stimmen
    1 Beiträge
    440 Aufrufe
    Niemand hat geantwortet
  • Quartz64 - USB3 oder SATA?

    Verschoben Quartz64 - A
    5
    0 Stimmen
    5 Beiträge
    312 Aufrufe
    T
    Naja, es geht ja jetzt bei "Schnittstelle" um mechanische Konnektoren. Und sowohl mPCIe/mSATA als auch M.2 sehen die unterschiedlichsten Protokolle vor, darunter die populären USB, PCIe und eben SATA. Ich hab bspw. ein Clearfog Pro mit 2 mPCIe/mSATA-Slots, in dem man per u-boot simpel zwischen SATA und PCIe wechseln kann. Und wenn der M.2-Slot auf dem Quartz64 Model B tatsächlich Key B ist, dann bedeutet das, dass man jede – ggf. eh schon herumliegende – M.2-SATA-SSD reinstecken kann, wohingegen dann nur ein paar NVMe-SSDs passen (das Gros ist Key M only, nur paar kommen mit Key B/M). Hmm... eigentlich wäre Key M dann schlauer, denn M.2-SATA-SSDs sind alle Key B/M, und NVMe-SSDs entweder Key M oder auch B/M. Wie auch immer bzw. um den Bogen zu Deinem Quartz64 Model A zu spannen. Ein Billo-Adapter von Aliexpress (wie der hier) sollte reichen, um M.2-SATA-SSDs verwenden zu können (sowas kann wie schon geschrieben eh bereits rumliegen und zumindest sequenzielle Transferraten sind mit SATA einen Tuck schneller als NVMe mit der einen Gen2-Lane des RK3566)
  • Quartz64 - Images

    Angeheftet Verschoben Archiv
    2
    0 Stimmen
    2 Beiträge
    246 Aufrufe
    FrankMF
    Manjaro Images -> https://github.com/manjaro-arm/quartz64-bsp-images/releases Ab Dev 20211117 mit HDMI-Ausgabe!
  • Quartz64 - Modell A lieferbar

    Verschoben Quartz64
    4
    1
    0 Stimmen
    4 Beiträge
    332 Aufrufe
    FrankMF
    Durch den Zoll ist es auch... [image: 1624464737019-aa906c24-2e67-404d-aad2-69fe1832229b-grafik.png]