Igor

There I only have the default-file-entrys:
 
 
I did now edit my /usr/lib/armbian/armbian-zram-config and inserted the lines from the fix at the right place (which were missing).
The fix inserted/corrected the SystemMaxUse=20M in /etc/systemd/journald.conf
 
Before a reboot I did enter a "journalctl --vacuum-size=5M"
 
And after the reboot I have:
root@opi-one(192.168.6.114):~# df Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf /dev/zram0 49584 19676 26324 43% /var/log Many thanks at @Igor
 
 

For those who couldn't made it, meeting logs: https://freenode.irclog.whitequark.org/armbian/2020-04-04 Meeting summary goes directly into Jira issues/bugs and the actual work. 
 
Thank you all for attending the meeting!

For those who couldn't made it, meeting logs: https://freenode.irclog.whitequark.org/armbian/2020-04-04 Meeting summary goes directly into Jira issues/bugs and the actual work. 
 
Thank you all for attending the meeting!

For those who couldn't made it, meeting logs: https://freenode.irclog.whitequark.org/armbian/2020-04-04 Meeting summary goes directly into Jira issues/bugs and the actual work. 
 
Thank you all for attending the meeting!

For those who couldn't made it, meeting logs: https://freenode.irclog.whitequark.org/armbian/2020-04-04 Meeting summary goes directly into Jira issues/bugs and the actual work. 
 
Thank you all for attending the meeting!

Oh,I fixed this problem spend 2 weeks,I finally heard sound from 3.5 mm jack (this jack is OMTP otherwise need keep press headphone button)
 
I see this topic,and I compair https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/codecs/rt5640.c and https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/codecs/rt5651.c,this rt5651 not enable mclk and orangepi4"s rt5651 linked i2s1,the i2s1's SCLK_I2S_8CH parent not SCLK_I2S1_8CH defult and need set alsamixer in following(also use alsactl save this alsamixer state):
amixer set 'HPO L' on amixer set 'HPO R' on amixer set 'HPOVOL L' on amixer set 'HPOVOL R' on amixer set 'HPO MIX HPVOL' on amixer set 'OUT MIXL DAC L1' on amixer set 'OUT MIXR DAC R1' on amixer set 'Stereo DAC MIXL DAC L1' on amixer set 'Stereo DAC MIXR DAC R1' on And I not familiar with electronics,I did some patch and hope this can help armbian fix 
fix-i2s1-clk.patch orangepi4-rt5651.patch orangepi4-i2s_8ch_mclk.dts

I've done a fresh "git clone" to get rid of the issue.
I'm now doing a new a new "tour of my Allwinner garden" with 5.6.1, and then I will do some commits ...

New Armbian CI autotest facility:

Switch: https://amzn.to/2w91QIZ
USB PSU: https://amzn.to/2R2mzW8
HUB: https://amzn.to/343ysQS
 

 

Currently it does not retries. Only once. Will do two retries, otherwise error.

New Armbian CI autotest facility:

Switch: https://amzn.to/2w91QIZ
USB PSU: https://amzn.to/2R2mzW8
HUB: https://amzn.to/343ysQS
 

 

https://www.google.com/search?q=How+to+remove+existing+docker+container 

Our next release date is coming and perhaps its time to discuss what to push into 20.05, what not, resolve open questions and distract from most used keyword for past few weeks.
 
@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @count-doku @chwe @ning @lanefu @gprovost @aprayoga @5kft
@JMCC @Werner @karabek @martinayotte @tkaiser @selfbg @Siraj ... to name just a few which might find this move useful  
 
I am preparing a meeting on IRC in Saturday at 1 pm GMT - this is reasonable good timing for US / EU folks. The idea behind this meeting is that (ideally) everyone, who will be present, quickly present (in alphabetical nick order) what they are working (not working on anything is equally legit) on followed by a discussion. If a feature, project or a fix can be pushed into this release. Plus answer and decide on other open questions. You are welcome to expand this with a PR/change document directly. This way we could - on a long run - improve all project parameters.

As my example -  what I am currently working and IMHO could be implemented by 20.05:
 
- setting up auto test facility, software and hardware which is a great support tool for making releases. It is already helping me finding bugs.
- merging mainstream kernel config in the non-hardware areas could go into this release
- firmware split up with @ning
 
... more Jira's during a week.
 
Ideally it would be that prior to this meeting you write into Jira what you are working and join discussion about your task/project/idea with a link - who does not have access shall PM to @lanefu or @Igor - reviewing and prioritising goes faster and better with Jira.
 
Welcome!

On my side, I'm planning to commit my work for Allwinner 5.6.y, since it now without RCs ...

just a short one.. and I didn't read all of it.. working on:
rk3399 to 5.6 (more or less done with: https://github.com/armbian/build/pull/1759 but testing needed especially for everything except pbp) display of pinebook pro working with mainline kernel - same PR camera working on 4.4 for pinebook - not even started yet I would love to merge rk3399 and rockchip64 bsp kernels to keep maintenance easier there - let's see if we get the mali mess sorted out there rk1808 into wip - the boards are there.. but time is missing and kernel source will be a pain maybe further cleaning of opi 4b DT

I ran it now on Odroid N2 and it gets stuck at:
 

I will ofc not proceed with debugging this 3rd party software, but it would be good to notify the author that there is something wrong ...
 
Armbian config script only calls their installer after installing Docker first: https://github.com/armbian/config/blob/master/debian-software#L1780

Our next release date is coming and perhaps its time to discuss what to push into 20.05, what not, resolve open questions and distract from most used keyword for past few weeks.
 
@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @count-doku @chwe @ning @lanefu @gprovost @aprayoga @5kft
@JMCC @Werner @karabek @martinayotte @tkaiser @selfbg @Siraj ... to name just a few which might find this move useful  
 
I am preparing a meeting on IRC in Saturday at 1 pm GMT - this is reasonable good timing for US / EU folks. The idea behind this meeting is that (ideally) everyone, who will be present, quickly present (in alphabetical nick order) what they are working (not working on anything is equally legit) on followed by a discussion. If a feature, project or a fix can be pushed into this release. Plus answer and decide on other open questions. You are welcome to expand this with a PR/change document directly. This way we could - on a long run - improve all project parameters.

As my example -  what I am currently working and IMHO could be implemented by 20.05:
 
- setting up auto test facility, software and hardware which is a great support tool for making releases. It is already helping me finding bugs.
- merging mainstream kernel config in the non-hardware areas could go into this release
- firmware split up with @ning
 
... more Jira's during a week.
 
Ideally it would be that prior to this meeting you write into Jira what you are working and join discussion about your task/project/idea with a link - who does not have access shall PM to @lanefu or @Igor - reviewing and prioritising goes faster and better with Jira.
 
Welcome!

Perhaps we need one example how this is planned and others can follow this? I am not sure everyone noticed this and even I was confused how this should be done.
 
@sfx2000 @gprovost I would like not to deal with more gadgets at this point. We added Jira several months ago and we haven't manage to use much of its powers. IRC is nothing fancy, but its good enough. We have a channel recorder, no need to deal with any subscriptions and/or legal stuff. It works. Consider that many folks are old school or geeky, where IRC is the thing and already a Skype represent a far end of comm tools  

Anyway, my concerns goes to the meeting content. To come up with an agenda that will help us bring up, put attention to common problems and to spark our comm channel regardless of technology behind this. For the future, if majority decide we need to upgrade to something from this century , I will follow.

Our next release date is coming and perhaps its time to discuss what to push into 20.05, what not, resolve open questions and distract from most used keyword for past few weeks.
 
@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @count-doku @chwe @ning @lanefu @gprovost @aprayoga @5kft
@JMCC @Werner @karabek @martinayotte @tkaiser @selfbg @Siraj ... to name just a few which might find this move useful  
 
I am preparing a meeting on IRC in Saturday at 1 pm GMT - this is reasonable good timing for US / EU folks. The idea behind this meeting is that (ideally) everyone, who will be present, quickly present (in alphabetical nick order) what they are working (not working on anything is equally legit) on followed by a discussion. If a feature, project or a fix can be pushed into this release. Plus answer and decide on other open questions. You are welcome to expand this with a PR/change document directly. This way we could - on a long run - improve all project parameters.

As my example -  what I am currently working and IMHO could be implemented by 20.05:
 
- setting up auto test facility, software and hardware which is a great support tool for making releases. It is already helping me finding bugs.
- merging mainstream kernel config in the non-hardware areas could go into this release
- firmware split up with @ning
 
... more Jira's during a week.
 
Ideally it would be that prior to this meeting you write into Jira what you are working and join discussion about your task/project/idea with a link - who does not have access shall PM to @lanefu or @Igor - reviewing and prioritising goes faster and better with Jira.
 
Welcome!

Our next release date is coming and perhaps its time to discuss what to push into 20.05, what not, resolve open questions and distract from most used keyword for past few weeks.
 
@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @count-doku @chwe @ning @lanefu @gprovost @aprayoga @5kft
@JMCC @Werner @karabek @martinayotte @tkaiser @selfbg @Siraj ... to name just a few which might find this move useful  
 
I am preparing a meeting on IRC in Saturday at 1 pm GMT - this is reasonable good timing for US / EU folks. The idea behind this meeting is that (ideally) everyone, who will be present, quickly present (in alphabetical nick order) what they are working (not working on anything is equally legit) on followed by a discussion. If a feature, project or a fix can be pushed into this release. Plus answer and decide on other open questions. You are welcome to expand this with a PR/change document directly. This way we could - on a long run - improve all project parameters.

As my example -  what I am currently working and IMHO could be implemented by 20.05:
 
- setting up auto test facility, software and hardware which is a great support tool for making releases. It is already helping me finding bugs.
- merging mainstream kernel config in the non-hardware areas could go into this release
- firmware split up with @ning
 
... more Jira's during a week.
 
Ideally it would be that prior to this meeting you write into Jira what you are working and join discussion about your task/project/idea with a link - who does not have access shall PM to @lanefu or @Igor - reviewing and prioritising goes faster and better with Jira.
 
Welcome!

Just to inform, newest 5.4.28-odroidxu4 kernel seems to work fine too. Hopefully past problems with every new update are gone ;-)

+ updates to: rockpis, rockchip64 and odroidxu4 legacy kernel

This image: https://dl.armbian.com/nanopineo2black/archive/Armbian_20.02.1_Nanopineo2black_buster_current_5.4.20.7z

eMMC is normally recognized.
cat /proc/partitions major minor #blocks name 179 0 62367744 mmcblk0 179 1 61739968 mmcblk0p1 179 32 30535680 mmcblk2 179 33 30226224 mmcblk2p1 252 0 51200 zram0 252 1 506600 zram1 Perhaps your eMMC is dead / not compatible?
 

It is when you insert it for the third time and you get a confirmatory click as the connector engages! Things are now looking more promising. mmcblk2 now appears (still unpartitioned so no mmcblk2p1.) Thank you for your help especially being able to demonstrate that the current release does support eMMC. 

Ok, it’s working perfect.

@Marko Buršič