pfeerick

Moderators
  • Content Count

    145
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Everything posted by pfeerick

  1. Just a quick question due to having just updated and rebooted my Cubietruck.... I was running 5.38 mainline Stretch, but I see that armbian-firmware 5.45 was installed over 5.38... so shouldn't the welcome screen now be saying "Welcome to ARMBIAN 5.45" instead of "Welcome to ARMBIAN 5.38" still? Or is that package not the one that determines the Armbian 'version'? Maybe a better question would be what would update /etc/armbian-release ? The update process was otherwise smooth and doesn't seem to have rise to any nasty surprises . I also look forward to trying out the pineH64 image since I see that has just made a big jump, as well as the new pinebook image. Keep up the great work!
  2. How about creating/editing /etc/rc.local and running script from there? i.e. Something like #!/bin/bash python <name of script> & exit 0 Make sure that /etc/rc.local is executable (sudo chmod +x /etc/rc.local) and it'll be picked up and run when you reboot.
  3. @Jason Fisher er... not sure why you commented about ZFS as that has nothing to do with this thread... have you replied to the wrong thread?
  4. @AnythingIsFine Ouch! That sounds like me with the raspberry pi... when the recent 'disabled by default' behavior of the SSH... scratching my head to work out why the SSH wasn't working, and I'd firstly forgotten to make the enable file, then made a typo in the filename... At least it's working now! Hm. so the artful images... interesting... will have to poke around and see why it changed. Be handy to port that back to other images. If the artful images are using the kernel that supports it, it could be signifying disk activity...
  5. If you subsequently mounted and unmounted the partition, a sync shouldn't have been needed, as you introduced enough time for the buffers to be written to disk, and the unmount shouldn't release the drive until everything has been written to disk. I don't know what's happening on your side with the verification, since at least version 0.9 Etcher has done a verify/validate on a write after the write phase on both Linux and Windows, but it was very subtle... the progress bar would just run through a second time but would state it was verifying instead of writing. In a update (1.4.2 or 1.4.4?) that was pushed a couple weeks ago, the verify progress bar is a different colour now, making it more visible. If you're using a serial console cable with the rock64, it would be a good idea to disconnect it (from the computer), powerup the rock64, and reconnect it, as sometimes the power feeding in from the serial console cable via either the TX or RX pin is enough to leave the rock64 in a non-booting state. Other than that, if Ether is verifying the image, it sounds like the image writing to eMMC is fine, so I don't know what else is going on. If you want to get really bored, you can watch these two screen record caps of me writing the current rock64 Ambian xenial image to the eMMC and then booting it... firstly using Etcher and then secondly using dd. Note with the dd capture I ran into the intermittent issue where the rock64 will not boot properly if there is a serial console cable connected at power on- it gets some residual power via the serial console cable and doesn't reset the CPU properly. Side-note: Can you link to a image that does this 'led' flashing... I've been using the Xenial images (initially the minimal images, but now container ones) of ayufan's images since he started producing them and hadn't noticed any of them flash the either of the LEDs OOTB, other than ones that flash the SPI Flash memory chip. I seem to remember the Android ones doing that though.
  6. The format of your command in /etc/fstab looks fine. Did you make sure that the /home/orangepi/ramdisk directory exists for mounting? You could have done a 'sudo mount /home/orangepi/ramdisk' after making the changes to /etc/fstab, and hopefully got a reaonsable error message then, instead of at boot time. And just a quick FYI, this isn't the OrangePi support forum! :-P
  7. When you did the dd, did you do a sync afterwards to ensure the image had completely finished writing to the sd card? pfeerick@ASUS-H55D:~$ sudo dd if=~/Armbian/Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img of=/dev/sdf status=progress bs=1M 832569344 bytes (833 MB, 794 MiB) copied, 3.00251 s, 277 MB/s 1052+0 records in 1052+0 records out 1103101952 bytes (1.1 GB, 1.0 GiB) copied, 3.97628 s, 277 MB/s pfeerick@ASUS-H55D:~$ time sync real 0m11.902s user 0m0.000s sys 0m0.028s As can be seen above, I needed to wait 12 seconds after dd had finished before I could safely remove the microSD card. (Edit: Just to remove any confusion, I loaded Armbian on a microSD this time to show the timing and that a sync is needed with dd. I previously loaded and booted a 16GB FORESEE eMMC using the pine64 eMMC to USB adapter.) Armbian does not need a separate /boot partition, as the version of uboot it ships with supports ext4, hence they were able to get rid of that extra partition. pfeerick@ASUS-H55D:~$ sudo fdisk -l /dev/sdf Disk /dev/sdf: 15 GiB, 16118710272 bytes, 31481856 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: 0x91a1b523 Device Boot Start End Sectors Size Id Type /dev/sdf1 32768 2154495 2121728 1G 83 Linux pfeerick@ASUS-H55D:~$ fdisk -l Armbian/Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img Disk Armbian/Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img: 1 GiB, 1103101952 bytes, 2154496 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: 0x91a1b523 Device Boot Start End Sectors Size Id Type Armbian/Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img1 32768 2154495 2121728 1G 83 Linux Why does running Fedora Workstation mean that Etcher skips the verification/validation after writing? Are you running an older version, or have it turned off in the options? Etcher can read a xz compressed image (e.g. xenial-containers-rock64-0.6.27-196-arm64.img.xz) natively, without any need to extract the image from it. It cannot do the same for yet, although it has been discussed on their issue tracker as a possibility.
  8. You can most certainly just flash Armbian to the eMMC instead of to microSD and using nand-sata-install... I just tried it with the 5.42 xenial build of Armbian and it worked just fine. https://pastebin.com/qvNad516 1) Download 7z file containing image from Armbian website 2) Extract .img file from 7z archive (i.e. Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img at time of writing) 3) Write .img file with Etcher using USB eMMC adapter 4) Once verified (man that eMMC verifies fast on USB3!!), clip eMMC onto rock64 and apply power It's possible what was tripping you up is that ayufan's images are xz compressed, and Etcher can read then natively. It can't read the 7z archives natively, so you have to help it and extract the disk image from the archive before writing it.
  9. I see two things... one minor cosmetic, the other bloody annoying! Firstly the bloody annoying 'feature'... And then the minor cosmetic detail... probably a legacy of the multi-reaction thingy... you mouse over the heart, that grey slider starts trying to pop out... On Chrome, Windows 10.
  10. Oh my, nice work! Actually booting into linux and not promptly bursting in flames... That in itself is an noteworthy milestone! Not sure of performance, but the processor is running very cool on 'idle' . barely warm to touch. No frequency or thermals yet, so it'll be interesting to see what is really going on. I don't think it was able to shut down properly on a 'sudo poweroff'... need the plug in a console cable to see what happened there. Addendum: Got the serial console working on the EXP header @ 115200 baud. It does 'power off' / "Starting Power-Off... [ 2557.657434] reboot: Power down", but continues to draw a health 0.8W or 170mA (basically the same as when it's idling, and leaves the green LED near the headphones jack lit. A forcible power off by pressing and holding the power button for ~8 seconds results in a drop to 0.18W or 32ma. Serial logs for Debian (first boot) and Ubuntu (rebooted). It looks like I booted the same build as Igor... Bionic... as I'm more partial to Ubuntu than Debian. My armbianmonitor dump is here, vanilla pineH64, nothing plugged in except for power and GbE via a switch : http://ix.io/18UC Edit re Debian: For the sake of completeness, I also booted the Debian build, and it's armbianmonitor log is http://ix.io/18V7 I can also report zero activity from the USB3 port. It is being powered, but there is no response/kernel messages when a device is plugged in, USB3, 2 or otherwise. On the other hand, this was the output from plugging something into the USB2 ports... Seems to be working fine (can see and mount drives) just the dwc3 error. == Lower USB Port == [Apr28 04:48] usb 3-1: new high-speed USB device number 2 using ehci-platform [ +0.160142] usb-storage 3-1:1.0: USB Mass Storage device detected [ +0.012355] scsi host0: usb-storage 3-1:1.0 [ +0.005677] dwc3 5200000.dwc3: failed to initialize core [ +1.007158] scsi 0:0:0:0: Direct-Access Generic STORAGE DEVICE 1532 PQ: 0 ANSI: 6 [ +0.004774] dwc3 5200000.dwc3: failed to initialize core [ +0.367311] sd 0:0:0:0: [sda] 31116288 512-byte logical blocks: (15.9 GB/14.8 GiB) [ +0.000978] sd 0:0:0:0: [sda] Write Protect is off [ +0.000008] sd 0:0:0:0: [sda] Mode Sense: 21 00 00 00 [ +0.001013] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ +0.012624] sda: sda1 [ +0.003756] sd 0:0:0:0: [sda] Attached SCSI removable disk == Disconnect and Upper USB Port == [Apr28 04:49] usb 3-1: USB disconnect, device number 2 [ +2.625559] usb 1-1: new high-speed USB device number 2 using ehci-platform [ +0.160284] usb-storage 1-1:1.0: USB Mass Storage device detected [ +0.005631] scsi host0: usb-storage 1-1:1.0 [ +0.003775] dwc3 5200000.dwc3: failed to initialize core [ +1.027671] scsi 0:0:0:0: Direct-Access Generic STORAGE DEVICE 1532 PQ: 0 ANSI: 6 [ +0.002970] dwc3 5200000.dwc3: failed to initialize core [ +0.367868] sd 0:0:0:0: [sda] 31116288 512-byte logical blocks: (15.9 GB/14.8 GiB) [ +0.001101] sd 0:0:0:0: [sda] Write Protect is off [ +0.000008] sd 0:0:0:0: [sda] Mode Sense: 21 00 00 00 [ +0.000993] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ +0.010520] sda: sda1 [ +0.003916] sd 0:0:0:0: [sda] Attached SCSI removable disk Edit re Debian: The Debian image from the didn't have the dwc3 errors when plugging into the USB2 ports... [Apr28 08:28] usb 3-1: new high-speed USB device number 2 using ehci-platform [ +0.159409] usb 3-1: New USB device found, idVendor=05e3, idProduct=0749, bcdDevice=15.32 [ +0.000009] usb 3-1: New USB device strings: Mfr=3, Product=4, SerialNumber=2 [ +0.000005] usb 3-1: Product: USB3.0 Card Reader [ +0.000005] usb 3-1: Manufacturer: Generic [ +0.000005] usb 3-1: SerialNumber: 000000001532 [ +0.000938] usb-storage 3-1:1.0: USB Mass Storage device detected [ +0.000994] scsi host0: usb-storage 3-1:1.0 [ +0.175901] usbcore: registered new interface driver uas [ +0.844075] scsi 0:0:0:0: Direct-Access Generic STORAGE DEVICE 1532 PQ: 0 ANSI: 6 [ +0.000708] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ +0.370255] sd 0:0:0:0: [sda] 31116288 512-byte logical blocks: (15.9 GB/14.8 GiB) [ +0.000981] sd 0:0:0:0: [sda] Write Protect is off [ +0.000007] sd 0:0:0:0: [sda] Mode Sense: 21 00 00 00 [ +0.000994] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ +0.008896] sda: sda1 [ +0.004247] sd 0:0:0:0: [sda] Attached SCSI removable disk Just tried the "Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter" (from the pine64 store) for the first time, and it seems to have been just a plug an play affair even in this early stage... quick run of nmtui and it was up and running. == Plugging in USB Wifo, bottom USB2 port == [Apr28 05:01] usb 3-1: new high-speed USB device number 5 using ehci-platform [ +0.161519] dwc3 5200000.dwc3: failed to initialize core [ +0.256283] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ +0.007980] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ +0.002099] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ +0.000014] cfg80211: failed to load regulatory.db [ +1.350222] usb 3-1: USB disconnect, device number 5 [ +0.000496] usbcore: registered new interface driver 8812au [ +0.421349] usb 3-1: new high-speed USB device number 6 using ehci-platform [ +0.463789] dwc3 5200000.dwc3: failed to initialize core [ +0.117435] 8812au 3-1:1.0 wlx08107aff527a: renamed from wlan0 [ +0.089667] IPv6: ADDRCONF(NETDEV_UP): wlx08107aff527a: link is not ready [ +0.576959] IPv6: ADDRCONF(NETDEV_UP): wlx08107aff527a: link is not ready [ +0.000041] IPv6: ADDRCONF(NETDEV_CHANGE): wlx08107aff527a: link becomes ready [ +0.142635] IPv6: ADDRCONF(NETDEV_UP): wlx08107aff527a: link is not ready [Apr28 05:02] IPv6: ADDRCONF(NETDEV_CHANGE): wlx08107aff527a: link becomes ready == ip addr == 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 86:99:5f:3e:0e:2d brd ff:ff:ff:ff:ff:ff inet 192.168.0.122/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0 valid_lft 84343sec preferred_lft 84343sec inet6 fe80::8eb6:99f:513a:2d7/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: wlx08107aff527a: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 08:10:7a:ff:52:7a brd ff:ff:ff:ff:ff:ff inet 192.168.0.123/24 brd 192.168.0.255 scope global dynamic noprefixroute wlx08107aff527a valid_lft 85820sec preferred_lft 85820sec inet6 fe80::ff65:b46c:ed97:2d32/64 scope link noprefixroute valid_lft forever preferred_lft forever == lsusb == Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 006: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  11. Don't know if it is of any interest, but since it's tinymembench and a rock64, here goes :-P. Running the ayufan-xential-linux-0.7.x image with docker and stuff in the background. Compiled tinymembench with default parameters. rock64 v2 board w/ 4GB memory. No HDMI plugged in, headless box. rock64@rock64:~/tinymembench$ uname -a Linux rock64 4.4.114-rockchip-ayufan-193 #1 SMP Sun Mar 4 20:24:21 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux rock64@rock64:~/tinymembench$ sudo cat /sys/kernel/debug/clk/clk_summary |grep clk_ddr clk_ddrmon 0 0 24000000 0 0 pclk_ddr 3 3 98304000 0 0 pclk_ddr_grf 1 1 98304000 0 0 pclk_ddrstdby 0 0 98304000 0 0 pclk_ddr_mon 1 1 98304000 0 0 pclk_ddr_msch 1 1 98304000 0 0 pclk_ddrupctl 0 0 98304000 0 0 pclk_ddrphy 1 1 75000000 0 0 sclk_ddrc 2 2 786000000 0 0 aclk_ddrupctl 0 0 786000000 0 0 clk_ddrupctl 1 1 786000000 0 0 clk_ddrmsch 1 1 786000000 0 0 rock64@rock64:~/tinymembench$ ./tinymembench tinymembench v0.4.9 (simple benchmark for memory throughput and latency) ========================================================================== == Memory bandwidth tests == == == == Note 1: 1MB = 1000000 bytes == == Note 2: Results for 'copy' tests show how many bytes can be == == copied per second (adding together read and writen == == bytes would have provided twice higher numbers) == == Note 3: 2-pass copy means that we are using a small temporary buffer == == to first fetch data into it, and only then write it to the == == destination (source -> L1 cache, L1 cache -> destination) == == Note 4: If sample standard deviation exceeds 0.1%, it is shown in == == brackets == ========================================================================== C copy backwards : 1438.1 MB/s (1.9%) C copy backwards (32 byte blocks) : 1449.3 MB/s (3.1%) C copy backwards (64 byte blocks) : 1354.0 MB/s (0.3%) C copy : 1360.7 MB/s (1.5%) C copy prefetched (32 bytes step) : 1280.4 MB/s C copy prefetched (64 bytes step) : 1447.5 MB/s (2.6%) C 2-pass copy : 1645.8 MB/s (2.5%) C 2-pass copy prefetched (32 bytes step) : 1214.7 MB/s C 2-pass copy prefetched (64 bytes step) : 1165.4 MB/s C fill : 5678.7 MB/s C fill (shuffle within 16 byte blocks) : 5681.5 MB/s (3.1%) C fill (shuffle within 32 byte blocks) : 5681.5 MB/s C fill (shuffle within 64 byte blocks) : 5685.2 MB/s (3.0%) --- standard memcpy : 1330.4 MB/s standard memset : 5680.6 MB/s (3.0%) --- NEON LDP/STP copy : 1530.9 MB/s NEON LDP/STP copy pldl2strm (32 bytes step) : 1261.7 MB/s (2.8%) NEON LDP/STP copy pldl2strm (64 bytes step) : 1466.2 MB/s NEON LDP/STP copy pldl1keep (32 bytes step) : 1668.5 MB/s NEON LDP/STP copy pldl1keep (64 bytes step) : 1674.7 MB/s (2.9%) NEON LD1/ST1 copy : 1511.5 MB/s NEON STP fill : 5681.3 MB/s NEON STNP fill : 2242.6 MB/s (1.9%) ARM LDP/STP copy : 1531.0 MB/s ARM STP fill : 5681.9 MB/s (2.8%) ARM STNP fill : 2251.2 MB/s (2.3%) ========================================================================== == Framebuffer read tests. == == == == Many ARM devices use a part of the system memory as the framebuffer, == == typically mapped as uncached but with write-combining enabled. == == Writes to such framebuffers are quite fast, but reads are much == == slower and very sensitive to the alignment and the selection of == == CPU instructions which are used for accessing memory. == == == == Many x86 systems allocate the framebuffer in the GPU memory, == == accessible for the CPU via a relatively slow PCI-E bus. Moreover, == == PCI-E is asymmetric and handles reads a lot worse than writes. == == == == If uncached framebuffer reads are reasonably fast (at least 100 MB/s == == or preferably >300 MB/s), then using the shadow framebuffer layer == == is not necessary in Xorg DDX drivers, resulting in a nice overall == == performance improvement. For example, the xf86-video-fbturbo DDX == == uses this trick. == ========================================================================== NEON LDP/STP copy (from framebuffer) : 305.5 MB/s NEON LDP/STP 2-pass copy (from framebuffer) : 288.1 MB/s NEON LD1/ST1 copy (from framebuffer) : 80.3 MB/s NEON LD1/ST1 2-pass copy (from framebuffer) : 79.2 MB/s ARM LDP/STP copy (from framebuffer) : 157.3 MB/s (2.0%) ARM LDP/STP 2-pass copy (from framebuffer) : 152.5 MB/s (1.9%) ========================================================================== == Memory latency test == == == == Average time is measured for random memory accesses in the buffers == == of different sizes. The larger is the buffer, the more significant == == are relative contributions of TLB, L1/L2 cache misses and SDRAM == == accesses. For extremely large buffer sizes we are expecting to see == == page table walk with several requests to SDRAM for almost every == == memory access (though 64MiB is not nearly large enough to experience == == this effect to its fullest). == == == == Note 1: All the numbers are representing extra time, which needs to == == be added to L1 cache latency. The cycle timings for L1 cache == == latency can be usually found in the processor documentation. == == Note 2: Dual random read means that we are simultaneously performing == == two independent memory accesses at a time. In the case if == == the memory subsystem can't handle multiple outstanding == == requests, dual random read has the same timings as two == == single reads performed one after another. == ========================================================================== block size : single random read / dual random read 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.0 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.0 ns 16384 : 0.0 ns / 0.0 ns 32768 : 0.1 ns / 0.1 ns 65536 : 5.3 ns / 9.0 ns 131072 : 8.2 ns / 12.5 ns 262144 : 11.5 ns / 16.9 ns 524288 : 67.3 ns / 106.0 ns 1048576 : 101.9 ns / 143.6 ns 2097152 : 120.3 ns / 159.0 ns 4194304 : 133.9 ns / 171.1 ns 8388608 : 142.0 ns / 178.2 ns 16777216 : 147.6 ns / 183.7 ns 33554432 : 152.0 ns / 188.1 ns 67108864 : 168.1 ns / 215.8 ns
  12. Right, why did you post to this topic while I had it open? I think I need to go check my network security now! Anyway, indeed... if this is node red and MQTT running, there is nothing to stop an ESP8266 with screen... say a 1.3" OLED or a 2.2" TFT, etc, from also polling the orange pi / etc and showing the data.
  13. Yup, that's what it says at the bottom of the login banner...
  14. I can't give any board specific advice, as I don't have an Orange Pi Win, so I can't help much sorry. Can I just confirm this was with the " Ubuntu server – legacy kernel" from the downloads page? And that ubuntu server was one of the previous ones you'd used, not the debian stretch nightly? And *exactly* what is the behaviour? Type in '1234', press enter, and it freezes? Type in '1234', press enter, type in new password first time, press enter, type in the new password the second time, press enter, and it freezes... some variation of that? I remember that happening something similar happening to me before, but it was because entering the new password wrong (or was it the old one wrong) didn't give an error and just kicked the ssh session.
  15. The most likely response will be a link to this page ... oh, wait, I just did that! But it will most likely be to fork the code base if you haven't done so already and submit a clearly documented pull request, and the discussion will roll on from there.
  16. It's somewhere in the region of 1.5G when installing (Ubuntu Server, that is). Haven't run the server install on PC for while, but I would have thought it would partition the device at the start, so it should just be a matter of USB booting an install image and installing the sucker. Why is Lubuntu taking up so much space now? It's only supposed to need 3Gb, with a recommended 6Gb for some free space? Are you using Lubuntu images from http://lubuntu.me/downloads/, so that you're only getting the required bits?
  17. Login/welcome messages come from the scripts in /etc/update-motd.d, so you can remove/change them as you wish. If you didn't want the sysinfo, tips,update nofications and armbian-config messages, you can just remove the executable bit (i.e. chmod -x) from the four scripts responsible for those messages (30-sysinfo 35-tips 40-updates 41-armbian-config), and then you'd be left with just the board name. You can also turn that off by disabling the 10-header script. You can also make your own, and have them run and display on login (if properly written and the executable bit is set). The easiest way to run something before login is to use crontab. i.e. run crontab -e, and then add a new @reboot command for a script that will run after the device has rebooted, and before login. See this page for some more information and examples.
  18. Both of these behaviours are to be expected. I've not been following pine64/rock64 development for the last 2/3 months, but I looked at the changelog the other day, and I see in the release notes for ayufan's rock64 builds "0.6.0: Highly experimental", so it's probably a known thing that it will break. You'd have to go onto the forum or IRC to find out more. The thing to realise is that it is still marked a pre-release build, and unless their development structure has changed in the last few months, 'pre-release' (in GitHub parlance) is considered testing' 'latest' (in GitHub parlance) is considered beta, and the images available from the pine64 website are the more tested 'stable' versions. The update scripts included with those builds will always default to the 'latest', but you can specify the version you want to update to if you want to force the issue. To see which one it will update to automatically, just go to the latest release tag on GitHub -> https://github.com/ayufan-rock64/linux-build/releases/latest
  19. @Joe_PS PuTTY is a piece of software that you use to connect to a remote computer, and access a terminal prompt (or a desktop GUI using X11 forwarding). You can use a serial connection (the simplest and most direct), and then later SSH over a network once the device is setup if you wish. You'll basically have a terminal/console prompt, and will be controlling the device as if you had a monitor and keyboard hooked up to it. So yes, you'll be able to type in 'armbian-config' and then use the keyboard to navigate the menus and install OMV via the software packages section.
  20. I'll bite... it'll give me a chance to have a ferret around in armbian-config It shouldn't be hard thanks to the config stuff Gord_W' found.
  21. New homepage UX looks fine, once the carousel is replaced with a newsfeed (or even the armbian twitter?) of some sort... as someone mentioned... New WiP board, x board depreciated for x reason, new beta in the works... I agree about the consistency of the links... make sure the big buttons are in the same order as the links in the menu. For the download page, list view looks great. Server/Desktop may become more apparent once options are seen. Else there would need to be an explanatory note at the top that Server images are mean for setups where a monitor is not connected, and Desktop images are... that sort of thing. If you wanted to introduce faster torrent / slower HTTP concept, why not just put links in smaller print underneath "HTTP link (slow), Torrent link (fast)". Experienced people will know to click the icon for the torrent, big text for HTTP, others will be guided by the smaller links. re: forum logo... if the guideline from the w3c is that the logo on sub-site should link to the main site, then that is just plain stupid. I am on the forum.armbian.com domain... when I click the logo, it should to forum.armbian.com... not some other site (armbian.com). The pine64 forum does the same, and that is just annoying. If you want a link to the main site, it belongs in the menu bar. With a suitable template, Wordpress should do just fine... it a CMS after all! Tutorials... will a hybrid approach work? Tutorials written/managed under WordPress/main site, so they remain 'clean' and 'to the point' (i.e. more wiki style) , and a link on the forum to the tutorial when it is published, and a link in the tutorial to the forum page for discussion and questions? Or does that sound too convoluted? Now @chwe What's wrong with talking about the need for a 'stable' release branch in this thread... doesn't that come under 'redesign'? :-P :-D :-D And I've also been guilty of the Mali misunderstand too.... trying to apply the old PC graphics card understanding to SoCs, when they threw that idea out the window! :-O And hey, it's great we're discussing this stuff, as between all of us this might take a bit longer, but there is some mutual ownership of what's going on, and some great ideas are coming out!
  22. Confirmed on my Orange Pi Zero w/ 5.36/legacy. After some digging, the extra [ ! -z "${SocTemp##*[!0-9]*}" ] on https://github.com/armbian/build/blob/master/packages/bsp/common/usr/bin/armbianmonitor#L346 that Igor added to make Soc readings more resilient with badly behaved kernels is the culprit. I've added an issue for it, and some explanation as to what broke.
  23. Did the /etc/cron.d/armbian-updates permission issue get fixed (I'm guessing not... I just updated to 5.36 whilst I was writing this and it's back)? I was getting the insecure mode journal entries also on a just updated from 5.31 -> 5.35. Orange Pi Zero. Dec 04 12:02:01 orangepizero-1 cron[521]: (*system*armbian-updates) INSECURE MODE (group/other writable) (/etc/cron.d/armbian-updates) Dec 04 12:03:01 orangepizero-1 cron[521]: (*system*armbian-updates) INSECURE MODE (group/other writable) (/etc/cron.d/armbian-updates) As with the earlier report, the permissions for /etc/cron.d/armbian-updates were: -rw-rw-r-- 1 root root 83 Nov 21 21:14 armbian-updates And sudo chmod 644 /etc/cron.d/armbian-updates shut it up. Dec 04 12:04:01 orangepizero-1 cron[521]: (*system*armbian-updates) RELOAD (/etc/cron.d/armbian-updates) Until then, unsurprisingly, the update count on the welcome banner was stuck at: [ 0 security updates available, 41 updates total: apt upgrade ] Last check: 2017-12-03 00:00 even though the system had just been updated and rebooted, and only actually had 1 update waiting. btw, 5.36 still has a 'user-built' kernel :-P
  24. There are just too many people who still don't read instructions (hey, stop lookin' at me!) so the only option is to break if they didn't read the 3 foot tall flaming print saying "BUILD SYSTEM REQUIREMENTS" and "if you don't have this system, use a virtual machine setup, like the vagrant one we provide for you". If they still want to disregard the instructions, they'll have to edit the build script themselves.
  25. I've been away from my rock/pine/orangepi stuff for a while whilst life, the end the uni term, and complaining against the latest political brainwave of our government... but time is clearing up again, and I can start following the forums and documentation and stuff. My 2 cents is I agree with the general view expressed by @tkaiser... I don't like deleting stuff unless it is duplicated, with a polite note to the OP to bring their attention to the forum rules. What I would do in the case of those who have not done their due diligence and are asking for support, or who are not doing what is asked, is to either just put on the broken record approach, or to simply ignore them. And I agree with the general idea of the FAQs... but that also sounds a bit like the getting started documentation... so I'm not sure that is actually needed.... other than a bloody big arrow pointing at the documentation page... so that even a blind person couldn't miss it! :-P