Jump to content

gprovost

Members
  • Posts

    580
  • Joined

  • Last visited

Reputation Activity

  1. Like
    gprovost reacted to TRS-80 in Armbian v20.11.y Bugfix release(s)   
    I think there are probably only 2 subforums you might need to monitor:
    Announcements
    Armbian build framework Both are very low volume.  You could set up an RSS feed (link at bottom of page) or simply peruse them whenever you log in.
  2. Like
    gprovost reacted to Julien Michel in Just received, installed but no HDD 1   
    After installing the hardware and software, my hdd 1 is inactive. I swapped my disk 1 and 5, 1 is still inactive. I checked my connections in the box but I don't see any problems. Could this be due to a software error?
  3. Like
    gprovost reacted to obynio in Unable to boot Helios64 after update to 5.9.14-rockchip64   
    Hello,
     
    I recently updated my Helios64 board from 5.9.11 to 5.9.14 using `apt upgrade` and since then I'm unable to boot my board which is stuck on `Starting kernel ...`. Here is the log of the what got upgraded.
     
     
    I tried to reinstall the latest release to eMMC through u-boot (`Armbian_20.11.3_Helios64_buster_current_5.9.14.img` and also tried `Armbian_20.11_Helios64_buster_current_5.8.17.img`) but I still get the same message `Starting kernel ...`. 
    I also tried to boot from SD card by using the jumper P10 but I'm still stuck to `Starting kernel ...`.
    I also tried to install it using Maskrom Mode. Everything runs correctly but still stuck on the `Starting kernel ...`.
     
    ~/a/rkbin-master ❯❯❯ lsusb -d 2207:330c Bus 002 Device 014: ID 2207:330c Fuzhou Rockchip Electronics Company RK3399 in Mask ROM mode ~/a/rkbin-master ❯❯❯ sudo tools/rkdeveloptool db rk3399_loader_v1.24_RevNocRL.126.bin Downloading bootloader succeeded. ~/a/rkbin-master ❯❯❯ sudo tools/rkdeveloptool wl 0 ../Armbian_20.11_Helios64_buster_current_5.8.17.img Write LBA from file (100%) ~/a/rkbin-master ❯❯❯ sudo tools/rkdeveloptool rd Reset Device OK.  
    Here is the log when I boot my board.
     
     
    I tried everything I found in the wiki but without any success, and I'm running out of ideas. Do you have an idea why the kernel is not booting ?
     
    Regards,
  4. Like
    gprovost reacted to Niglix in Can't access OMV after first install   
    I followed in detail the installation tutorial but I'm stuck at the installation of OMV. I can't access after the installation using the ip address or the generic link helios.local. 
    I did try to reinstall the configuration. To go through a boot on the Micro SD...
    I don't know if there would be a command line to verify that OMV is installed? Or another way to install it?
  5. Like
    gprovost reacted to grek in Can't access OMV after first install   
    to install OMV You should login via SSH to your helios then:
     
    root@helios64:~# armbian-config
    root@helios64:~# armbian-config Software -> Softy -> OMV  
    You can verify if it installed:
     
    root@helios64:~# dpkg -l |grep openmediavault ii openmediavault 5.5.17-3 all openmediavault - The open network attached storage solution ii openmediavault-fail2ban 5.0.5 all OpenMediaVault Fail2ban plugin ii openmediavault-flashmemory 5.0.7 all folder2ram plugin for OpenMediaVault ii openmediavault-keyring 1.0 all GnuPG archive keys of the OpenMediaVault archive ii openmediavault-luksencryption 5.0.2 all OpenMediaVault LUKS encryption plugin ii openmediavault-omvextrasorg 5.4.2 all OMV-Extras.org Package Repositories for OpenMediaVault ii openmediavault-zfs 5.0.5 arm64 OpenMediaVault plugin for ZFS root@helios64:~#  
  6. Like
    gprovost got a reaction from Werner in Armbian v20.11.y Bugfix release(s)   
    Helios64 LAN2 is completely disable thanks to the following commit : https://github.com/armbian/build/commit/6bb68d7ff787614bf0798b2d3fad9883144a9c2d
    The mainline kernel r8153 driver doesn't support the vendor ID and product ID used in Helios64, so the interface is completely disable, it's not just losing 2.5Gb speed :-(
     
    We didn't see at all this commit, and personally I wasn't aware of the publication of 20.11.3 release, because most probably I'm not following the right thread. Can someone point me out what thread I'm supposed to follow before a new minor release is being pushed ?
  7. Like
    gprovost got a reaction from lanefu in Armbian v20.11.y Bugfix release(s)   
    Helios64 LAN2 is completely disable thanks to the following commit : https://github.com/armbian/build/commit/6bb68d7ff787614bf0798b2d3fad9883144a9c2d
    The mainline kernel r8153 driver doesn't support the vendor ID and product ID used in Helios64, so the interface is completely disable, it's not just losing 2.5Gb speed :-(
     
    We didn't see at all this commit, and personally I wasn't aware of the publication of 20.11.3 release, because most probably I'm not following the right thread. Can someone point me out what thread I'm supposed to follow before a new minor release is being pushed ?
  8. Like
    gprovost reacted to Ammonia in Only HDD 1 & 2 power up   
    I ordered a replacement MOSFET (same model), including a drop-in replacement from vishay with better power ratings (just in case it should happen again). Unfortunately shipping is taking longer than it should. I temporarily bypassed the MOSFET to get all the hard drives to boot up so I could transfer the more important data. I was hoping fixing it would be faster than receiving a replacement board - and for me dealing with UPS is playing Russian roulette. Fixing it by replacing a 13-14 cent component is the better option for us both. Hopefully I won't ruin the board in the process!
  9. Like
    gprovost reacted to EduardCH in filesystem for raid5   
    Thanks for reply. I was talking about raid5 or raidz1. The idea is to have only one drive for parity.
     
    I already figured it out. I do have experience in ZFS on x86. But I decided for myself that I can not use ZFS (or btrfs) on ARM and feel safe for data at the same time. Will wait and see. I'm sure that this will change soon.
     
    This is exactly where I came to. I've set up SnapRaid and mergerfs. For home usage it's almost perfect.
     
    You right, especially when there are not so much options, since ZFS and Btrfs are not ready yet. But I hope since we now have good ARM based hardware storage solution, like Helios64, this will change soon.
  10. Like
    gprovost reacted to Werner in Armbian 20.11.1 Focal Freezes?   
    Logs are usually stored in ram and only written every few minutes to drastically increase the lifespan of sd cards. The downside is that it is sometimes hard to track down issues. You could either disable log2ram and try to reproduce or connect debug console and follow the output of code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } dmesg and wait until another freeze happens.
     
    Though there does not necessary need to be any output. Sometimes systems freeze without giving a clue whatsoever :/
  11. Like
    gprovost reacted to Chris Bognar in Script to check the power status, and shutdown if battery is low!   
    I haven't done much work outside of shell scripting and config files, and I'm not experienced enough to work inside the systemd framework for fear of trashing the system beyond my knowledge.  I've been reading the bash guide TRS-80 offered as a reference, and I've come away with a better understanding of some of the more complex ideas, but I've been browsing it for 3 days and still have quite a bit to read and absorb.  Many thanks for his advice and fast replies.
     
    Here is a cleaned up, easier to read version of my original script . . . I haven't modified it operationally because it works like I need it to, but hopefully my style will improve as I get more involved with it.  Also thanks to gprovost for his quick replies and exceptional help to the community as a whole.  This is truly a fantastic machine and labor of love for the KOBOL team.
     
     
     
  12. Like
    gprovost reacted to Tonat in Btrfs scrub causes crash.   
    Compared to the system of m11k, my Helios64 has two 10T Ironwolf disks in slots 1 & 2, other slots are empty.
    The mount options are the same except I didn't use nodiratime (I think it is redundant because noatime is used).
    Apart from the btrfs scrub I have not had any problems at all.
     
    As an experiment I tried the following to see if it would crash again
    Do a scrub Simultaneously create two compressed tar files of the data on the disks (trying to produce significant processor and disk activity) After about 6hours I stopped the tars and did another scrub. Simultaneously un-tar the files in step 2 (which finished with expected error as the files were incomplete) Do another scrub. All the above worked correctly.
     
    This makes me think the crash originally reported was a one off event (but it would be good to know if there is an underlying cause).
    I will let you know if I have any more problems.
  13. Like
    gprovost got a reaction from djurny in Helios64 - freeze whatever the kernel is.   
    @djurny Thanks for the feedback. We will let you know.
     
    We are working with Rockchip to get to the root cause of this instability. We are still suspecting wrong DDR timing settings.
  14. Like
    gprovost reacted to SIGSEGV in Why I prefer ZFS over btrfs   
    This discussion is interesting because I can relate to both sides.
    As an end user - having multiple filesystems to choose from is great, choosing the right one is where I need to spend my time choosing the right tool for the task. Having a ZFS DKMS is great, but if after an update my compiler is missing a kernel header, I won't be able to reach my data. Shipping a KMOD (with the OS release) might give me access to my data after each reboot/upgrade. The ECC/8GB RAM myth is getting old but it has garnered enough attention that most newbies won't read or search beyond the posts with most views.
     
    Armbian as a whole is always improving - a few weeks ago iSCSI was introduced for most boards (and helped me replace two x86_64 servers with one Helios64) - and an implementation of ZFS that works out of the box will be added soon enough. That being said, this is a community project - if a user wants 24x7 incident support, then maybe the ARM based SBCs + Armbian are not the right choice for them. Having a polite discussion with good arguments (like this thread) is what gets things moving forward - We don't have to agree with all the points, but we all want to have stable and reliable systems as our end goal.
  15. Like
    gprovost reacted to TRS-80 in Btrfs scrub causes crash.   
    In the meantime I received a quite interesting reply on my above linked thread from none other than tkaiser himself.  It's quite long and full of lots of good info, but the TL;DR is that I am re-thinking my position on btrfs now, most especially on ARM (while overall, and on x86 especially I maintain my position).  But maybe you guys know all of that already and that's why you use btrfs in the first place. 
     
    However if I am going to shit up someone else's thread, especially with (apparently wrong) information, the very least I feel I should do is return and issue a retraction / update.
     
    Cheers!
  16. Like
    gprovost reacted to ebin-dev in Backup Utility   
    I am using the following modified version of an Armbian Script to rsync emmc to sd (replace UUIDs to match yours):
     
    # cat backuptosd.sh #!/bin/bash # Check if user is root if [ $(id -u) != "0" ]; then echo "Error: You must be root to run this script." exit 1 fi cat > install-exclude <<EOF /dev/* /proc/* /sys/* /media/data1/* /media/data2/* /media/data3/* /media/data4/* /media/data5/* /mnt/sd/* /mnt/ssd/* /mnt/usb/* /mnt/hd/* /run/* # /tmp/* # /root/* EOF exec 2>/dev/null umount /mnt/sd exec 2>&1 mount /dev/mmcblk0p1 /mnt/sd rsync -avxSE --delete --exclude-from="install-exclude" / /mnt/sd # change fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/etc/fstab sed -e 's/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx3c/UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx2d/g' -i /mnt/sd/boot/armbianEnv.txt umount /mnt/sd rm install-exclude  
  17. Like
    gprovost reacted to Igor in 2.5G Ethernet crash (r8152)   
    We are updating several kernel drivers with their best option - which is also a reason why Armbian is better then some generic Linux. Yes, it is used:
    https://github.com/armbian/build/blob/master/lib/compilation-prepare.sh#L201-L213
     

    I already update our fork to 2.14 and if you build kernel from sources, it will be v2.14. In case you want to change anything in the driver, send a PR. Either to upstream or our fork - just note about the changes since its not heavily monitored. Usually we just point to original source. I forget why we use a fork in this case. Not that important after all.
  18. Like
    gprovost reacted to Werner in swappiness = 100 or why he start so fast to swap   
    If you do code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } swapon you will notice that the used swap is zram. By default halt of the available memory is compressed via zram as swap and the system shall use it.
  19. Like
    gprovost 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.
     
  20. Like
    gprovost reacted to TRS-80 in ZFS on Helios64   
    @scottf007,
     
    Igor's comment was more directed at the others in the thread who are trying to solve this particular bugbear.  In other words, mostly development talk.
     
    There are lots of clues and instructions littered throughout these forums that will tell you how to get this working.  However if you get too frustrated or can't figure it out, just wait a bit longer and eventually something will be released to make this "easier" for the average Joe.
  21. Like
    gprovost 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,
     
  22. Like
    gprovost reacted to Zageron in How to upgrade to new release   
    sudo apt-get update && sudo apt-get dist-upgrade -y  
    This will upgrade your unit. I rebooted after doing this, but I'm not sure that you need to.
  23. Like
    gprovost reacted to barnumbirr in 1 ssd + 5 hdd   
    From the wiki:
    Source: https://wiki.kobol.io/helios64/sata/#sata-controller-diagram
  24. Like
    gprovost got a reaction from tmb in Missing RAID array after power loss   
    At first glance, things look pretty good so it should be easy reassemble the array.
     
    The reason it didn' t happen automatically it's because the event count between sda, sdc is different from sdb, sdd, sde. Fortunately the difference is very small, so data on the RAID should still be ok.
     
    First you need to stop the array
     
    mdadm --stop /dev/md0
     
    Let's try to re assemble without --force option
     
    mdadm /dev/md0 --assemble /dev/sd[abcde]
     
    Let us know if it works. If yes then you array should start the syncing process (cat /prod/mdstat), you could share the output of mdadm -D /dev/md0
     
    If if fails, please show the output. Next step, if previous one failed, it's to try assemble with --force option.  Please take note that if --force is used you might end up with few file corrupted (whatever writing operation that happen in the difference of event count, in your case the difference of event count is very small).
     
    mdadm /dev/md0 --assemble --force /dev/sd[abcde]
     
    Same here, share output of cat /prod/mdstat and mdadm -D /dev/md0
  25. Like
    gprovost reacted to Igor in 2.5G Ethernet crash (r8152)   
    I also updated our sources https://github.com/igorpecovnik/realtek-r8152-linux
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines