Jump to content

aprayoga

Members
  • Posts

    138
  • Joined

  • Last visited

Reputation Activity

  1. Like
    aprayoga reacted to lalaw in DAS Mode and Capture One   
    Bunch of random questions:
     
    1. Any ETA on when DAS mode would be rolled into kernel 5.x?  
    2. Any ideas on how I can get around the 1 post per day limitation?
     
    If I can take the liberty, I'd like to describe my setup and solicit suggestions.  
     
    I have am running Capture1 on a Mac connected via USB-C.  I'd love to use the Helios64 as a r/w DAS for the Capture1, while still making it available (perhaps ro) to enable network access and backup.
     
    Some issues that I foresee:
    1. Because the DAS mode is using the Mass Storage Gadget, it seems like my choices are to expose the entire disk/block device or to have a file that simulates the block devices.  The problem with the file is that it would no longer appears as a filesystem in NAS mode, correct?
    2. If my assumption in (1) is true, then I have to expose the entire disk.  For the Mac to read the disk, I assume I need to use exFat or Fat32 (as ext4, ZFS, etc. support on Mac sound spotty for r/w)
    3. exFat/Fat32 don't appear to be first class citizens in the world of OMV, but it sounds like I can cobble together support and mount those disks manually
    4. Once sorted out, would it be possible to combine the Capture1 disk with other NAS-dedicated disks in a SnapRaid group for redundancy?  And expose the Capture1 disk as a (r/o) share on the NAS?
     
    My hope is that I can have Capture1 see as a local DAS for work, I can get some level of disk failure redundancy though period SnapRaid parity syncs, and I can create some sort of rsync job to maintain an offsite backup in case I have a bigger failure.
  2. Like
    aprayoga reacted to tikey in M.2 SSD "Crucial MX500 1TB CT1000MX500SSD4" not detected   
    I got the Helios64 and was running it from an external SD card so far since when I first installed it, the other options where not available, yet. I'm running openmediavault 5.5 (Armbian 20.11.6 Buster with Linux 5.9.14-rockchip64). Now, I wanted to move the system to a SSD and installed a "Crucial MX500 1TB CT1000MX500SSD4" according to https://wiki.kobol.io/helios64/m2/ Unfortunately, the SSD is not detected by the system, see output of dmesg below. For ata1, it only shows SATA link down.
     
    Is there anything I can do to figure out what the problem is? Or is there any reason why this particular SSD would not work?
     
    ~$ dmesg | grep ata [ 0.000000] Memory: 3740032K/4061184K available (14464K kernel code, 2094K rwdata, 5980K rodata, 4224K init, 573K bss, 190080K reserved, 131072K cma-reserved) [ 0.016073] CPU features: detected: ARM errata 1165522, 1319367, or 1530923 [ 1.394468] libata version 3.00 loaded. [ 3.019011] dwmmc_rockchip fe320000.mmc: DW MMC controller at irq 28,32 bit host data width,256 deep fifo [ 3.315946] ata1: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010100 irq 240 [ 3.315955] ata2: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010180 irq 241 [ 3.315964] ata3: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010200 irq 242 [ 3.315972] ata4: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010280 irq 243 [ 3.315979] ata5: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010300 irq 244 [ 3.628407] ata1: SATA link down (SStatus 0 SControl 300) [ 13.625910] ata2: softreset failed (1st FIS failed) [ 14.101801] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 14.121464] ata2.00: ATA-10: ST4000VN008-2DR166, SC60, max UDMA/133 [ 14.121475] ata2.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 32), AA [ 14.123003] ata2.00: configured for UDMA/133 [ 14.601788] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 14.615989] ata3.00: ATA-10: ST4000VN008-2DR166, SC60, max UDMA/133 [ 14.616001] ata3.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 32), AA [ 14.617535] ata3.00: configured for UDMA/133 [ 15.093805] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 15.113279] ata4.00: ATA-10: ST4000VN008-2DR166, SC60, max UDMA/133 [ 15.113290] ata4.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 32), AA [ 15.114802] ata4.00: configured for UDMA/133 [ 15.428239] ata5: SATA link down (SStatus 0 SControl 300) [ 17.307715] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null) [ 21.469500] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl  
  3. Like
    aprayoga got a reaction from GeckoX in Helios 4 doesn't switch on anymore   
    You can check the PSU by measuring the output voltage.
     
    You can check the motherboard by following instruction on the older support thread. You can also find our recommendation for replacement PSU
     
     
  4. Like
    aprayoga got a reaction from gprovost in Recovery: (too) short delay between UMS and Maskrom modes   
    As we have mentioned on the wiki, you can watch the System LED as visual cue. When it blink once, release the button.
    There are roughly 2 second delay to release the button.
    https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-rockchip64-mainline/general-support-recovery-button.patch#L131-L137
     
    Another visual cue you can check is through serial console.
    U-Boot 2020.07-armbian (Nov 23 2020 - 16:22:15 +0100) SoC: Rockchip rk3399 Reset cause: POR DRAM: 3.9 GiB PMIC: RK808 SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB MMC: mmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Model: Helios64 Revision: 1.2 - 4GB non ECC using mmc0 device for download mode rockchip_dnl_mode = ums mode as soon as you see rockchip_dnl_mode = ums mode, release the button.
  5. Like
    aprayoga reacted to Remus in Unable to connect helios64 to router   
    Hi there,
     
    So I'm having a problem connecting the helios to the router. I try different lan cables and different ports. It was working everything fine yesterday, I did a reboot and no more connection. I'm completely new to this. I was installing home assistance and plex before this happened but I believe I didn't mess with anything to do with network. Don't know what I might have done. I can connect to helios via putty and after logging in the part where ip should be there is none. Any advise would be most appreciated. Again I'm completely new to this.
  6. Like
    aprayoga reacted to Schroedingers Cat in Armbian 20.11.1 Focal Freezes?   
    I'm using Armbian 20.11.1 Focal (5.9.11-rockchip64) on my Helios64. When there's heavier load via ethernet (SFTP to a SATA Ultrastar 12TB disk) for something like more than an hour, the entire system will freeze. Not sure if it actually does freeze but I lose all SSH connections and cannot connect anymore via SSH unless I restart the Helios64. Happened today 4 times and it's totally reproducible. Haven't tested another drive yet.
     
    What makes this difficult to debug is that under /var/log/syslog or kern.log or faillog nothing relevant is being written as to in what state the device is.
     
    Is this a known issue?
    How can I find out what the problem is?
  7. Like
    aprayoga got a reaction from RussianNeuroMancer in USB C to display   
    @0utc45t, try legacy image. if it still not working, make sure your cable has converter chip inside.
    There are at least 2 standards regarding display signal in USB Type-C. one is DisplayPort Alternate Mode, which is the one supported on Helios64 (RK3399) and the other one is HDMI Alt mode.
    If you have cable that use HDMI Alt mode, it won't work on Helios64.
     
    @RussianNeuroMancer,
    yes. on legacy, HDMI+Hub combo working fine. The problem with mainline driver, it does not support OTG. You have to define the port as "host" or "peripheral" in device tree.
    That PR comment, before i knew https://github.com/armbian/build/pull/2299
    HDMI+hub combo working fine in LK5.9 if you also enable rockchip-dwc3-0-host overlay.
  8. Like
    aprayoga reacted to Chris Bognar in Script to check the power status, and shutdown if battery is low!   
    If anyone is interested, I've created a shell script that can be run with cron to check A/C and battery status, and do a graceful shutdown when a battery threshold is met.  It also logs power outages, battery drain when off A/C, and when it posts a shutdown (if any).  This is a simple script, nothing fancy, but works for me.  It has a granularity of one minute (cron is limited to one minute intervals), but I've been able to keep the system up on heavy load for 4-5 minutes before the script generates a shutdown on low battery.
     
    The script is generous -- it waits for 916mV or less before a shut-down.  This value was provided by the KOBOL team on their Wiki as the recommended shutdown threshold for the battery, but can be changed via the script.  You can comment out any file-logging lines, or change the file location, also from within the script.  I've heavily commented it, should be pretty easy to follow.
     
    Copy the script below into a file named whatever you choose, place it where you want to run it, and cron it to get it going.  It should only create disk writes when the power is out or when shutting down from battery drain on no A/C (a few lines once per minute), and will create no disk writes  if you comment out the logging.
     
     
    Let me know how it works for you, if you use it.  I've been testing it for the past couple of days, and it's worked as intended.  I'm always open to code tips, and I'm still learning, so any advice is appreciated.
  9. Like
    aprayoga reacted to NotAnExpert in Missing RAID array after power loss   
    Thanks!
     
    Ran the commands, the non-forced assembly failed but the forced fixed the issue. I have been checking files and folders and have not found anything wrong yet.
     
    Appreciate your help and detailed instructions!
     
    mdadm --stop /dev/md0
    mdadm: stopped /dev/md0
     
     
    mdadm /dev/md0 --assemble /dev/sd[abcde]
    mdadm: /dev/md0 assembled from 2 drives - not enough to start the array
     
     
    mdadm /dev/md0 --assemble --force /dev/sd[abcde]
    mdadm: forcing event count in /dev/sdb(1) from 26341 upto 26352
    mdadm: forcing event count in /dev/sdd(3) from 26341 upto 26352
    mdadm: forcing event count in /dev/sde(4) from 26341 upto 26352
    mdadm: clearing FAULTY flag for device 3 in /dev/md0 for /dev/sdd
    mdadm: clearing FAULTY flag for device 4 in /dev/md0 for /dev/sde
    mdadm: Marking array /dev/md0 as 'clean'
    mdadm: /dev/md0 has been started with 5 drives.
     
    cat /proc/mdstat
    Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
    md0 : active (auto-read-only) raid6 sda[0] sde[4] sdd[3] sdc[2] sdb[1]
          35156259840 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/5] [UUUUU]
          bitmap: 0/88 pages [0KB], 65536KB chunk
     
    unused devices: <none>
     
    mdadm -D /dev/md0
    /dev/md0:
               Version : 1.2
         Creation Time : Thu Nov  5 22:00:27 2020
            Raid Level : raid6
            Array Size : 35156259840 (33527.62 GiB 36000.01 GB)
         Used Dev Size : 11718753280 (11175.87 GiB 12000.00 GB)
          Raid Devices : 5
         Total Devices : 5
           Persistence : Superblock is persistent
     
         Intent Bitmap : Internal
     
           Update Time : Thu Nov 26 07:13:29 2020
                 State : clean
        Active Devices : 5
       Working Devices : 5
        Failed Devices : 0
         Spare Devices : 0
     
                Layout : left-symmetric
            Chunk Size : 512K
     
    Consistency Policy : bitmap
     
                  Name : helios64:0  (local to host helios64)
                  UUID : f2188013:e3cdc6dd:c8a55f0d:d0e9c602
                Events : 26352
     
        Number   Major   Minor   RaidDevice State
           0       8        0        0      active sync   /dev/sda
           1       8       16        1      active sync   /dev/sdb
           2       8       32        2      active sync   /dev/sdc
           3       8       48        3      active sync   /dev/sdd
           4       8       64        4      active sync   /dev/sde
     
    =============================================================
     
    After running commands I went back to OMV web UI and raid was listed with clean state.
     
    Under filesystem I selected the raid6 “data” and mounted it.
     
    Added shares to Samba and all data is accessible.
     
  10. Like
    aprayoga reacted to Mangix in XOR on Helios 4   
    Is it me or it the mv_xor driver being loaded late?
     
    ```
    [    0.007976] xor: measuring software checksum speed
    [    0.164062] xor: using function: arm4regs (2534.000 MB/sec)
    [    0.316068] raid6: neonx8   xor()  1096 MB/s
    [    0.452063] raid6: neonx4   xor()  1378 MB/s
    [    0.588069] raid6: neonx2   xor()  1610 MB/s
    [    0.724066] raid6: neonx1   xor()  1346 MB/s
    [    0.860075] raid6: int32x8  xor()   328 MB/s
    [    0.996072] raid6: int32x4  xor()   369 MB/s
    [    1.132082] raid6: int32x2  xor()   332 MB/s
    [    1.268063] raid6: int32x1  xor()   285 MB/s
    [    1.268067] raid6: .... xor() 1610 MB/s, rmw enabled
    [    1.665163] mv_xor f1060800.xor: Marvell shared XOR driver
    [    1.694139] mv_xor f1060800.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr )
    [    1.694257] mv_xor f1060900.xor: Marvell shared XOR driver
    [    1.722115] mv_xor f1060900.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr )
    ```
     
    I see that /proc/interrupts shows no action despite me using RAID5.
     
    edit: from looking at kernel source, it seems btrfs uses xor_blocks instead of async_tx. The former seems software only.
  11. Like
    aprayoga reacted to djurny in Helios64 USB-C serial console   
    Hi all,
    Something to share for those who use the USB-C serial console from another Linux host. Install and use 'tio' to connect to the serial console instead of minicom. This supports both 1500k baud and also can be easily used inside GNU screen (minicom gets a meta key conflict per default; CTRL-A is default meta key for both GNU screen and minicom). Minicom resulted in regular errors posted in syslog by the ftdi_sio kernel module. Did not run any strace to find out what syscall is causing it, but in short, tio appears to not treat the tty as a modem: no errors are popping up in syslog. Hopefully the serial consoles will remain up now.
    One caveat: I did not find a way to send a BREAK over serial using tio. This is something that is handy in case kernel freezes up, as sometimes you will still have opportunity to do a magic sysrq triggered reboot (BREAK + b = initiate a reboot of the kernel, also see magic sysrq & REISUB).
     
    Groetjes,
     
  12. Like
    aprayoga reacted to SSL in fan spinning   
    My bad, a Cable was Preventing the fan from spinning, this topic could be closed!
  13. Like
    aprayoga reacted to barnumbirr in 1 ssd + 5 hdd   
    From the wiki:
    Source: https://wiki.kobol.io/helios64/sata/#sata-controller-diagram
  14. Like
    aprayoga got a reaction from gprovost in 2.5G Ethernet crash (r8152)   
    @FloBaoti you can get 2.14 source from https://github.com/wget/realtek-r8152-linux
    and compile using docker similar like in this thread
  15. Like
    aprayoga reacted to Igor in 2.5G Ethernet crash (r8152)   
    I also updated our sources https://github.com/igorpecovnik/realtek-r8152-linux
  16. Like
    aprayoga reacted to mortomanos in Reboot not working properly with OMV   
    One success discovered today: Using a windows machine with FTDI drivers and Putty brings console output, I can now explore further when there are reboots that do not bring the system up.
  17. Like
    aprayoga reacted to FloBaoti in 2.5G Ethernet crash (r8152)   
    Hi,
    I run Armbian Buster 20.11.1 and today, without any important network traffic, eth1 interface has crashed.
    Here is dmesg :
     
     
     
    After ifdown & ifup eth1, interface is up again.
     
    What's wrong ? I can see driver 2.13 is used, and Realtek has issued a 2.14 version, but only usable up to 5.6 kernel So I can't compile it.
     
  18. Like
    aprayoga got a reaction from Zageron in Armbian 20.11 on Helios64.... Feedback?   
    @Zageron run
    echo ledtrig-netdev | sudo tee -a /etc/modules add the modules into auto load list.
     
    apparently /etc/modules is not modified during upgrade.
  19. Like
    aprayoga reacted to BacchusIX in OMV Issues   
    I've been trying to get OMV setup on the Helios prior to adding my hard drives and I keep getting errors and communication failures when I try to do pretty much anything. I like OMV for it's GUI, but honestly, I've never been a fan of it functionally. Is there anything comparable to it that works with the Helios64? Anyone have any suggestions how to fix it?
     
    I have logs but I don't see a place to attach them.
     
     
     
  20. Like
    aprayoga reacted to Lago in ft230x and fan spins   
    I need help with two items. 
    1.  When directly connect to my windows 10 pro pc i get the following in device manager.  ft230x.  Where can I download the drivers so i can use putty to connect to the helios64.
    2.  One of the fans is always spinning even when i shutdown with sudo shutdown -t now. 
     
    Thanks
     
     
  21. Like
    aprayoga got a reaction from gprovost in USB-C DAS (Is it or is it NOT supported?)   
    @slymanjojo to use DAS on LK 5.9, you would need to configure the USB-C as device mode.
     
    In your helios64, create a file dwc3-0-device.dts contains following code
    /dts-v1/; /plugin/; / { compatible = "rockchip,rk3399"; fragment@0 { target = <&usbdrd_dwc3_0>; __overlay__ { dr_mode = "peripheral"; }; }; }; add and enable to user overlay
    sudo armbian-add-overlay dwc3-0-device.dts and reboot
     
    Now, you can follow instruction on our wiki to enable DAS. If you are using Windows, you might need to unplug and replug the usb cable after enabling the DAS mode. 
    ---
    If you want to use USB-C in Host mode, you need to remove folloing line from /boot/armbianEnv.txt
    user_overlays=dwc3-0-device and enable host mode overlay on armbian-config > System > Hardware and tick dwc3-0-host
  22. Like
    aprayoga reacted to m11k in HOWTO: btrfs root filesystem   
    Hi,
     
    I wanted to convert my root filesystem to btrfs.  This allows me to use snapper to take regular snapshops.  I also use btrbk to send my snapshots to my secondary storage (also a btrfs array).  My root filesystems is installed to eMMC, but there isn't any reason you couldn't do this with an sd card.  These instructions are done with a laptop running Linux.  I'm using Debian in this case, although any distro with a recent kernel and btrfs tools installed should work.
     
    CAVEATS:
    The current u-boot image (2020.08.21) doesn't support booting natively to btrfs.  u-boot *does* support btrfs though.  Hopefully a future build of u-boot will add btrfs support.  To work around this, we have to create an ext4 /boot partition, and then a btrfs root partition.
     
    1. To start, I booted the helios64 via sd card to the USB mass storage image (https://wiki.kobol.io/helios64/install/emmc/).  I then connected a laptop to the helios64 via the USB-C cable, and the emmc appeared as /dev/sdb.  The rest of these instructions will assume the eMMC is /dev/sdb, so please adjust accordingly for your system.
     
    2. Mount the eMMC root filesystem on the host:
    # mkdir /mnt/nasrootext4 # mount /dev/sdb1 -o ro /mnt/nasrootext4  
    3. Back up the contents of the root filesystem:
    # tar -C /mnt/nasrootext4 --acls --xattrs -cf root_backup.tar .  
    4. Make a backup of the partition layout (in case you decide to revert this modification):
    # fdisk -l /dev/sdb | tee nas_fdisk.txt  
    5. Unmount the filesystem, and run fdisk on it.  Make note of the start sector.  It should be 32768.
    # umount /dev/sdb1 # fdisk /dev/sdb Command (m for help): p Disk /dev/sdb: 14.6 GiB, 15634268160 bytes, 30535680 sectors Disk model: UMS disk 0 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: 0x794023b5 Device Boot Start End Sectors Size Id Type /dev/sdb1 32768 30230303 30197536 14.4G 83 Linux  
    6. Delete the existing partition ('d')
    7. Create a new partition ('n')
    8. Select 'primary' partition type
    9. Select partition number 1
    10. Select first sector: 32768 (This is very important to get right, and should match the start sector of the partition that was just deleted)
    11. Select last sector: +512M (this create a 512MB /boot partition)
    12. You will see a message "Partition #1 contains a ext4 signature.".  This is okay.  I selected 'n' (don't remove signature) but it doesn't matter.  You should probably remove the signature since we're going to create a new ext4 filesystem anyway.
    13. Create new partition ('n')
    14. Select 'primary' partition type
    15. Select partition number 2
    16. First sector: 1081344 (this is one more than the end sector of the other partition)
    17. Last sector: (leave the default as the full drive, 30535679 in my case)
    18. Print the layout to confirm:
    Disk /dev/sdb: 14.6 GiB, 15634268160 bytes, 30535680 sectors Disk model: UMS disk 0 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: 0x794023b5 Device Boot Start End Sectors Size Id Type /dev/sdb1 32768 1081343 1048576 512M 83 Linux /dev/sdb2 1081344 30535679 29454336 14G 83 Linux  
    19. Write the partition table to disk and exit ('w')
    20. Create a new ext4 filesystem on the first partition: 'mkfs.ext4 /dev/sdb1' (you may need to add -F if it complains about an existing ext4 signature)
    21. Create a new btrfs filesystem on the second partition: 'mkfs.btrfs /dev/sdb2'
    22. Mount the new root filesystem:
    # mkdir /mnt/nasrootbtrfs # sudo mount -o compress=zstd /dev/sdb2 /mnt/nasrootbtrfs  
    23. Make some initial subvolumes (note that '@' will be the root subvolume, as this is preferred by 'snapper'):
    # cd /mnt/nasrootbtrfs # btrfs subvol create @ # btrfs subvol create @home # btrfs subvol create @var_log  
    24. Mount the boot partition, and the @home and @var_log subvolumes
    # cd @ # mkdir boot # mount /dev/sdb1 boot/ # mkdir home # mount /dev/sdb2 -o noatime,compress=zstd,subvol=/@home home # mkdir -p var/log # mount /dev/sdb2 -o noatime,compress=zstd,subvol=/@var_log var/log # mount | grep sdb /dev/sdb2 on /mnt/nasrootbtrfs type btrfs (rw,relatime,compress=zstd,space_cache,subvolid=5,subvol=/) /dev/sdb1 on /mnt/nasrootbtrfs/@/boot type ext4 (rw,relatime) /dev/sdb2 on /mnt/nasrootbtrfs/@/home type btrfs (rw,noatime,compress=zstd,space_cache,subvolid=258,subvol=/@home) /dev/sdb2 on /mnt/nasrootbtrfs/@/var/log type btrfs (rw,noatime,compress=zstd,space_cache,subvolid=260,subvol=/@var_log)  
    25. Note that our current directory is '/mnt/nasrootbtrfs/@'
    26. Untar the old root filesystem into the new root directory.  Since boot, home, and var/log are mounted, tar will extract the relevant data into these mounted filesystems.
    # tar -xvf /root/helios64_root.tar --acls --xattrs --numeric-owner |@ tee /root/extract_log.txt This is the only spot where things did not go as expected.  I received a handful of errors about "No space left on device" while untarring.  These seem to be transient btrfs errors. I use btrfs pretty extensively at work, and I've seen cases in the past on older kernels where btrfs would falsely report ENOSPC when the filesystem was under heavy load.  I'm not sure if that is what is happening here, but I would guess it's a bug.  It could be a bug in the kernel on my laptop, or it could be a bug in the usb-c mass storage export on the helios64.  To recover from this, I ran the tar command a couple of times.  I continued to receive these errors on different files.  I did this three or four times.  I also tried removing --acls and --xattrs, but it didn't seem to make much of a difference.  On my last attempt to untar, all of the files that failed happened to be from usr/lib/python3, so I untarred just that directory: 'tar -xvf /root/helios64_root.tar --numeric-owner ./usr/lib/python3'.  That extracted without error.  I was satisfied that everything made it back on disk.  Perhaps if you only extracted one top-level directory at a time, it would not produce any errors.  Maybe there is some way to slow down the 'tar' to avoid these ENOSPC errors.
     
    27. After extracting the root filesystem, I made a snapshot of it: 'btrfs subvol snap -r . root_post_copy'
    28. Update /mnt/nasrootbtrfs/@/etc/fstab.  This was my old fstab:
    Old version: UUID=dabb3dbf-8631-4051-a032-c0b97eb285bd / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 tmpfs /tmp tmpfs defaults,nosuid 0 0 # >>> [openmediavault] /dev/disk/by-label/helios64_btrfs_raid1 /srv/dev-disk-by-label-helios64_btrfs_raid1 btrfs defaults,nofail,noatime,nodiratime,compress=zstd 0 2 # <<< [openmediavault]  
    Look up the new UUID for /dev/sdb2.  I did this by running 'ls -l /dev/disk/by-uuid').  Updated /etc/fstab:
    UUID=240bab7d-1b6c-48f4-898d-ba12abcecb3f / btrfs defaults,noatime,compress=zstd,ssd,subvol=@ 0 0 UUID=240bab7d-1b6c-48f4-898d-ba12abcecb3f /home btrfs defaults,noatime,compress=zstd,ssd,subvol=@home 0 0 UUID=240bab7d-1b6c-48f4-898d-ba12abcecb3f /var/log/ btrfs defaults,noatime,compress=zstd,ssd,subvol=@var_log 0 0 UUID=fd5b620c-57e2-4031-b56c-3c64ce7c7d5f /boot ext4 defaults,noatime 0 2 tmpfs /tmp tmpfs defaults,nosuid 0 0 # >>> [openmediavault] /dev/disk/by-label/helios64_btrfs_raid1 /srv/dev-disk-by-label-helios64_btrfs_raid1 btrfs defaults,nofail,noatime,nodiratime,compress=zstd 0 2 # <<< [openmediavault]  
    29. Modify /mnt/nasrootbtrfs/@/boot/armbianEnv.txt.  In particular modify rootdev, rootfstype, and add 'extraargs'.  Old version:
    verbosity=1 bootlogo=false overlay_prefix=rockchip rootdev=UUID=dabb3dbf-8631-4051-a032-c0b97eb285bd rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u  
    New version:
    verbosity=1 bootlogo=false overlay_prefix=rockchip rootdev=UUID=240bab7d-1b6c-48f4-898d-ba12abcecb3f rootfstype=btrfs usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u extraargs=rootflags=subvol=@  
    30. Make a 'boot' symlink.  I'm not sure if this is necessary, but u-boot expects the boot files to be in the '/boot' directory on the root filesystem, but they are now in the root directory of the boot partition.  This symlink makes sure that if u-boot tries to access /boot/foo, it will actually access /foo.
    # cd /mnt/nasrootbtrfs/@/boot # ln -s . boot  
    31.  Unmount everything:
    # umount /mnt/nasrootbtrfs/@/var/log # umount /mnt/nasrootbtrfs/@/home # umount /mnt/nasrootbtrfs/@/boot # umount /mnt/nasrootbtrfs/  
    32. Power off helios64
    33. Remove sd card
    34. Start picocom on your laptop ('picocom -b 1500000 /dev/ttyUSB0')
    35. Turn on helios 64 and look for startup.
     
    TROUBLESHOOTING:
    Of course this did not work on the first attempt for me.  After rebooting the helios64, it never successfully booted into Linux.  I didn't see any errors from u-boot.  To troubleshoot, I wrote the original helios64 debian buster image to sd card and booted the helios64 to that.  I mounted /dev/mmcblk1p1 to /mnt, and changed the 'verbosity' to 7 in armbianEnv.txt.  I eventually discovered that I had the UUID wrong in /boot/armbianEnv.txt.  Correcting that value fixed the issue, and the helios64 booted successfully from eMMC.
     
    SETTING UP AUTOMATED SNAPSHOTS AND BACKUPS:
    Enabling 'snapper' for automated root snapshots was very easy:
    1. sudo apt install snapper
    2. sudo snapper -c root create-config /
     
    The debian snapper automatically take snapshots before and after apt upgrades.  However since /boot is a separate filesystem, this is not included in these snapshots.  As a workaround, I added an apt hook which rsyncs /boot to /.bootbackup before the snapshots are made.  Note that the 'snapper' hook is /etc/apt/apt.conf.d/80snapper, so I created /etc/apt/apt.conf.d/79-snapper-boot-backup:
    # /etc/apt/apt.conf.d/79-snapper-boot-backup DPkg::Pre-Invoke { "if mountpoint -q /boot && [ -e /.bootbackup ] ; then rsync -a --delete /boot /.bootbackup || true ; fi"; }; DPkg::Post-Invoke { "if mountpoint -q /boot && [ -e /.bootbackup ] ; then rsync -a --delete /boot /.bootbackup || true ; fi"; };  
    This takes care of automated snapshots.  I still want snapshots stored on another drive (or another system) for redundancy.  I'm using 'btrbk' to do this.  btrbk wants the btrfs top-level subvolume mounted somewhere.  To do so, I created the directory /mnt/btr_pool, and added the following line to /etc/fstab:
    UUID=240bab7d-1b6c-48f4-898d-ba12abcecb3f /mnt/btr_pool/ btrfs defaults,noatime,compress=zstd,ssd,subvolid=5 0 0  
    My spinning drive array on the helios64 is a btrfs filesystem, and I have it mounted on /srv/dev-disk-by-label-helios64_btrfs_raid1.  I created a '/srv/.../backups/helios64/btrfs/volumes' directory.  I then created the following three files:
     
    /srv/dev-disk-by-label-helios64_btrfs_raid1/backups/helios64/btrfs/btrbk.conf:
    timestamp_format long volume /mnt/btr_pool snapshot_dir btrbk snapshot_preserve 30d snapshot_preserve_min latest target_preserve 7d 8w 6m target_preserve_min latest target send-receive /srv/dev-disk-by-label-helios64_btrfs_raid1/backups/helios64/btrfs/volumes subvolume @ subvolume @home subvolume @var_log  
    /srv/dev-disk-by-label-helios64_btrfs_raid1/backups/helios64/btrfs/rsync_boot.sh:
    #!/bin/sh set -e -x mountpoint /boot [ -e /.bootbackup ] rsync -a --delete /boot /.bootbackup  
    /srv/dev-disk-by-label-helios64_btrfs_raid1/backups/helios64/btrfs/run.sh
    #!/bin/bash set -e -x CDIR=$( dirname ${BASH_SOURCE[0]} ) ${CDIR}/rsync_boot.sh btrbk -c ${CDIR}/btrbk.conf run  
    I then added a daily cron job which runs the 'run.sh' script.
     
    Well, that was a longer post than I had imagined.  I hope someone finds it helpful.
  23. Like
    aprayoga reacted to akschu in Stability issues on 20.08.21   
    Did more testing over the weekend on 5.9.9.  I was able to benchmark with FIO on top of a ZFS dataset for hours with the load average hitting 10+ while scrubing the datastore.  No issues.  Right nowt he uptime is 3 days. 
     
    I'm actually a little surprised at the performance.  It's very decent for what it is. 
     
    I wonder if the fact that I'm running ZFS and 5.9.9 while others are using mdadm and 5.8 is the difference.  I'm not really planning on going backwards on either.  If 5.9.9 works then no need to build another kernel, and you would have to pry ZFS out of my cold dead hands.  I've spend enough of my life layering encryption/compression on top of partitions on top of volume management on top of partitions on top of disks.  ZFS is just better, and having performance penalty free snapshops that I can replicate to other hosts over SSH is the icing on the cake. 
     
  24. Like
    aprayoga reacted to SIGSEGV in iSCSI on Helios64 [Working great on Armbian 20.11 test images]   
    For anyone looking to build an iSCSI target on their new Helios64, I can confirm that it's working correctly under the test builds for Armbian 20.11.
    Thanks to @aprayoga for his comment on the pull request, the kernels modules related to LinuxIO have been added to all boards in the Armbian project.
     

  25. Like
    aprayoga reacted to ShadowDance in Disk power management & sleep settings?   
    @privilegejunkie what specific model? My guess is that the answer is no, though. That's a relatively old article and the WD utility mentioned there only applies to old Red drives that are 4TB and below. For WD drives that support IDLE3, you can try to use idle3ctl (apt install idle3-tools) to manage their idle setting. I've turned idle3 off on all my drives because they're usually idle for, at most 5 minutes leading to constant sleep/wake.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines