lanefu

Moderators
  • Content Count

    264
  • Joined

  • Last visited


Reputation Activity

  1. Like
    lanefu reacted to Igor in Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party   
    Earlier today I pushed a fairy large patchset containing various functional improvements of many boards.  If you have Allwinner board and some spare time:
     
    1. Build DEV image/kernel with https://github.com/armbian/build (you need to add EXPERT="yes" to the config to unlock)
    2. Install DEV kernel from beta repository (currently in making -> available from November 16th)
     
    Optional Defreeze kernel updates Switch to nightly kernel (armbian-config -> system -> Nightly) Reboot Switch to other kernel (armbian-config -> system -> Other -> DEV)  
    When board came up, do some exploration. Most important information is to find out if there is a regression toward kernel 4.14.y! Then make a test report https://github.com/armbian/testings#how-to-create-a-test-report. 
     
    If you know how to fix certain problems, you are more than welcome! Our resources are tiny and we can't possible fix all problems  
     
    This topic is a place to discuss how certain problems/bugs can be solved.
     
    I will focus on:
     
    Orangepi PC2 http://ix.io/1s2c (hdmi, dvfs) @tkaiser SBCBENCH: http://ix.io/1s5d
    ( @hojnikb available frequency steps: 120 MHz, 240 MHz, 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz, 1.34 GHz, 1.37 GHz) Olinuxino A64 http://ix.io/1s2d (hdmi, dvfs, wireless, usb, battery) SBCBENCH: http://ix.io/1s5e tested battery charging/discharging 
    Orangepi Prime SBCBENCH: http://ix.io/1s5R (once "powered off" during benchmarking at 92C) 
    Orangepi +2e SBCBENCH: http://ix.io/1s5T
    Orangepi Win SBCBENCH: http://ix.io/1s8c
     
    For now.

     
    BTW.
    Do you want to become a (Allwinner) board maintainer? Duties:
    - responsible for content at the download page,
    - running latests updates and managing bug list there.
  2. Like
    lanefu reacted to Igor in Improve 'Support over Forum' situation   
    Forum enachements:
    theme "armbian" updated with upstream version, manual fixes and adjustment with theme designer, fixed recycle bin, updated member map plugin added crowdfunding plugin (this will show supporters automagically) added "show new topic rules" plugin (currently enabled in recycle bin for test) added raffles and giveaway system (will be enabled for users when properly tested) Please report if you find any bugs in the forum theming
  3. Like
    lanefu reacted to lrrr in Orange Pi R1   
    Is there an "official" way to install openwrt to spiflash?  About the only thing I've found for installing to spiflash, is this: https://github.com/hyphop/miZy.
  4. Like
    lanefu reacted to TonyMac32 in Le Potato general topics   
    For the build it yourself crowd, I've aligned our 4.18 patchset with @Neil Armstrong 's collection, which include the video decoder drivers.  I haven't installed the Mali drivers yet, so screen redraw is still painful, but otherwise...
  5. Like
    lanefu reacted to chwe in board support - general discussion / project aims   
    I think the Forum is generally more read than changelog (I don't have stats to back this claim.. ). Our goal is more contribution and better communication. For me the change-log shows decisions already made. A 'Board seeks new maintainer' thread is an announcement. We plan to drop support for *random board/kernel* if you disagree you've to step in cause as soon patches related to it fail we will drop them (e.g. moving them to a EOS sub-folder or delete them) and new images are not longer provided (or images are not longer provided at all? - reduces 'infrastructure coast' keep them in 'seed our torrents' only could be a good idea. Community is responsible to keep them 'online').
     
    I assume at least @TonyMac32, @lanefu and @martinayottes english is better than mine. But for sure, I can have a look.
     
    @Tido the discussion happens in public. Make your list public and I may fill in it there as well..  For me it sounds reasonable to only monitor one thread and Igors PR. As soon as we 'extract' actions out of it they get their dedicated threads (at least the bigger tasks/projects --> e.g. the release naming which happens on github).
     
     
  6. Like
    lanefu reacted to chwe in Initial easy setup proposal   
    An idea which came up during coffee when I read through our documentation (I'll update it partly).. Why not implement an 'unbricker' as well?  
    http://docs.armbian.com/User-Guide_Advanced-Features/#how-to-unbrick-the-system
    e.g. check which one is installed and then give the user the opportunity to choose an older one. 
     
  7. Like
    lanefu reacted to TonyMac32 in board support - general discussion / project aims   
    Just saw this one, honestly just throw away the vendor kernel and roll it into Meson64, it has extremely active upstream support and should soon have vdec support in mainline with Le Potato and K2.  Then we've eliminated a kernel and uncluttered.  The C1 is strangely also getting mainline support, but I have no idea the maturity, someone with one or Bay Libre would need to speak to that.  I don't see too much logic behind throwing it away when it shares 95% of its self with 2 other boards we support (the C2 anyway).
  8. Like
    lanefu reacted to sfx2000 in board support - general discussion / project aims   
    Just to share a thought or two...
     
    Armbian is actually in a special place - and thru community consensus and working with the OEM/Chipset community can do a lot of good work...
     
    Not that much different than what the OpenWRT and FreeElectrons/Bootlin folks have done...
     
    I've read thru the threads - and that really stuck out was @tkasier and the GPIO mess that is... and yes, it's a mess.
     
    (along with uboot and dts, and then solve kernel and related stuff) - anyways, been there, done that.
     
    Armbian has great experience at bringing up boards, doing some tweaks to improve performance/compat as needed...
     
    So it's reach out to the community - the chipset guys, the board folks, work with the community - and there, it's the regular gatherings, and build the brand and set up BOF meetings to get some consensus across the community.
     
    I'm a former member of IETF - and one of the big deals is letting loose of ownership, but keeping a gentle hand on development, and that gains a lot of respect within the larger than armbian team...
     
    Hard to explain, but if the team has already solved hard problems, then those solutions are generally agreed upon, so the collective can move forward.
     
    Getting back to Igor's statement...
     
    Don't tell - rather be open and ask...
     
    Find the community gatherings, work the threads with OEM's and Chipset contacts...
     
     
  9. Like
    lanefu reacted to Igor in board support - general discussion / project aims   
    There was never a formal team. More like a strong common passion and interest to do something valuable, to push things forward, to help, to show how things should look like. IMO it worked very well until the level of self-fulfillment and happines was high enough and a mountain of problems low enough. People perception on this is very colorful and even among inner circle, we have different views. No matter how good and super the project might be. We have more and more users, while most of them waste our time and energy, contribute nothing and ask for more. This is not sustainable.
     
    Armbian might not need major build script or infrastructure development, but both need regular maintenance. We are short already for that. Not hardware, not software but responsibility.
     
    If board support is extending and developing, then this will bring solving harder problems which are not possible to be solved by a few people in their free time. This calls for 20-30x size of the budget size. Where from?

    On the other hand, people expect that "we will solve all the problems they find out". Reality is that our main workforce is basically offline due to overload, mounted problems, life, ... 
     
    We can talk about how to reshape the project, but first, you need someone that will execute what we brained out. 
     
    Personally, I need to look on a project from a distance and leave super (hardware) details behind. It might give me an opportunity to better see the problems we have. 
  10. Like
    lanefu reacted to chwe in board support - general discussion / project aims   
    Background: the last 7 posts came from:
     
    I think those discussions fit better here than elsewere...  Some updates for the table:
     
    not 100% properly updated - feel free to enhance.  
  11. Like
    lanefu reacted to Igor in board support - general discussion / project aims   
    That is already written and it is used ad hoc or if a person bumps into:
    https://docs.armbian.com/Process_Contribute/

    Instead of telling people what to do. Let's ask people if they want to take responsibility as such:
     
    - source code maintainer - adjust kernel configurations, patches, ... help on what we do,
    - project manager: development and testings overview, samples redistribution
    - code cleaner - sweeping our build script code round the clock
    - documentation editor - as a title implies
    - marketing manager - to help communicate project specific services, new features, changes, ...
  12. Like
    lanefu reacted to tkaiser in Quick Review of Rock960 Enterprise Edition AKA Ficus   
    Nope, lazy mode won (thanks to parted and resize2fs now using the eMMC's full capacity, then did do-release-upgrade to upgrade Vamrs' Xenial image to 18.04 LTS, then quickly checked partition 5 whether latest DT changes are present -- they are).  Then I took two SATA SSDs and one NVMe SSD (in Pine's PCIe to M.2 adapter), threw everything in a corner, connected the stuff and fired it up again:
     

     
    The huge fan is there to generate sbc-bench numbers now almost without throttling. Numbers here: http://ix.io/1nVS -- performance (not so) surprisingly identical to all other RK3399 thingies around but DDR3 memory results in slightly lower memory performance (negligible with almost every use case) and of course those RK3399 boards where we allowed 2000/1500 MHz so far show ~5% better CPU performance. The better cpuminer scores compared to RockPro64 with same 4.4. kernel here are just due to testing with Bionic on Ficus (GCC 7.3) vs. Debian Stretch there (GCC 6.3 -- with some tasks simply updating GCC you end up with whopping performance improvements for free)
     
    Not able to test the PCIe SSD since 'rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!' (full dmesg output). I guess there's still some work needed to get DT bits correctly for PCIe? Ok, let's forget about PCIe now (there won't be anything new anyway since PCIe lives inside RK3399 so as long as trace routing on the PCB is ok this RK3399 will perform 100% identical to every other RK3399 thingy out there)
     
    Now let's check USB situation. I'm a bit excited to have a look at the USB3 SATA implementation here since on the PCB itself there's a JMS561 controller (USB3-to-SATA bridge with support for 2 SATA ports, providing some silly RAID functionality but also PM mode. PM --> port multiplier). The two SSDs when connected with the JMS561 in PM mode appear as one device on the USB bus:
    root@rock960:~# lsusb Bus 004 Device 003: ID 1058:0a10 Western Digital Technologies, Inc. Bus 004 Device 002: ID 05e3:0616 Genesys Logic, Inc. hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub 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 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 003: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC Bus 005 Device 002: ID 1a40:0201 Terminus Technology Inc. FE 2.1 7-port Hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@rock960:~# lsusb -t /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/7p, 480M |__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 480M |__ Port 2: Dev 3, If 1, Class=Vendor Specific Class, Driver=ftdi_sio, 480M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M The JMS561 appears as '1058:0a10 Western Digital Technologies, Inc' device which is an indication that the chip runs with WD branded firmware (I'm not that excited). This chipset can be found in a lot of dual drive external USB3 thingies from various drive manufacturers but I thought we would see it here running with original JMicron firmware There's a Genesys Logic USB3 hub on the board connected to RK3399's USB3 host port (the hub appears twice, once with product ID 0616 -- that's SuperSpeed most people call USB3 -- and once with ID 0610 -- that's Hi-Speed or incorrectly called 'USB2') The JMS561 is behind the internal hub We also have a 7-port Terminus Technology USB2 hub on the PCB One FTDI UART adapter is internally connected to this hub (no idea what's that for -- maybe access to the 'MCU' that can be added to the board?) I then used a 4th SSD in a VIA VL716 enclosure (USB-C) connected to the USB-C port just to end up with the same symptoms I already ran into when testing with USB-C on NanoPC-T4 and RockPro64 a while ago. Tons of error messages in the logs (updated dmesg). In the kernel messages the question 'Maybe the USB cable is bad?' appears and I would believe the kernel is right (I have 2 USB-C cables, the good one from Apple somewhere where I don't find it, the el cheapo providing those messages. I need to buy another one) The good news: there is SuperSpeed (USB3) on the USB-C connector and it's not behind the internal USB3 hub (BTW: Schematics for the board are here: https://dl.vamrs.com/products/ficus/docs/hw/). The bad news: all USB receptacles are behind one of the two internal USB hubs.
     
    So let's focus now on the 2 SATA ports provided by the JMS561.
     
    1) Samsung EVO840 connected to one of the SATA ports. Testing methodology exactly identical as outlined here: https://forum.armbian.com/topic/8097-nanopi-m4-performance-and-consumption-review/?do=findComment&comment=61783. Only some minor slowdowns compared to NanoPi M4 (there the JMS567 USB-to-SATA bridge also being behind an internal USB3 hub). In other words: When HDDs are attached this is just fine since then the HDD is the bottleneck but neither the JMS561 nor the USB3 connection:
    random random kB reclen write rewrite read reread read write 102400 4 23192 26619 20636 20727 20633 26177 102400 16 79214 89381 78784 79102 78889 88974 102400 512 292661 295840 271486 277983 277481 300712 102400 1024 321196 322169 305092 312765 312185 329470 102400 16384 356091 356179 350200 360167 359817 357583 2048000 16384 371761 374096 361612 361590 361724 374401  
    2) Another Samsung added to 2nd 'SATA' port (now 2 disks connected to the JMS561). Running two independent iozone tests with 2GB test size at the same time. As expected we now run into 'shared bandwidth' and bus contention issues since both SSD are connected to the same JMS561 that is bottlenecked by the upstream connection to the SoC (one single SuperSpeed line that has to go through the USB3 hub). If we would talk about HDD the below numbers are still excellent since HDD are still the bottleneck with such a '2 disk' setup.
    random random kB reclen write rewrite read reread read write PM851 2048000 16384 131096 132075 161149 162122 161282 131273 EVO840 2048000 16384 151916 157295 176928 183874 186000 178285 3) Now adding another Samsung SSD in an JMS567 enclosure to one of the USB3 receptacles (also behind the hub). As expected 'shared bandwidth' and bus contention issues matter even more now with 3 parallel iozone benchmarks running on each SSD in parallel. But the newly added Samsung EVO750 in an external enclosure finished way earlier:
    random random kB reclen write rewrite read reread read write PM851 2048000 16384 112897 130875 125697 171855 175661 134626 EVO840 2048000 16384 113541 132846 127664 172124 174311 137836 EVO750 2048000 16384 214842 164890 328764 326065 197740 154398 TL;DR: The 2 available SATA ports provided by a JMS561 in PM fashion are totally sufficient when you want to attach one or two HDDs. In case you need highest random IO or sequential IO performance exceeding the USB3 limit (with this 'behind a hub' topology this means ~365 MB/s) then your only choice is the PCIe slot once it works (either by using a PCIe based SSD there or a SATA or even SAS adapter)
     
  13. Like
    lanefu reacted to tkaiser in Quick Review of Rock960 Enterprise Edition AKA Ficus   
    Latest RK3399 arrival in the lab. For now just some q&d photographs:
     



     
    @wtarreau my first 96boards thing so far (just like you I felt the standard being directed towards nowhere given that there's no Ethernet). And guess what: 2 x Ethernet here!
     
    A quick preliminary specifications list:
    RK3399 (performing identical to any other RK3399 thingy out there as long as no throttling happens) 2 GB DDR3 RAM (in April Vamrs said they will provide 1GB, 2GB and 4GB variants for $99, $129 and $149) Board size is the standard 160×120 mm 96Boards EE form factor. EE = Enterprise Edition, for details download 96Boards-EE-Specification.pdf (1.1MB) Full size x16 PCIe slot as per EE specs (of course only x4 usable since RK3399 only provides 4 lanes at Gen2 speed) Board can be powered with 12V through barrel plug, 4-pin ATX plug or via pin header (Vamrs sent a 12V/4A PSU with the board) Serial console available via Micro USB (there's an onboard FTDI chip) 2 SATA ports + 2 SATA power ports (5V/12V). SATA is provided by a JMS561 USB3 SATA bridge that can operate in some silly RAID modes or PM mode (with spinning rust this chip is totally sufficient -- for SSDs better use NVMe/PCIe) Socketed eMMC and mechanical SD card adapter available (Vamrs sent also a SanDisk 8GB eMMC module as can be seen on the pictures) SIM card slot on the lower PCB side to be combined with an USB based WWAN modem in the mPCIe slot (USB2 only) 1 x SD card slot routed to RK3399, 1 x SD card slot for the BMC (Baseboard Management Controller) Gigabit Ethernet and separate Fast Ethernet port for the BMC Ampak AP6354 (dual-band and dual-antenna WiFi + BT 4.1) USB-C port with USB3 SuperSpeed and DisplayPort available eDP and HDMI 2.0 USB2 on pin headers and 2 type A receptacles all behind an internal USB2 hub USB3 on one pin header and 2 type A receptacles all behind an internal USB3 hub 96boards Low Speed Expansion connector with various interfaces exposed 96boards High Speed Expansion connector with various interfaces exposed (e.g. the 2nd USB2 host port, see diagram below) S/PDIF audio out 'real' on/off switch to cut power. To really power on the board the translucent button next to it needs to be pressed  

  14. Like
    lanefu got a reaction from TonyMac32 in board support - general discussion / project aims   
    My 4x4 v8 truck doesnt have giant tires.....but oem is pretty big so... true statement


    'Merica.

    Sent from my SM-G950U using Tapatalk

  15. Like
    lanefu reacted to Igor in board support - general discussion / project aims   
    Yes. Now we have many patches that are either our origin or changed from the 3rd party. We ("only") need to define a protocol ... like we need a better/more polished protocol for testing.
     

    We have resources for something but not for all. We also need to create or find resources for the current state of the project. Without doing anything extra! I don't know what will be possible to do and when from a current perspective. Let's keep things on the list even we might not solve them. This is nothing new.
     
     
    At least this is not exactly urgent. A default branch can be 1st pushed under EXPERT/unsupported but not removed. Yet.
     
     
    Current update logic is as follows. When its time for the update, when nightly builds run fine ... we test images and push out a 1st stable images (we could call them RC). The update follows after a while (few weeks) when second test force - users installing a system from new images, which should at least boot up to 99% - report those few remaining issues. This was the core idea in a last major update and there was actually an extremely low reported failures. I am actually very happy, but the price was higher than I am willing to accept. If this is once per year, ok, but if we start pushing out updates more often, this is not sustainable.
     
     
     
    If just a few people are aware of problems while the rest have no idea how hard is to make things happen, they will continue to push on us with full force (until we break down). We need to communicate properly that support is as is and there is nobody here waiting for users complains. Sometimes we solve things promptly, sometimes we file them for the future, some are ignored. More later ... life is calling.
  16. Like
    lanefu reacted to TonyMac32 in Daily (tech related) news diet   
    https://lkml.org/lkml/2018/9/23/212
  17. Like
    lanefu reacted to tkaiser in sbc-bench   
    Relevant swapping occurred. Still no idea why so I added monitoring of virtual memory settings few hours ago. I'll look into this within the next months but no high priority since there is detailed monitoring in sbc-bench we know exactly why numbers differ currently between Orange Pi One Plus (1 GB) and PineH64 (more than 1 GB).
  18. Like
    lanefu reacted to sfx2000 in zram vs swap   
    Apologies up front - after digging thru the forums, you have a fair investment in your methods and means...  fair enough, and much appreciated.
     
    Just ask that you keep an open mind on this item - I've got other things to worry about...
     
    current tasks are rk3288 clocks and temps, and an ask to look at rk_cypto performance overall...
     
    Keep it simple there... many use cases to consider - one can always find a benchmark to prove a case...
     
    I've been there, and this isn't the first ARM platform I've worked with - I've done BSP's for imx6, mvedbu, broadcom, and QCA... not my first rodeo here.
     
    Just trying to help.
  19. Like
    lanefu reacted to tkaiser in NanoPi M4 performance and consumption review   
    Really looking forward to this HAT
     
    BTW: I've not the slightest idea how much efforts and initial development costs are needed for such a HAT. But in case the Marvell based 4-port SATA solution will be somewhat expensive maybe designing another one with an ASMedia ASM1062 (PCIe x2 and 2 x SATA) and just one Molex for 2 drives might be an idea. Could be one design made for NEO4 that will work on M4 too with a larger (or dual-purpose) HAT PCB?
  20. Like
    lanefu reacted to mindee in NanoPi M4 performance and consumption review   
    Thanks for your suggestion, we made a SATA HAT prototype for NanoPi M4, it can connect  with 4x 3.5inch hard drive and work well.
     
     
  21. Like
    lanefu got a reaction from Werner in Orange pi one plus - 1800 MHz   
    Just built debs and upgraded my kernel.. seems to work
     
    SBC bench http://ix.io/1nje
     
    w/ cheap ceramic heatsink  (and a little bit of forced ambiant air)
    ########################################################################## 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs LE) LE CPU Freq: 1791 1792 1789 1792 1791 1791 1790 1791 1792 RAM size: 994 MB, # CPU hardware threads: 4 RAM usage: 882 MB, # Benchmark threads: 4 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 2710 340 776 2637 | 76925 398 1648 6563 23: 2665 349 779 2716 | 75245 398 1634 6511 24: 2623 360 784 2821 | 73176 398 1615 6424 25: 1276 197 741 1457 | 69984 398 1567 6228 ---------------------------------- | ------------------------------ Avr: 311 770 2408 | 398 1616 6431 Tot: 355 1193 4420  
  22. Like
    lanefu reacted to dmeey in Fault in logrotate functionality?   
    I have already adressed this issue with a little demonstrations script in this thread:
     
    however, nobody answered yet.
  23. Like
    lanefu reacted to dmeey in logrotate - rotating of /var/log.hdd is problematic   
    First time armbian user and poster here. Since this is not the right time and place for an introduction, lets keep it with a simple "Hi all!" and get straight to the topic:
     
    for completeness, my system:
    BOARD=orangepizeroplus BOARD_NAME="Orange Pi Zero Plus" BOARDFAMILY=sun50iw2 VERSION=5.59 LINUXFAMILY=sunxi64 BRANCH=next ARCH=arm64 IMAGE_TYPE=testing BOARD_TYPE=conf INITRD_ARCH=arm64 KERNEL_IMAGE_TYPE=Image logging, in particular logrotate with ram-logging
    As far as I understand:
    - Three different cron files are responsible to handle ram-logging and logrotate
    -- /etc/cron.daily/logrotate
    -- /etc/cron.daily/armbian-ram-logging
    -- /etc/cron.d/armbian-truncate-logs
    - The configuration files for logrotate follow an agreement, that rotation is performed on the "cold" log files in log.hdd
     
    Now while armbian-truncate-logs seems to do the right thing(i.e. truncating the "hot" log files in /var/log after rotation),  I have an impression that the consequences of a regular call to logrotate(as found in /etc/cron.daily/logrotate) have not been thought through. Since the hot log is not truncated in this case, it's contents get synced back by the next call to armbian-ram-logging.
     
    I have created a minimal working example to demonstrate my point:
    armbian-logrotate-test
    #!/bin/bash LOGROTATE_CONF=armbian-logrotate-test.conf LOGFILE=armbian-logrotate-test.log counter=0 # fn log_logline () { echo "logline ${counter}" >> /var/log/${LOGFILE} counter=$((counter+1)) } log_rotate () { chown root.root ${LOGROTATE_CONF} /usr/sbin/logrotate --force ${LOGROTATE_CONF} } log_ramlog () { /usr/lib/armbian/armbian-ramlog write >/dev/null 2>&1 } log_cleanup () { rm -f /var/log/${LOGFILE}* rm -f /var/log.hdd/${LOGFILE}* } log_status () { echo "### /var/log.hdd ###" find /var/log.hdd -type f -name "${LOGFILE}*" -exec echo {} \; -exec cat {} \; echo "### /var/log ###" find /var/log -type f -name "${LOGFILE}*" -exec echo {} \; -exec cat {} \; } # main log_cleanup # - logging scenario log_logline log_logline log_ramlog log_rotate log_logline log_logline log_ramlog log_rotate log_logline log_logline # - output log_status log_cleanup with
    armbian-logrotate-test.conf
    /var/log.hdd/armbian-logrotate-test.log { rotate 10 daily missingok notifempty } after calling the script as root the following output is obtained:
    ### /var/log.hdd ### /var/log.hdd/armbian-logrotate-test.log.1 logline 0 logline 1 logline 2 logline 3 /var/log.hdd/armbian-logrotate-test.log.2 logline 0 logline 1 ### /var/log ### /var/log/armbian-logrotate-test.log logline 0 logline 1 logline 2 logline 3 logline 4 logline 5  
    Has this been overlooked or do I miss something out in my test scenario?
  24. Like
    lanefu reacted to Lion Wang in Banana PI BPI-W2   
    When I'm in a bad mood, I'm glad to see your posts, because you're like my wife, always chattering, but I can't say no   hope you can help us to development BPI-W2
  25. Like
    lanefu reacted to tom_i in lvcreate doesn't work - solved   
    @lanefu - thx man, swithching to nightly solve that problem