rrf 3.4 beta update on ODROID sbc not possible

joeko

@o_lampe said in rrf 3.4 beta update on ODROID sbc not possible:

@joeko said in rrf 3.4 beta update on ODROID sbc not possible:

is there a mix of beta version and make the problem ?

Have to tried to upgrade to beta5 first, and if successful, go for beta6?

no, fresh and new install this morning on duet3 mini.
first with rf 3.3 (all fine) and update to the beta

joeko

@o_lampe said in rrf 3.4 beta update on ODROID sbc not possible:

@joeko said in rrf 3.4 beta update on ODROID sbc not possible:

is there a mix of beta version and make the problem ?

Have to tried to upgrade to beta5 first, and if successful, go for beta6?

hmm, if didnt try it but if possible i will.
but how i can do this ? as far as i know i can only update to the latest beta.

Nurgelrot

@joeko So is this issue solved? I'm on 3.4 beta6 on both a Duet3d mini5 and a BTT GTR board using the STM32 port of RRF.

using Armbian (debian 10.11 aka buster)

joeko

@nurgelrot said in rrf 3.4 beta update on ODROID sbc not possible:

@joeko So is this issue solved? I'm on 3.4 beta6 on both a Duet3d mini5 and a BTT GTR board using the STM32 port of RRF.

using Armbian (debian 10.11 aka buster)

no way, always the same.
updates hold back and it seems that the betas are mixed....
witch gpiochip and pinnumber did you set in the json ?

witch way you have used for install, first stable and than beta ?

Nurgelrot

@joeko I'm always following unstable on these so I went from 3.4 Beta somthing to Beta 6

I did have an issue with the STM32 version not patching right away it complained about a dependency problem with duetsoftwareframework requiring <= reprapfirmware 3.4-b5-999. I removed all the duet packages and reinstalled latest unstable and it worked.

My transfer pin is 67 on /dev/gpiochip0. But these are different on different versions of linux on the odroid C4. I remember that the ubuntu version shipped with the Odroid had it at pin 68 on chip1

if any version is installed but nothing is running (or you have shut it down) try running:

sudo /opt/dsf/bin/DuetControlServer -ud

that will produce errors on screen if you have any sort of communication problem. ^D or ^C to exit.

joeko

@nurgelrot said in rrf 3.4 beta update on ODROID sbc not possible:

@joeko I'm always following unstable on these so I went from 3.4 Beta somthing to Beta 6

I did have an issue with the STM32 version not patching right away it complained about a dependency problem with duetsoftwareframework requiring <= reprapfirmware 3.4-b5-999. I removed all the duet packages and reinstalled latest unstable and it worked.

My transfer pin is 67 on /dev/gpiochip0. But these are different on different versions of linux on the odroid C4. I remember that the ubuntu version shipped with the Odroid had it at pin 68 on chip1

if any version is installed but nothing is running (or you have shut it down) try running:

that will produce errors on screen if you have any sort of communication problem. ^D or ^C to exit.

with armbian buster it works. i also did it with buster from hardkernel (meveric from forum) but this was not possible. now it works.

sudo /opt/dsf/bin/DuetControlServer -ud

give me

Duet Control Server v3.4-b6
Written by Christian Hammacher for Duet3D
Licensed under the terms of the GNU Public License Version 3

[info] Settings loaded
[fatal] Another instance is already running. Stopping.

i think that is ok because it is running

thank you for your help

@chrishamm
it would make it easier when it offer the choice to modify the json for the tfr pin while the installation...much easier.

jay_s_uk

@joeko I've updated our DSF on armbian instructions here
https://teamgloomy.github.io/dsf_on_armbian.html

Nurgelrot

@joeko Yes a opportunity to override the default pin locations in the post-install script would be very handy. Also when you upgrade make sure you do not override your existing config.json. I've done that a couple times now getting annoying

joeko

@jay_s_uk said in rrf 3.4 beta update on ODROID sbc not possible:

@joeko I've updated our DSF on armbian instructions here
https://teamgloomy.github.io/dsf_on_armbian.html

first i have used armbian buster with kernel 4.9. with that version i got boot problems. after change to buster with kernel 5.1 is this gone. i spend many hours to fix that.....

do i realy set

Then you have to add the following lines in /boot/armbianEnv.txt :

extraargs=apparmor=1
security=apparmor

because here is it also possible without this.

jay_s_uk

@joeko if you want to use 3rd party plugins (and the duetpimanagement plugin), then yes, you need apparmor installed

joeko

@jay_s_uk said in rrf 3.4 beta update on ODROID sbc not possible:

@joeko if you want to use 3rd party plugins (and the duetpimanagement plugin), then yes, you need apparmor installed

installed yes but also ?

Then you have to add the following lines in /boot/armbianEnv.txt :

 

extraargs=apparmor=1

security=apparmor

i have it installed and running but i am not sure if this is needed. here is it running without

jay_s_uk

@joeko check with sudo aa-status, it'll tell you if its running.
I had to add it on the armbian build i'm using though as I don't think its installed by default

joeko

apparmor module is loaded.
9 profiles are loaded.
9 profiles are in enforce mode.
   /opt/dsf/plugins/EndstopsMonitor/**
   /opt/dsf/plugins/InputShaping/**
   /usr/bin/man
   /usr/sbin/chronyd
   /usr/sbin/haveged
   man_filter
   man_groff
   nvidia_modprobe
   nvidia_modprobe//kmod
0 profiles are in complain mode.
2 processes have profiles defined.
2 processes are in enforce mode.
   /usr/sbin/chronyd (2569)
   /usr/sbin/chronyd (2570)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

looks good ?

jay_s_uk

@joeko yep, looks good

joeko

and again, first while

sudo apt-get install duetsoftwareframework

i got errormessage that no connection to the board is possible (of course) and the sbc hangs and i had to cut the power, power on and modify the json and install new.