Skip to content

Booten von der NVMe Platte

ROCKPro64
  • Wenn alles funktionieren würde, könnte man den u-boot in den SPI-Speicher flashen und dann würde der ROCKPro64 von der NVMe-Platte booten. Das unterstützt der u-boot aktuell nicht und das SPI flashen funktioniert meiner Meinung nach auch noch nicht. Meine letzten Versuche waren zu mindestens erfolglos.

    Früher auf den BananaPi's haben wir ja immer das Rootverzeichnis umgebogen auf die Festplatte und auf der SD-Karte den Aufruf entsprechend angepasst. Dann brauchte man die SD-Karte nur kurz zum Starten, aber alles andere passierte dann auf der Festplatte. Die bessere Wahl, vor allen Dingen wenn man billige SD-Karten einsetzt.

    Dann versuchen wir es mal, ob man das auch entsprechend umbiegen kann.

    Hardware

    • ROCKPro64
    • NVMe PCIe Karte
    • Samsung 960 EVO m.2 256GB

    Software-Empfehlung.

    Kamil's 0.7.11 als bionic-minimal-rockpro64-0.7.11-1075-arm64.img.xz

    Den aktuellsten Kernel den man benutzen kann ist 4.4.154-1128-rockchip-ayufan

    Mainline teste ich zu einem späteren Zeitpunkt.

    Vorbereitungen

    Das Image auf eine SD-Karte schreiben, damit den ROCKPro64 booten. Danach den aktuellsten Kernel installieren.
    Die vier Files von https://github.com/ayufan-rock64/linux-kernel/releases/ runterladen. Danach installieren.

    sudo dpkg -i *.deb
    

    Reboot. Danach bitte die Schritte in dieser Anleitung abarbeiten. Somit wären wir nun auf einem aktuellen Stand. Jetzt an die Hardware.

    Partitionen löschen (PCIe-NVMe-SSD)

    rock64@rp64_nextcloud:~$ sudo fdisk /dev/nvme0n1
    
    Welcome to fdisk (util-linux 2.31.1).
    Changes will remain in memory only, until you decide to write them.
    Be careful before using the write command.
    
    
    Command (m for help): p
    Disk /dev/nvme0n1: 465,8 GiB, 500107862016 bytes, 976773168 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: dos
    Disk identifier: 0x76dd7679
    
    Device         Boot   Start       End   Sectors  Size Id Type
    /dev/nvme0n1p1 *       2048   1499135   1497088  731M 83 Linux
    /dev/nvme0n1p2      1501182 976771071 975269890  465G  5 Extended
    /dev/nvme0n1p5      1501184 976771071 975269888  465G 83 Linux
    
    Command (m for help): d
    Partition number (1,2,5, default 5): 
    
    Partition 5 has been deleted.
    
    Command (m for help): d
    Partition number (1,2, default 2): 
    
    Partition 2 has been deleted.
    
    Command (m for help): d
    Selected partition 1
    Partition 1 has been deleted.
    
    Command (m for help): 
    
    
    Command (m for help): d
    No partition is defined yet!
    Could not delete partition 366717289473
    
    Command (m for help): w
    
    The partition table has been altered.
    Calling ioctl() to re-read partition table.
    Syncing disks.
    

    Partition anlegen

    rock64@rp64_nextcloud:~$ sudo fdisk /dev/nvme0n1
    
    Welcome to fdisk (util-linux 2.31.1).
    Changes will remain in memory only, until you decide to write them.
    Be careful before using the write command.
    
    
    Command (m for help): n
    Partition type
       p   primary (0 primary, 0 extended, 4 free)
       e   extended (container for logical partitions)
    Select (default p): p
    Partition number (1-4, default 1): 1
    First sector (2048-976773167, default 2048): 
    Last sector, +sectors or +size{K,M,G,T,P} (2048-976773167, default 976773167): 
    
    Created a new partition 1 of type 'Linux' and of size 465,8 GiB.
    Partition #1 contains a ext4 signature.
    
    Do you want to remove the signature? [Y]es/[N]o: Y
    
    The signature will be removed by a write command.
    
    Command (m for help): w
    The partition table has been altered.
    Calling ioctl() to re-read partition table.
    Syncing disks.
    

    Partition formatieren

    rock64@rp64_nextcloud:~$ sudo mkfs.ext4 /dev/nvme0n1
    mke2fs 1.44.1 (24-Mar-2018)
    Found a dos partition table in /dev/nvme0n1
    Proceed anyway? (y,N) y
    Discarding device blocks: done                            
    Creating filesystem with 122096646 4k blocks and 30531584 inodes
    Filesystem UUID: 7ec25e75-55c9-4d5d-ba79-be53459d7cf9
    Superblock backups stored on blocks: 
    	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    	102400000
    
    Allocating group tables: done                            
    Writing inode tables: done                            
    Creating journal (262144 blocks): done
    Writing superblocks and filesystem accounting information: done  
    

    Disk Label erstellen

    sudo e2label /dev/nvme0n1 TEST
    

    Label anzeigen

    rock64@rockpro64:/boot/extlinux$ sudo blkid
    /dev/mmcblk0p6: SEC_TYPE="msdos" LABEL="boot" UUID="F4D5-2B6F" TYPE="vfat" PARTLABEL="boot" PARTUUID="7c5ac738-ff0f-458f-a5af-a4c8e68d4eb2"
    /dev/mmcblk0p7: LABEL="linux-root" UUID="94cf8a89-37ac-40f6-8ead-97986ad4c98f" TYPE="ext4" PARTLABEL="root" PARTUUID="e5904a49-a20b-4300-9e2d-538409b62957"
    /dev/nvme0n1: LABEL="TEST" UUID="fa0af070-498d-4c88-af1f-126f0390e5b8" TYPE="ext4"
    /dev/zram0: UUID="cc0465f6-402f-41dd-b980-41f52d65a3fd" TYPE="swap"
    /dev/zram1: UUID="31513e1d-e80d-4b27-98b1-bf2bdbee302b" TYPE="swap"
    /dev/zram2: UUID="c62d350e-61ee-433d-9b5a-63e5d6459c84" TYPE="swap"
    /dev/zram3: UUID="a6306cf0-8e68-47d1-9c39-6a46f68bd912" TYPE="swap"
    /dev/zram4: UUID="10375922-5008-4f22-beb5-0d09c0f398d0" TYPE="swap"
    /dev/zram5: UUID="a1911e3e-0589-4927-ac12-92e37b0e8e9b" TYPE="swap"
    /dev/mmcblk0: PTUUID="2c9a4a22-7aa8-4a1b-815e-0c3e2e7065e6" PTTYPE="gpt"
    /dev/mmcblk0p1: PARTLABEL="loader1" PARTUUID="45411944-1c6e-4279-8d0b-138e5d048f46"
    /dev/mmcblk0p2: PARTLABEL="reserved1" PARTUUID="aae3009f-3c99-4421-801a-d7e8d25ba5b4"
    /dev/mmcblk0p3: PARTLABEL="reserved2" PARTUUID="512b7b26-a5b8-4e8d-a362-fd692f4fd316"
    /dev/mmcblk0p4: PARTLABEL="loader2" PARTUUID="88a77e9a-27e0-40e7-899b-effcabc6dcaa"
    /dev/mmcblk0p5: PARTLABEL="atf" PARTUUID="b03779fe-7974-40a7-879d-2fe630f01ba2"
    

    Mounten der SSD

    Wir mounten nach /mnt

    sudo mount /dev/nvme0n1 /mnt
    

    Root Verzeichnis kopieren

    Nun kopieren wir die komplette SD-Karte auf die SSD.

    sudo rsync -ax / /mnt/
    

    Bootparameter ändern

    sudo nano /boot/extlinux/extlinux.conf
    

    Inhalt

    root=LABEL=linux-root
    

    ändern in

    root=LABEL=TEST
    

    Abspeichern - Fertig! Neustarten!

    Kontrolle

    Nach einem Neustart schauen wir uns mal eben die Platten an

    rock64@rockpro64:~$ df -h
    Filesystem      Size  Used Avail Use% Mounted on
    udev            1.9G     0  1.9G   0% /dev
    tmpfs           388M  460K  388M   1% /run
    /dev/nvme0n1    229G  1.4G  216G   1% /
    tmpfs           1.9G     0  1.9G   0% /dev/shm
    tmpfs           5.0M  4.0K  5.0M   1% /run/lock
    tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
    /dev/mmcblk0p6  112M  4.0K  112M   1% /boot/efi
    tmpfs           388M     0  388M   0% /run/user/1000
    

    Da ist die NVMe Platte mit 229GB Kapazität.

    Den oberen Teil habe ich am 1. März 2019 aktualisiert, der Rest folg noch!

    Problem

    Im Moment geht nur ein Kaltstart, ein Reset am Taster oder auch ein

    sudo shutdown -r now
    

    funktionieren im Moment nicht. Muss ich mich mal auf die Suche machen 😉

    Update
    Ein shutdown now funktioniert einwandfrei, auch nach dem Aufwecken über den Power-Button.

    Kernel-Update

    Aufpassen, bei einem Kernel-Update müsst ihr die Änderungen in der Datei /boot/extlinux/extlinux.conf wiederholen.

    Das Problem gestaltet sich etwas komplexer. Da wir ja bei dem Kernel-Update auf der NVMe-Karte rumrödeln, ist auf der SD-Karte der Ordner /boot nicht aktuell, so das immer wieder der alte Kernel geladen werden würde.

    Aber, auch das lässt sich relativ einfach anpassen. Wir sind im gestarteten System mit dem aktualisierten Kernel. Bevor wir neustarten, machen wir nun das.

    Die SD-Karte mounten

    sudo mount /dev/mmcblk0p7 /mnt
    

    Den alten Ordner /boot sichern

     sudo mv /mnt/boot /mnt/boot_BAK
    

    Den Ordner /boot von der NVMe-Karte kopieren

    sudo cp -r /boot /mnt/boot
    

    Die Datei extlinux.conf wieder anpassen

    sudo nano /mnt/boot/extlinux/extlinux.conf
    

    Das kennt ihr ja jetzt schon 😉 Danach ist der Ordner /boot auf der SD-Karte und der NVMe-Karte identisch und das System startet den neuen Kernel. Ok, etwas umständlich, aber leider geht SPI Flash ja noch nicht. Und ob das dann mit NVMe geht steht noch in den Sternen. Aber so kann man ja auch erst mal was spielen 🙂

    Aktuelles System

    rock64@rockpro64:~$ uname -a
    Linux rockpro64 4.4.132-1081-rockchip-ayufan-g50be7e64a779 #1 SMP Tue Jul 31 20:09:25 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
    

    Laufwerke

    rock64@rockpro64:~$ df -h
        Filesystem      Size  Used Avail Use% Mounted on
        udev            1.9G     0  1.9G   0% /dev
        tmpfs           388M  444K  388M   1% /run
        /dev/nvme0n1    229G  1.4G  216G   1% /
        tmpfs           1.9G     0  1.9G   0% /dev/shm
        tmpfs           5.0M  4.0K  5.0M   1% /run/lock
        tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
        /dev/mmcblk0p6  112M  4.0K  112M   1% /boot/efi
        tmpfs           388M     0  388M   0% /run/user/1000
    

    Mainline

    Mit dem Mainline-Kernel habe ich kein funktionierendes System hinbekommen.

  • Mainline hat jetzt jemand hinbekommen.

    forum.pine64.org

    Test folgt heute nachmittag 😉

  • Das aus dem Forum geht perfekt. Thank You Dukla2000

    Ich wusste erst nicht so recht wie ich das mit meiner vorhanden Installation durchführen soll. Aber ist relativ easy 😉 Heute mal in Kurzform.

    • SD-Karte mit 4.4.x flashen.
    • Auf 4.18 bringen
    • Änderungen durchführen
    • Die NVMe SSD mounten
    • boot Ordner sichern
    • boot Ordner von der SD-Karte auf die NVMe SSD kopieren
    • Die extlinux.conf auf SD-Karte und NVMe SSD ändern!
    • Neustart - fertig!
  • @FrankM Hi, Do we need to mount the NVMe at the time of boot by updating fstab in order for the system to boot from the NVMe? Thanks , Deva

  • @rdevarajan No, you don't need to edit /etc/fstab

  • @FrankM thank you Frank. Shall try it out .

  • Mal mit 0.7.11 und dem Kernel 4.4.154-1128 erneut getestet und das Howto ein wenig angepasst und ergänzt.

  • @FrankM
    halli hallo,
    ein vorschlag von mir dazu.

    das root ist nach dem o.g. prozedere nun auf der nvme platte. kernel und konsorten sind weiterhin auf der sd/emmc. Weil der uboot nur das findet. Soweit so gut. Wenn mit laufendem root nun ein neuer kernel und konsorten erzeugt werden, müssen die auf sd/emmc, weil sonst nicht verwendet.

    Das lässt sich am einfachsten erledigen, indem man sd/emmc als boot in das root mounted. Das ist quasi ein einblenden. Wie auch immer man das erledigt (fstab, autofs/manuell/etc/pp/sucht euch was aus). Dann arbeitet der ganze prozess immer schon auf dem ziel und legt keine kopien an.

    gruß

  • Danke @kosmonaut-pirx , ich habe da schon ein paar Mal drüber nachgedacht und heute Morgen auch kurz ein paar Tests gemacht, aber da bin ich irgendwie zu blöd für 🙂

    Da ich aktuell auch nicht vor habe, den Kernel zu updaten lass ich es erst mal so. Würde mich aber freuen, wenn jemand eine funktionierende Lösung hat.

    Das steht aktuell in der Datei /etc/fstab

    LABEL=boot /boot/efi vfat defaults,sync 0 0
    
  • @FrankM
    naja, dein fstab entry mounted nur nach /boot/efi. D.h. irgendwoher kommt das /boot parent schon. Gehört vielleicht zum root dazu, das weiß ich aber nicht. Und ich gehe mal davon aus, dass dein kernel unter /boot liegt und nicht unter /boot/efi 🙂

    als ein beispiel: hier einmal meine partitionstabelle:

    code_textGerät          Anfang     Ende Sektoren Typ-UUID                             UUID                                 Name      Attr.
    /dev/mmcblk0p1     64     8063     8000 0FC63DAF-8483-4772-8E79-3D69D8477DE4 D44AD46E-C52B-4CB4-9C75-7CC0F6AACFF7 loader1   
    /dev/mmcblk0p2   8064     8191      128 0FC63DAF-8483-4772-8E79-3D69D8477DE4 C9C0BC0D-6DAC-4A00-B35F-7222CDD9AEA9 reserved1 
    /dev/mmcblk0p3   8192    16383     8192 0FC63DAF-8483-4772-8E79-3D69D8477DE4 465252D7-4F2C-4476-826C-609F1060C307 reserved2 
    /dev/mmcblk0p4  16384    24575     8192 0FC63DAF-8483-4772-8E79-3D69D8477DE4 464A9658-E15B-4ACA-8DD9-7B105807324C loader2   
    /dev/mmcblk0p5  24576    32767     8192 0FC63DAF-8483-4772-8E79-3D69D8477DE4 D22AE41D-5CEE-4BF0-B35D-ED193830B54A atf       
    /dev/mmcblk0p6  32768   262143   229376 EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 277BAD52-9EB3-4A1E-842C-C584A1822F2B boot      
    /dev/mmcblk0p7 262144   876543   614400 0FC63DAF-8483-4772-8E79-3D69D8477DE4 0E38AF18-077C-4AE2-89E1-DD2680E47C6D root      LegacyBIOSBootable
    /dev/mmcblk0p8 876544 15269854 14393311 0FC63DAF-8483-4772-8E79-3D69D8477DE4 A56E8046-FCAD-5243-9A87-D7DED604866E           
    
    

    sieht vermutlich überall ähnlich aus. dazu ein paar notizen:

    • von partition p1 bis p5 kann man alles ignorieren. Meiner meinung nach ist die hälfte überflüssig, aber das ist hier out of scope und/oder ich mag falsch liegen
    • paritition p6 hat jemand "boot" benannt. Das entspricht dem o.g. efi-mount. Ob man das wirklich braucht ist auch wieder eine andere frage, s.o.
    • partition p7 ist die wichtigste. Das label .. ist unwichtig. Die partition ist aber mit Bootable gekennzeichnet. Das ist das flag, welches der uboot benutzt um nach dem kernel zu suchen. Btw, hat mich stunden gekostet, das zu evaluieren. Dort in der partition muss der kernel liegen bzw. besser gesagt: das ext-linux conf
    • partition p8 ist hier das sys root

    bei mir ist das fstab dann entsprechend

    UUID=928fbf89-87f9-45c0-8f26-d6b6ad15e9f3	/boot	ext4	noatime	1	2
    UUID=e62dbec1-7b17-4242-b133-1a98d1aaf32b	/	ext4	noatime	0	1
    LABEL=boot	/boot/efi	vfat	defaults,sync	0	0
    

    erster eintrag ist da wo der kernel liegt (ja die uuids passen nicht zu denen aus o.g. liste), zweiter eintrag ist das sys root, und dritter eintrag wie bekannt. Damit hat man das /boot gefüllt mit dem, was der uboot "sieht"

    gruß

  • Vielen Dank für den Tipp. Ich habe da heute Morgen mal mit rumgespielt, jetzt ist die Installation kaputt 🙂

    Ein Image vom Kamil, bionic-minimal, was ich schon von Anfang an nur benutze sieht wie folgt aus.

    rock64@rockpro64:~$ sudo blkid
    /dev/mmcblk0: PTUUID="57682308-b92c-4d66-ae74-9f0ad2059819" PTTYPE="gpt"
    /dev/mmcblk0p1: PARTLABEL="loader1" PARTUUID="58c8a80d-a7fb-4b74-a7fc-414be0a692ff"
    /dev/mmcblk0p2: PARTLABEL="reserved1" PARTUUID="91b9a739-2540-423a-a1b0-2da8a1645c11"
    /dev/mmcblk0p3: PARTLABEL="reserved2" PARTUUID="2d4c9c31-153f-43da-a9d9-8ed60581b2c4"
    /dev/mmcblk0p4: PARTLABEL="loader2" PARTUUID="df727104-fb01-4622-b983-612af8220f6a"
    /dev/mmcblk0p5: PARTLABEL="atf" PARTUUID="ca76f1f0-b226-471c-b181-71b2370c64b1"
    /dev/mmcblk0p6: SEC_TYPE="msdos" LABEL="boot" UUID="2C5B-5CAF" TYPE="vfat" PARTLABEL="boot" PARTUUID="4c5e58d7-b449-49d7-ae30-e519c8c206cb"
    /dev/mmcblk0p7: LABEL="linux-root" UUID="d4e1b4d0-338c-42ec-86f2-6890d3e61eea" TYPE="ext4" PARTLABEL="root" PARTUUID="4f0eec35-c6c0-420a-b56f-86b75901d1f1"
    /dev/nvme0n1: LABEL="TEST" UUID="378c1065-8e5b-462c-8773-57e258720299" TYPE="ext4"
    

    zram mal rausgelöscht. Das war der Zustand, nachdem ich das Rootsystem auf die NVMe SSD gelegt hatte und neugestartet habe.

    Sieht dann so aus

    rock64@rockpro64:~$ df -h
    Filesystem      Size  Used Avail Use% Mounted on
    udev            992M     0  992M   0% /dev
    tmpfs           200M  452K  199M   1% /run
    /dev/nvme0n1    229G  1.3G  216G   1% /
    tmpfs           996M     0  996M   0% /dev/shm
    tmpfs           5.0M  4.0K  5.0M   1% /run/lock
    tmpfs           996M     0  996M   0% /sys/fs/cgroup
    /dev/mmcblk0p6  112M  4.0K  112M   1% /boot/efi
    tmpfs           200M     0  200M   0% /run/user/1000
    

    Ich habe dann versucht, die partition7 nach /boot einzuhängen, das funktionierte auch so weit.

    ABER

    Dann habe ich natürlich auf /boot das ganze Filesystem eingehangen. Bringt nix. Hmm!?!?

    Habe dann versucht das Ganze nach /media zu mounten und zusätzlich den Ordner boot von der Partition7 nach /boot.

    # Ganze Partition in /media einbinden:
    UUID=bbf85ecb-cc61-40ed-ba7b-d7b804ee845e   /media   ext4   defaults   0   0
    # Ordner "boot" zusätzlich in /boot einbinden:
    /media/boot  /boot  none  bind  0  0
    

    Das funktionierte so weit auch gut, reboot war einwandfrei. Mit df -h sah auch alles gut aus. Dann einen anderen Kernel installiert, sah immer noch gut aus, nach dem Neustart war das System platt. Seltsamerweise irgendwas mit der MMC-Karte!?

    Nein, das ist nicht mein Spezialgebiet 😂

  • @FrankM
    hm..

    Dann habe ich natürlich auf /boot das ganze Filesystem eingehangen. Bringt nix. Hmm!?!?
    

    was meinst du damit, das ganze filesystem? wenn du partition p7 so mountest, solltest du die kernel/initrd/dtb geschichte sehen. Da fehlt dann das efi dingens, weil das von der anderen partition p6 kommt. kA ob man das braucht.

    in p7 bzw /boot ist dann das extlinux, was alles beschreibt. was da jetzt nicht passt, schwer zu sagen von ausserhalb. klar müssen vmlinuz (oder wie auch immer genannt) initrd (wie auch immer gen..) und dtb (wie auc..) noch da sein.

    für den rest steht man grad auf dem schlauch, was nicht tun sollte. im prinzip ist das alles logisch 🙂

  • @FrankM

    I only recently found this forum and I like it because it has usefull information for me.
    In writing I'm better in English than in German, but reading in German in no problem, so I can understand your posts. I hope you can understand my post in English.

    I have a rockpro64 with nvme-card and I managed to put root on it, according to your post above. I have tried to put LVM on my nvme-card and put root on a logical volume on LVM but then I cannot boot anymore. I think the system needs a module to manage LVM at boot, but I don't know how to do that. Do you have a suggestion or a solution?

  • Hello @ftim ,

    first i don't know many about lvm. But i think you will need the kernel-modul.

    modprobe lvm-mod 
    

    give an error, not found....

    When i look into kernel config i found nothing. Please ask Ayufan on IRC or in the forum to build the next release with this module.

  • hello,
    most likely a module will not do it, I guess. Assume the kernel wants to "load" the root. It needs to know lvm functionality for this, in case the root is in a lvolume. Unfortunately, that module is located in (exactly) that lvolume.
    In my understanding, here's where the initrd comes into play. But i might be wrong
    regards

  • Für dies Kernal: Linux rockpro64 4.4.167-1213-rockchip-ayufan-g34ae07687fce #1 SMP Tue Jun 18 20:44:49 UTC 2019 aarch64 GNU/Linux

    Booten von der NVMe Platte nicht möglich.

    Ich folgte die folgende Schritte. Leider funktioniert es nicht. Es gibt einen Fehler in Boot.

    Ohne RAID oder LVM config.

    Specs:
    Rockpro64
    Marvel PCIe 88se9230 karte
    SANDISK SSD 120 GB

  • Armbian 20.08 (Caple) released

    Armbian
    1
    0 Stimmen
    1 Beiträge
    333 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - Debian Bullseye Teil 2

    Verschoben ROCKPro64
    3
    0 Stimmen
    3 Beiträge
    433 Aufrufe
    FrankMF

    Gestern mal das Ganze mit einem Cinnamon Desktop ausprobiert. Eine verschlüsselte Installation auf eine PCIe NVMe SSD. So weit lief das alles reibungslos. Der Cinnamon Desktop hat dann leider keine 3D Unterstützung. Sieht so aus, als wenn keine vernünftigen Grafiktreiber genutzt würden. Da ich auf diesem Gebiet aber eine Null bin, lassen wir das mal so. Außerdem mag ich sowieso keine Desktops auf diesen kleinen SBC. Da fehlt mir einfach der Dampf 😉

    Gut, was ist mir so aufgefallen?

    Unbedingt die Daten des Daily Images erneuern, keine alten Images nutzen. Ich hatte da jetzt ein paar Mal Schwierigkeiten mit. Da das ja nun keine Arbeit ist, vorher einfach neu runterladen und Image bauen.

    Warum zum Henker bootet eigentlich. außer meiner Samsung T5, nichts vom USB3 oder USB-C Port?? 👿

  • ROCKPro64 - Projekt Wireguard Server

    Verschoben ROCKPro64
    2
    0 Stimmen
    2 Beiträge
    485 Aufrufe
    FrankMF

    Hat ein wenig Nerven gekostet und der Artikel ist auch was länger geworden 🙂 Viel Spaß beim Lesen und testen!

  • Image 0.9.16 - Kurztest

    ROCKPro64
    5
    0 Stimmen
    5 Beiträge
    389 Aufrufe
    FrankMF

    Kurzer Test, ok ist was länger geworden 🙂 Mit Debian Buster Minimal habe ich es nicht hinbekommen 😞 Das soll aber nicht heißen, das es nicht geht. WLan auf der Konsole ist nicht meine Stärke. Ok, dann Desktop.

    bionic-mate-rockpro64-0.9.16-1163-armhf.img.xz

    Installiert, kurz WLan 5G aktiviert, eingeloggt. Netzwerkkabel entfernt. Firefox angeworfen, Rammstein Viedo in 1080p angeworfen. Läuft alles einwandfrei.

    b834128c-30c3-43cd-ba43-b69b41783b57-grafik.png

    Und PCIe NVMe SSD geht auch 😉

    Das Desktop System ist mittlerweile richtig gut zu benutzen. Aber ich bin verwöhnt, mir ist das immer viel zu langsam. Das soll aber niemanden davon abhalten, sich das mal anzusehen. Je nach Einsatzzweck sicherlich interessant.

  • H.265/x265 dekodiert und wiedergegeben (4K Video)

    ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    434 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - USB-OTG funktioniert!

    ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    538 Aufrufe
    Niemand hat geantwortet
  • zram - Was das??

    ROCKPro64
    3
    0 Stimmen
    3 Beiträge
    927 Aufrufe
    FrankMF

    @tkaiser ; Ich hab dich vermisst 😂

    Danke für die Info, ich bin vor dem ROCKPro64 da noch nie so richtig drüber gestolpert. Aber wenn ich dann was finde, schau auch immer wofür es denn bitte ist.

    Danke für Deine Hinweise.

  • 2GB Version - Out of stock

    Verschoben Archiv
    1
    0 Stimmen
    1 Beiträge
    717 Aufrufe
    Niemand hat geantwortet