Jump to content

gprovost

Members
  • Posts

    580
  • Joined

  • Last visited

Reputation Activity

  1. Like
    gprovost reacted to mortomanos in Reboot not working properly with OMV   
    To give some feedback after more than one month of operation: The reboot problem did not happen again after using the overlay. For me, the problem is solved as for now.
    I recommend every user with similar problems, just post your serial output in new threads in the forum, and contact support if the board admins advise it. Great support from Kobol, thank you.
  2. Like
    gprovost got a reaction from TRS-80 in armbian-config RFC ideas   
    @TRS-80 I think it's important once in a while to re-question the whole thing because it helps to clarify the real objective that we might sometimes forget... or justify that energy should be focused somewhere else.
     
    I think ultimately the life of a distro will always depends on the size of its user base and lets distinguish here community and user base. User base includes all the passive users that we never hear from, I have no clue how much that represent for Armbian. @Igor Maybe you have such numbers : number of d/l per image and number of active forum user ? Even though this will not necessary help to say if armband-config is useful, it will help to give a sense of proportion of user we never hear from which to my assumption are often users that don't hack/tinker too much with their boards.
     
    Then I think it could be useful to run a poll on the forum & twitter and simply ask what the people are using their SBC + Armbian for :
    1/ Hacking / Tinkering
    2/ Headless server
    3/ Set-top TV box
    4/ Work Desktop
     
    Such kind of poll could will help understand the audience usage. If the great majority vote for option 1, then it would back up @TRS-80 assumption. But if majority is 3 and 4, then clearly we are talking about a user based that is not really CLI oriented. As for option 2, is a bit 50 / 50.
     
    We should also be aware of what's happening out there.
    1/ DietPi user base is growing and I guess it's because of their approach of making a big eco system of 3rd party app available to user via an interface a bit similar to armbian-config.
    2/ Debian / Ubuntu install, even in headless mode, is actually not purely CLI so we all get use to a bit of GUI even if we are advanced CLI users.
     
    I agree with Igor that the strength of armbian-config is also a lot the configuration features (without forgetting nand-sata-install which also deserve its attention). So personally I see a big plus to have armbian-config around, because it can only help to widen the user base which in fine is beneficial to Armbian sustainability.
     
    Yes that's a lot of assumption I made, It's why I think the poll would be really a nice driver for this refactoring effort.
  3. Like
    gprovost got a reaction from Igor in armbian-config RFC ideas   
    @TRS-80 I think it's important once in a while to re-question the whole thing because it helps to clarify the real objective that we might sometimes forget... or justify that energy should be focused somewhere else.
     
    I think ultimately the life of a distro will always depends on the size of its user base and lets distinguish here community and user base. User base includes all the passive users that we never hear from, I have no clue how much that represent for Armbian. @Igor Maybe you have such numbers : number of d/l per image and number of active forum user ? Even though this will not necessary help to say if armband-config is useful, it will help to give a sense of proportion of user we never hear from which to my assumption are often users that don't hack/tinker too much with their boards.
     
    Then I think it could be useful to run a poll on the forum & twitter and simply ask what the people are using their SBC + Armbian for :
    1/ Hacking / Tinkering
    2/ Headless server
    3/ Set-top TV box
    4/ Work Desktop
     
    Such kind of poll could will help understand the audience usage. If the great majority vote for option 1, then it would back up @TRS-80 assumption. But if majority is 3 and 4, then clearly we are talking about a user based that is not really CLI oriented. As for option 2, is a bit 50 / 50.
     
    We should also be aware of what's happening out there.
    1/ DietPi user base is growing and I guess it's because of their approach of making a big eco system of 3rd party app available to user via an interface a bit similar to armbian-config.
    2/ Debian / Ubuntu install, even in headless mode, is actually not purely CLI so we all get use to a bit of GUI even if we are advanced CLI users.
     
    I agree with Igor that the strength of armbian-config is also a lot the configuration features (without forgetting nand-sata-install which also deserve its attention). So personally I see a big plus to have armbian-config around, because it can only help to widen the user base which in fine is beneficial to Armbian sustainability.
     
    Yes that's a lot of assumption I made, It's why I think the poll would be really a nice driver for this refactoring effort.
  4. Like
    gprovost reacted to Igor in armbian-config RFC ideas   
    Overall, we are in this <5% or even less  But its not just about the software install. That's just a part. Its about configuring particular (hardware) functions. As easy as possible. By making this easy, we will make lots of people that are not that skilled or just lazy, happy. Also we didn't promote current armbian-config much since it never left beta stage and was more or less my pet project.
     
     
    We have no plans to reinvent the wheel. You know what Docker is and how to use it. Many people don't and they never will. But they will know what Pi-hole is and how to configure it. We just need to build an easy Docker(+native) install wrapper.
     

    Absolutely. Just don't look on it as a software installer. It's much more than that. Especially in CLI, it comes handy and it's more user-friendly than stock Debian (dpkg-reconfigure tzdata) for changing timezone for example ... You can enable hardware functions such as SPI, tweak ZSH/BASH, install headers, edit DT, edit boot parameters, enable desktop, enable AP, connect BT keyboard, enable 2FA on SSH ...
     

    Biggest complexity represent build system and things people see as granted - "Debian on SBC".
     
    But current armbian-config is not possible to develop and maintain properly which is why we are talking about and going into this RFC. The goal is to get it under control and provide as a full blown (non-beta) part of the Armbian. To keep functionality that is needed and drop what's pointless.
     
     
  5. Like
    gprovost reacted to slymanjojo in Helios64 - freeze whatever the kernel is.   
    @gprovost
    Been Running stable since  21.02.3 Buster.
    cat /etc/default/cpufrequtils
    ENABLE=true
    MIN_SPEED=408000
    MAX_SPEED=1800000
    GOVERNOR=ondemand
     
    No VDD tweaks.
     

     
  6. Like
    gprovost reacted to Seneca in Helios64 - freeze whatever the kernel is.   
    I did a dist-upgrade yesterday, and I've had two freezes since then due to high IO (probably). But I've reverted the cpufreq tweaks now (ondemand+min/max 400000/1800000), and I never enabled he vdd tweaks in boot.cmd, so there wasn't anything to revert. So we'll see how it goes, I'll try to put a lot of IO load on it the coming days.
    5.10.21-rockchip64 #21.02.3 SMP PREEMPT Mon Mar 8 01:05:08 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux  
  7. Like
    gprovost got a reaction from hartraft in Kernel panic in 5.9.14 20.11.10   
    Could you guys update to latest  kernel (linux-image-current-rockchip64_21.02.3_arm64 / LK 5.10.21)  and revert to ondemand governor with the full range of frequency in case you were on performance mode.
     
    Also remove any vdd voltage tweak you might have put in /boot/boot.cmd. If you had vdd tweak you will need to rebuild u-boot boot script after removing the lines in /boot/boot.cmd
     
    mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr  
    Let us know how the new kernel improves the stability.
  8. Like
    gprovost got a reaction from meymarce in Information on Autoshutdown / sleep / WOL?   
    WoL feature is not yet supported because suspend mode was not yet supported until now.
     
    Suspend mode has been recently added for Pinebook Pro (RK3399) in kernel mainline, so just a question of time before we got this on Helios64.
     
    https://github.com/armbian/build/blob/master/patch/kernel/rockchip64-current/board-pbp-add-suspend.patch
  9. Like
    gprovost reacted to Igor in Armbian v21.02   
    In case I forgot to mention something important https://github.com/armbian/documentation/commit/99875c73cdcdfd82ddbf58c3929b8cef5be0d4a6
  10. Like
    gprovost reacted to ebin-dev in No "Install" option in armbian-config - how to upgrade bootloader?   
    I can confirm that the following procedure updates u-boot on emmc without any issues:
     
    # cd /usr/lib/linux-u-boot-current-helios64_21.02.3_arm64 # ls -la total 8404 drwxrwxr-x 2 root root 4096 Mar 9 11:01 . drwxr-xr-x 80 root root 4096 Mar 9 11:01 .. -rw-rw-r-- 1 root root 206844 Mar 8 15:55 idbloader.bin -rw-rw-r-- 1 root root 4194304 Mar 8 15:55 trust.bin -rw-rw-r-- 1 root root 4194304 Mar 8 15:55 uboot.img # dd if=idbloader.bin of=/dev/mmcblk2 seek=64 conv=notrunc # dd if=uboot.img of=/dev/mmcblk2 seek=16384 conv=notrunc # dd if=trust.bin of=/dev/mmcblk2 seek=24576 conv=notrunc # reboot now  
  11. Like
    gprovost got a reaction from lanefu in armbian-config RFC ideas   
    I really like the idea to put the constrain that all 3rd party applications must only be supported through containers. That will clearly help to improve user experience thanks to well maintained container but mainly avoid app installation that would potentially mess up the OS. We need to think of a way to list in the menu the already installed containers (of course only list the container installed by armbian-config). Also the question will be do we want to make docker and docker-compose packages a dependency of new armbian-config ? I think we should, it will make thing easier... but of course also not a big deal to install them only when first 3rd app is being installed.
     
    I also like the fragmented approached made by @tparys clearly it will help a lot for maintenance and contribution. We will need to define a clear policy on how to handle local and global variables between the different chunk of scripts.
     
    On the CI topic, I unfortunately also don't see what could be really easily tested in an automated pipeline.
     
    Happy to participate in the refactoring effort.
     
     
  12. Like
    gprovost got a reaction from lanefu in Req: Build my Dream Compute SBC   
    @lanefu Ahahah yeah it seems you are describing more a Cluster Node SBC than a NAS which is our main focus at Kobol ;-) Sorry... But yeah while for me PoE = Remote Power Supply for the big family of everything & nothing that we call IoT... I can clearly see the benefit of it for easy clustering of a small SBC compute node.
     
    Maybe you should move the topic to a more general Rockchip thread, because honestly I don't think such design would be a priority for us right now... but who knows ;-)
  13. Like
    gprovost reacted to Heisath in Armbian v21.05 (Jerboa) Release Thread   
    Release Planning: April 3rd. Meeting in IRC channel #armbian on freenode. Meeting starts at 2pm GMT.
    (let me know if this is a bad date, because it is around easter holiday in Germany for example)
     
    Code Freeze: 2021-04-19 (Monday April 19th)
    Release Date: 2021-05-09 (Sunday May 9th)
    Release Candidate: https://github.com/armbian/build/tree/v21.05.0-rc
    Changelog: https://docs.armbian.com/Release_Changelog/#v2105-2021-05-09
    Coordinator: @Heisath
     
    The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release. 
     
    Open topics:
    - complete desktop branch merge into master (this seems generally done, but might need fine tuning)
    - enable 3D support (also done? Bugfixing)
    - discuss support for desktops (IIRC it was planned to have a longer supported LTS desktop version, we need a maintainer for that, if it happens)
    - check if remaining boards can / have been updated to LK5.10 (some were left out last release)
    - check possible u-boot updates
    - complete remaining Jira issues
    - cycle and check board support status (espressobin for example needs a new maintainer (otherwise EOS) @Pali maybe?)
    - late topics: 
    - business meeting schedule
    - kernel config changes on arm64
     
    Release Planning Meeting Agenda:
     
    Please add developers and more topics below, I will then also add them here.
    @Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @martinayotte @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava @Mangix @Pali
  14. Like
    gprovost reacted to Werner in Unable to boot   
    Good start
     
    Do you have your system on sd or eMMC?
     
    In first case plug it into any other Linux machine and edit the /boot/armbienEnv.txt on it and set verbosity to 7
     
    If on eMMC burn a sd card with a fresh helios image and boot it. If needed check kobol wiki to set necessary jumper to disable eMMC direct boot.
    Then do the same as above and increase verbosity.
     
    Then provide logs again.
  15. Like
    gprovost reacted to FloBaoti in Unable to boot   
    System is on eMMC.
    Thanks for this hint about verbosity, I didn't see it anywhere on wiki
     
    So, I boot on fresh install on sd card, changed verbosity then reboot on eMMC. I found culprit, a custom mount point prevented system for booting after cleaned it up, system boots fine !
     
    Maybe these simple diag step needs to be published to help people
     
    Sorry for my annoyance in the previous posts, but it's true that it's starting to get boring such an unstable system (reboot every day or so).
  16. Like
    gprovost reacted to Werner in Unable to boot   
    Activate serial console and check output:https://wiki.kobol.io/helios64/usb/#serial-console
    or hook up your own USB UART adapter for debugging: https://wiki.kobol.io/helios64/uext/
  17. Like
    gprovost got a reaction from bunducafe in How can I move the root filesystem manually from sata drive to eMMC   
    Yes unfortunately nand-sata-install does not work the other way around, I'm looking at it currently since there was another use case related to install on OS rootfs on HDD that wasn't also supported.
     
    The step for you case should be :
     
    1. First boot the system on a microSD card with a fresh install of Armbian.
     
    2. Copy rootfs from old destination (HDD) to new destination (eMMC)
     
    mkdir /mnt/rfs_new /mnt/rfs_old mount /dev/mmcblk2p1 /mnt/rfs_new/ mount /dev/sdX1 /mnt/rfs_old/ rsync -avrlt --delete --exclude-from=/usr/lib/nand-sata-install/exclude.txt /mnt/rfs_old/ /mnt/rfs_new/  
    3. use command blkid to know the UUID of /dev/mmcblk2p1
     
    4. Modify /mnt/rfs_new/boot/armbianEnv.txt to modify rootdev line with the UUID of /dev/mmcblk2p1
     
    verbosity=1 bootlogo=false overlay_prefix=rockchip rootdev=UUID=075c8660-77ca-4048-a04b-be3364c60a40 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u  
    5. Modify /mnt/rfs_new/etc/fstab 
     
    - Remove /media/mmcboot and /boot mount point lines
    - Edit / mount point to use the UUID of /dev/mmcblk2p1
     
    # <file system> <mount point> <type> <options> <dump> <pass> tmpfs /tmp tmpfs defaults,nosuid 0 0 UUID=075c8660-77ca-4048-a04b-be3364c60a40 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide 0 1  
    6. Sync and Poweroff
     
    7. Remove microSD and Poweron (maybe cross your finger also)
     
     
     
  18. Like
    gprovost reacted to wurmfood in Backup method for system installed on SSD (slot1)   
    Any normal backup solution should work. In general, it sounds like you want to just make an image of the live system. The dd utility will work for this.
     
    dd if=/dev/disk/by-id/[your disk] of=/path/to/zfs/pool/root.img bs=1M status=progress  
    You can adjust the block size based on what you find works well for your system. You can later restore it using exactly the same process, just switching your in-file (if) and out-file (of). Note that file here can include block devices.
  19. Like
    gprovost reacted to TijuanaKez in Installing Nextcloud after Openmediavault - Question?   
    I would suggest following this guide, and choosing the Portainer Stack option.
     
    https://forum.openmediavault.org/index.php?thread/28216-how-to-nextcloud-with-letsencrypt-using-omv-and-docker-compose/
     
    As well as being a streamlined and fairly painless way to install NextCloud and MariaDB at once, you'll get SWAG for free, which you will likely want.
  20. Like
    gprovost got a reaction from Werner in How can I move the root filesystem manually from sata drive to eMMC   
    Yes unfortunately nand-sata-install does not work the other way around, I'm looking at it currently since there was another use case related to install on OS rootfs on HDD that wasn't also supported.
     
    The step for you case should be :
     
    1. First boot the system on a microSD card with a fresh install of Armbian.
     
    2. Copy rootfs from old destination (HDD) to new destination (eMMC)
     
    mkdir /mnt/rfs_new /mnt/rfs_old mount /dev/mmcblk2p1 /mnt/rfs_new/ mount /dev/sdX1 /mnt/rfs_old/ rsync -avrlt --delete --exclude-from=/usr/lib/nand-sata-install/exclude.txt /mnt/rfs_old/ /mnt/rfs_new/  
    3. use command blkid to know the UUID of /dev/mmcblk2p1
     
    4. Modify /mnt/rfs_new/boot/armbianEnv.txt to modify rootdev line with the UUID of /dev/mmcblk2p1
     
    verbosity=1 bootlogo=false overlay_prefix=rockchip rootdev=UUID=075c8660-77ca-4048-a04b-be3364c60a40 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u  
    5. Modify /mnt/rfs_new/etc/fstab 
     
    - Remove /media/mmcboot and /boot mount point lines
    - Edit / mount point to use the UUID of /dev/mmcblk2p1
     
    # <file system> <mount point> <type> <options> <dump> <pass> tmpfs /tmp tmpfs defaults,nosuid 0 0 UUID=075c8660-77ca-4048-a04b-be3364c60a40 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide 0 1  
    6. Sync and Poweroff
     
    7. Remove microSD and Poweron (maybe cross your finger also)
     
     
     
  21. Like
    gprovost reacted to Igor in armbian-config RFC ideas   
    We can run this on actual Armbian, but for the most of the part that is not needed. We can use stock Github runners and x86 Debian & Ubuntu userland to run tests. Code must be designed as architecture independen from start and HW features has to be tested on the actual devices. But since that is a bit more complicated it doesn't need to be the part of this pipeline.
  22. Like
    gprovost reacted to bunducafe in SD-Card to eMMC OS issue   
    Hi folks,
     
    just a heads up in this thread (maybe related to others experiencing boot issues with Helios64 and OMV5):
     
    If you use the setup: OMV5, Multiple Hdds, LUKS encryption + UnionFS
     
    then it is very likely that the machine does not come up instead is booting into revocery mode. That's because it cannot find any mountpoints because of LUKS. In order to get the helios booting again you have to add a "nofail" into the mergerfs option.
     
    Unfortunately the merferfs pool does not getting mounted automatically once you decrypted the hdds within LUKS Plugin. That's a bit of a nuisance but it is bearable if you do not boot your machine every day. In my case I had to remove the nofail, the mergerfs did mount immediately and then I did put the nofail in again. There might be a more elegant possibility but at least it is a remedy to get the helios working again.
     
    Jump over to the OMV-forums and do a search for LUKS + UnionFS + nofail and you find several threads about that issue.
     
    I have no idea if it is better to swith to the merferfsfolder plugin because I have no knowledge so far if I just can change the plugins without any errors.
  23. Like
    gprovost reacted to SR-G in Helios64 - freeze whatever the kernel is.   
    So 26 days as uptime now - it seems better.
     
     
  24. Like
    gprovost reacted to Gareth Halfacree in SATA issue, drive resets: ataX.00: failed command: READ FPDMA QUEUED   
    I'd suggest getting one or more drives, setting them up in a btrfs mirror, dding a bunch of random onto them, and scrubbing. It's possible dding alone will trigger the error, but if it doesn't then scrubbing certainly should.
     
    $ sudo mkfs.btrfs -L testdisks -m raid1 -d raid1 /dev/sdX /dev/sdY /dev/sdZ $ sudo mkdir /media/testdisks $ sudo chown USER /media/testdisks $ sudo mount /dev/sdX /media/testdisks -o user,defaults,noatime,nodiratime,compress=zstd,space_cache $ cd /media/testdisks $ dd if=/dev/urandom of=/media/testdisks/001.testfile bs=10M count=1024 $ for i in {002..100}; do cp /media/testdisks/001.testfile /media/testdisks/$i.testfile; done $ sudo btrfs scrub start -Bd /media/testdisks  
    The options on the mount are set to mimic my own. Obviously change the number and name of the devices and the username to match your own. It's also set to create 100 files of 10GB each for a total of 1TB of data; you could try with 10 files for 100GB total first to speed things up, but I've around a terabyte of data on my system so figured it was worth matching the real-world scenario as closely as possible.
  25. Like
    gprovost reacted to Igor in After Install OMV no Plugins   
    Operating system and hardware has almost certainly nothing to do with the problem you are facing. This forum has mainly just general know-how about this software. I would suggest you to form your questions on OMV forums: https://forum.openmediavault.org/wsc/
     
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines