GreyLinux
-
Posts
12 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by GreyLinux
-
-
On 9/20/2021 at 4:56 PM, David Pottage said:
We have all seen the recent release announcement of Armbian 21.08 which now includes a beta release of Debian 11 (Bullseye).
I have a RockPro64 (Rockchip 3399) that is currently running Debian 10 (Buster) that I would like to upgrade, so that it gets the latest packages from Debian and continues to receive security patches. I am tempted to just upgrade it by editing /etc/apt/sources.list and pulling the latest packages (the debian way), but I wondered if there is a safer way to perform the upgrade.
Has anyone else upgraded a Debian based Armbain system that way. Are there any issues to watch out for?
What customisations are there in Armbian besides the kernel? How easy would it be to apply those changes after the upgrade?
Thanks.
is the Bullseye image considered stable for Rockpro64 , in regards to starting from scratch with a fresh image and not upgrading ?
I know the downloads page suggest that the userspace has an unstable status , is this because its still being tested with said hardware for issues?
thanks in advance for any info .
-
On 11/13/2020 at 9:28 PM, soerenderfor said:
@GreyLinux - Sorry for the delay, i did use 2020.01-ayufan-2014-gff2cdd38 uboot. I'm pretty sure just flashed it on sd card (not 100% sure) and flashed spi, the i could boot Armbian from my "5" port on sata pcie card.
Maybe it is possible witharmbian-config
I'm not sure, because i haven't tryed uboot update from armbian-config.
Nice 👍 thanks @soerenderfor
this is my next objective . I will have a look into whether I can do it with armbian-config . -
@soerenderfor
I think this will be my next step ! Currently I do indeed boot from the SD card . Would you have any info on how to best to boot from the ssd instead? -
I think I was just lucky that a lot of you guys had tried other cards and I could learn from your hard work . Marvell card for the win !
-
@soerenderfor
its going really really well , I've just installed simpnas on the rockpro64 and I'm seriously impressed, it's brilliant . The card has been working flawlessly doesn't skip a beat with heavy uploading and the rockpro64 barely uses any of it's processing power to run several docker containers and simpnas .I'm running kernel 5.8.17
-
@soerenderfor
wow that is incredibly tight. Great effort getting all that to fit into the NAS case, utilising every inch.I have a meager 2x 2.5 inch SSD's so lots of wasted space .
I might have to ask your opinion on the simpNaS solution you use , but that's a topic for another thread .
-
wow this is seriously amazing , thanks to @soerenderfor for pointing this project out .
I find this clean interface enticing , one thing that bothers me with openmediavault is the complexity of the admin panel , it provides to many options.
I have some questions but if required I can ask them on simpnas forum .
currently I have openmediavault installed on a rockpro64 and in docker I run HomeAssistant, Radicale caldav server and I'm working on a Jellyfin container. This is behind an nginx reverse proxy container that exposes only HomeAssistant and Radicale containers to outside of my network.
I use docker compose to run all said containers, I have to use the latest docker-compose which I install using pip ,because the Radicale container requires an option not available in the docker-compose provided by Debian .
So my first question is seeing as all the apps are run using docker do you foresee a problem with me uninstalling the apt installed docker-compose and installing via pip ?
My second question is regarding a stable release , do you have a projection of when this will be considered as out of beta ? not that this would prevent me from switching from Openmediavault to Simpnas this is just an open query.
Third question do you plan on implement a firewall tab in the network section , or have you already ? otherwise of course adding iptables rules or running ufw via the command line is possible .
Final question do you think adding a Portainer app is possible , as visually its a great option to manage container ?
thanks in advance for your response and for creating this awesome project .
-
On 10/20/2020 at 9:04 PM, soerenderfor said:
rmmod pwm-fan echo 0 > /sys/class/pwm/pwmchip1/export echo 110 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle echo 500 > /sys/class/pwm/pwmchip1/pwm0/period echo 1 > /sys/class/pwm/pwmchip1/pwm0/enable in /etc/rc.local
Perfect at least I have base few value to start my testing from and see if I need to adjust to suit my setup .
On 10/20/2020 at 9:04 PM, soerenderfor said:How is that card for you? I have tested around 10 cards. And runs with the same card as you besides my card has 5 ports, and it is the best of all the cards. The expensive cards have been a sad expereince.
Yeah I think it's an excellent card so far as I say I haven't yet managed to do any real intensive testing, but as you say it's given me zero down time so far compared to the pine64 standard card, which wouldn't take much to upset and then I would need to spend 20 minutes fixing every few days. The rest of the NAS case hardware ( quality speaking ) and of course the rockpro64 itself are brilliant especially for the price point .
I made sure I did a lot of research before purchasing the marvell 88SE9230 and so far it's the perfect companion to the NAS case and rockpro setup .
-
22 hours ago, soerenderfor said:
@GreyLinux - I just did put the fan settings in /etc/rc.local the fan runs always but nearly silent.
My 4xHDD temps runs very low, between 34-36° the SSD hits 37-39°
I did mange to fit 5 disks in the NAS case.
I think this is the route I will go , after a little bit of thought , I concluded that with my setup of 2 SSD's , the 80mm case fan and a tall heatsink, I would benefit more from just trying to keep everything cool rather than just having the fan work when the CPU is getting a little hot.
I'll have to do some testing to discover the most optimum setting for the fan to keep everything cool but not too noisy.
I am however , still intrigued with the overlay concept and so I will be doing further research into this as I think its an interesting topic that I haven't really given much thought to before. I've discovered that it features quite heavily when you begin to get serious with arm based SBC's and therefore will prove useful in learning.
Out of interest @soerenderfor what value did you find worked for your setup to keep the temps that low with such a full case ?
QuoteWhat sata card do you have?
I decided on the Marvell 88SE9230 this one to be exact
I hoping, although I haven't done any serious testing, that this removes the errors I was getting with the pine64 PCIe card, w hich eventually mounted my drives as read only, before remounting them as different drive devices.
thanks for advice , much appreciated .
-
Hi all ,
I'm also interested in this topic as I require a 5. kernel to use the marvel PCIe card with the rockpro64 , like the original poster I fan runs continuously and I have no control over it .
From reading this thread I have learnt a lot , however I'm trying to work out which is the best solution or if I even understand them all .
I gather that although the ATS option can be made to work on a newer kernel its not a good option because a hard-coded default 50Hz is not ideal for the standard 80mm pine64 fan.
I always understand by removing the PWM module as @Dunc4n1d4h0 suggests and control the fan manually with the caveat that it runs continuously albeit at a defined frequency and duty cycle ( I'm new to all this and suggestions are that running the fan continuously is better for a NAS use case) .
The final solution is one that I sort of understand but in relative terms I'm still a noob with Linux, so as I understand it you use the default pwn fan module create a file rk3399-rockpro64-tz.dts in the boot directory along with the file fdt_overlay.patch.txt , install the fdtoverlay tool as linked by the @usual user GitHub issue and using fdt_overlay.patch.txt overlay the existing rk3399-rockpro64.dtb with rk3399-rockpro64-tz.dts that provides an editable option to control the fan duty cycle or frequency ,depending on the temp similar to ATS solution but the kernel manages it instead of a script .
any direction , advice or information would be appreciated
thanks in advance
-
On 10/12/2020 at 9:05 AM, soerenderfor said:
@Meier @aldrick I do have rockpro64, i have only experinced kernel freeze with some crap sata pcie cards, and yes card from pine64 stores is one of them.
I run Armbian buster with kernel 5.8.13. I use OMV5 with no problems what so ever, i did update spi bootloader from ayufan, installede armbian on ssd.
Boot up from and run from SSD, + 4 disk attached (1x480GB SSD, 2x3.5" 2x2.5"), i did write 4TB on one of the disks, yesterday.. No problems..
ROCK64, i have not used that board for a long time, the usb ports acts like my girlfriend when she is mad.sorry to hijack this thread but I tried exactly as you have with kernel 5.8.13 with OMV5 and as you say it does discover the PCIe card marvell 88SE9230 and drives successfully after adding a udev rule that binds the driver to the card , however on a 5.(+) kernel the fan runs continuously . Did you discover a way to control the fan on the newer kernel , if you implement this setup .
Upgrade Debian Buster to Bullseye
in Beginners
Posted
most of the hardware download pages I looked at showed it still as unstable status , must be a glitch in the matrix !
thanks for the reply , I will be changing over my setup to bullseye shortly then.