Skip to content

Interessante Diskussion

Armbian
  • Hmm .. ich habe mich nicht durch den ganzen Thread gelesen, sondern nur die letzten Beiträge und hier das Thema Board-Wildwuchs und .. drop RK3399 gelesen ...

    Ein wenig schade, dass das Armbian RockPro Release in den letzten zwei Monaten nicht mehr ge-updated wurde .. die "Zwischenversion" finde ich weiterhin sehr vielversprechend und die Config-Tools - i.B. die NVMe initierung als "Boot"-Device (eher root Device 🙂 ) und Docker, zsh .. etc.

    Vor ein paar Wochen bin ich bei den Armbian Downloads über den "NanoPC-T4 (auch RK3399)" gestolpert und auch gesehen dass hier der Kernel 5 als nightly build supported wird .. Seit Lieferung liegt der hier leider (aufgrund sonstiger Projekte) noch original Verpackt im Karton. NVMe direkt, ohne Adapter Karte reinstecken war noch ein weiteres Kauf-Argument .. Mal schauen .. derzeit werkelt mein RockPro64 als MySQL bzw. MariaDb für die Entwicklung mit nem gepflegten
    Ayufan 4.4.167-1169-rockchip-ayufan-g3cde5c624c9c seinen Dienst wunderbar ...

  • Ich bin auch nur drüber gestolpert, weil ich in dem Bereich bei github allem folge. So findet man immer was interessantes.

    Man kann es ja ein wenig verstehen, es sind mittlerweile so viele verschiedene RK3399 Boards, und alle sind irgendwie anders, das es kaum Spaß macht, das alles zu pflegen.

    Was an Armbian wirklich idiotensicher ist, ist armbian-config. Das hilft vor allen Dingen Einsteigern ungemein. Man wird sehen wie es sich entwickelt und welche Entscheidungen man bei Armbian trifft.

    Ich persönlich bin mittlerweile sowieso wieder auf allen Boards bei Images vom Kamil. Da hat man einen relativ kurzen Draht, wenn es mal klemmt, anschreiben im IRC und er fixt es. So geschehen, die Tage. Neues Release und beim Booten eine unendliche Pause, irgendwas mit systemd. Kamil angeschrieben, im nächsten Release war dann folgendes drin.

    0.8.0rc9: Fix long start issue due to removed /etc/machine-id,
    

    Getestet, Fehler weg 🙂 Gut, es ist auch nicht alles perfekt was Kamil macht, aber die Images laufen. Also, zu mindestens die ohne GUI 😉

  • Igor schraubt aber noch am Kernel, baut den aktuellen Ayufan Kernel gerade ein.

  • 0 Votes
    1 Posts
    39 Views
    No one has replied
  • Armbian Images

    Armbian
    1
    0 Votes
    1 Posts
    253 Views
    No one has replied
  • TwisterOS

    Images
    1
    0 Votes
    1 Posts
    226 Views
    No one has replied
  • 0 Votes
    2 Posts
    306 Views
    FrankMF

    Müsste seit gestern so weit sein 🙂

    b20f93d2-1719-40c5-afb8-6b4edafa6793-image.png

  • 1 Votes
    1 Posts
    375 Views
    No one has replied
  • 0 Votes
    2 Posts
    584 Views
    FrankMF

    Der frühe Vogel.... 🙂

    IMG_20181226_072626_ergebnis.jpg

    Das oben geschriebene eben nochmal durchgeführt, funktioniert einwandfrei. Jetzt kann ich die USB3-Platte umbauen und den Job verlagern. Dann habe ich einen ROCKPro64 wieder frei zum Testen 😉

  • 0 Votes
    2 Posts
    890 Views
    FrankMF

    Das Resize-Problem der Partition, nachdem man das System auf einer USB3-HDD installiert hat, ist in

    Welcome to ARMBIAN 5.67.181217 nightly Debian GNU/Linux 9 (stretch) 4.4.167-rockchip64

    gefixt. Eine echte Verbesserung!

  • 0 Votes
    14 Posts
    2k Views
    FrankMF

    Ich habe heute, nachdem es einige Updates von Armbian gab, mal nachgeschaut ob ein spezieller Fehler verschwunden ist.
    Und zwar geht es um das Resizen der Partion nachdem wir Armbian auf eine USB-HDD (USB3) installiert haben.

    Ich setze dafür folgendes System ein.

    Hardware ROCKPro64v2.0 4GB RAM SanDisk 240GB 2,5 Zoll HDD (nix tolles) Software Welcome to ARMBIAN 5.67.181217 nightly Debian GNU/Linux 9 (stretch) 4.4.167-rockchip64

    Was sehe ich nach dem Reboot?

    root@rockpro64:~# df -h Filesystem Size Used Avail Use% Mounted on udev 1.9G 0 1.9G 0% /dev tmpfs 388M 5.3M 383M 2% /run /dev/sda1 220G 1.3G 207G 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 tmpfs 1.9G 4.0K 1.9G 1% /tmp /dev/mmcblk0p1 58G 1.3G 57G 3% /media/mmcboot /dev/zram0 49M 3.0M 43M 7% /var/log tmpfs 388M 0 388M 0% /run/user/0

    Korrekt die Größe angepasst!

    Schnell mal den USB3 testen

    root@rockpro64:~# sudo dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 38.0723 s, 113 MB/s

    Der Adapter

    root@rockpro64:~# lsusb -vvv Bus 004 Device 002: ID 2109:0715 VIA Labs, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x2109 VIA Labs, Inc. idProduct 0x0715 bcdDevice 1.31 iManufacturer 1 VLI Manufacture String iProduct 2 VLI Product String iSerial 3 000000123ADA bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 121 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 224mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 4 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 98 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Command pipe (0x01) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Data-in pipe (0x03) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Data-out pipe (0x04) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 MaxStreams 32 Status pipe (0x02) Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 70 bNumDeviceCaps 4 FIXME: alloc bigger buffer for device capability descriptors Device Status: 0x0000 (Bus Powered)

    Ein lästiger Fehler weniger. 😉