Heisath

DLINK has pretty easily accessible sources, go to their product page: https://eu.dlink.com/uk/en/products/dns-340l-sharecenter-4-bay-cloud-network-storage-enclosure And to their "GPL Support" page: https://tsd.dlink.com.tw/dlist?OS=GPL If you search for the device there, you actually get the tar.gz. with all the used files for building the firmware. Good way to figure out the kernel, uboot and compiler version used.

It might be. At least there you can check for an uncluttered way of building kernel and custom initramfs. But you seem to already have access to some linux terminal. So my suggestion is to: - gather information about the system from there (which kernel is it running, which modules, what partition layout, grab the device tree etc. ) ( see lsblk, lsmod, uname ...) - try to prepare a debian (with debootstrap or similar) on a usb stick. Insert the usb stick into the DLink and chroot over to your debian. Then you can try how it works w/o removing the old system. - look fo

There are no Armada 370 devices currently supported by Armbian. You can try to adopt one of the Armada 385 devices (helios4 & clearfog) or check if there ever were other Armada devices supported (dont think so). Probably you want to check here first: https://github.com/armbian/build/tree/master/config/boards https://github.com/armbian/build/tree/master/config/sources/families (mvebu) You can also check out my build tree for the WD MyCloud (which is Armada 375 based) https://github.com/heisath/wdmc2-kernel

Yeah that should be right. A ran into similiar errors when using some PCIe devices with newer kernels.

@those who didnt make it: No problem, just check the meeting log http://meeting.armbian.de/ , the irc chat log (irc.armbian.com/logs) and the Jira issues for the next release (https://armbian.atlassian.net/secure/RapidBoard.jspa?projectKey=AR&rapidView=2) @all: For the next weeks, remember to try and fix Jira issues (also mark them as done), review open PRs and issues on github. And try to get your work done before the codefreeze 2021-04-19 (Monday April 19th). @Igor: Wouldn't say so. I asked about the holiday thing in first post, a

You can plug the circuit in some simulator (like falstad.com, LTSpice or similar) to check what the parameters do. I did that for you here: https://tinyurl.com/yemxbzmt As you guessed R6 in combination with LM358 B does work as a schmitt trigger. See also this circuit with just the B half. https://tinyurl.com/yehg4ooh The exact size of R6 probably does not matter all that much.

As I said, try adding CLEAN="" to stop the script from cleaning the kernel tree in cache/

If you want to continue using the armbian buildscript but want the compilation to run faster (when doing small changes to kernel tree each time), you can also try to call ./compile.sh CLEAN="" This will skip cleaning the uboot and kernel sources and thus make compilation much faster. Warning, the patches will still be applied and might fail, shouldnt be a problem though. See https://docs.armbian.com/Developer-Guide_Build-Options/ for more options.

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-02 (Sunday May 2nd, estimate) Release Candidate: <will be added on codefreeze> Changelog: <will be added on releae> Coordinator: @Heisath The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release. Open topics: - complete

Hi, sorry for the late reply. Current state @Technicavolous : Hijax and I are pretty busy at the moment so project is progressing rather slow, but: Hijax is done with the final (?) revision of the power&serial mux board. You can check it out here: https://github.com/armbian/mpads/tree/serial-mux-updated Also we are working on the SD card muxing which is surprisingly hard: https://github.com/armbian/mpads/tree/sd-card-mux-redesign On the master branch I am working on the firmware for SD card muxer: https://github.com/armbian/mpads/tree/master (warning, the kicad

Yes this rebuildability is something we have been thinking/working on for a while. There even is an existing Jira Ticket for it: https://armbian.atlassian.net/browse/AR-175?atlOrigin=eyJpIjoiN2FhZTgyMTIxZWMxNDA2NmE5NjIxOTEzYTI4YWNiNDAiLCJwIjoiaiJ9 and the original post As of know this has not been implemented (probably because no one had enough time / interest / motivation to do it). Maybe you can? We'd also need to define how many old tags we support and for how long...

You could figure out what armbian-config does when installing the bootloader and do it manually while changing the relevant paths to your SD card. Or copy the needed files to the new sd card with bootloader. armbian-config source: https://github.com/armbian/config You will find out, that armbian-config uses the nand-sata-install script: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/nand-sata-install In there you find the call write_uboot_platform "$DIR" "${root_partition_device}" This function comes from the uboot package that you insta

Is there also a status page for the status page? Just to make sure, we know what to do, if the status page is not available

I assume the original thinking of the authors of fancontrol was, that when the programm crashes/unexpectedly get closed, it does not leave the fans at a low speed and possibly endanger the system. The fancontrol does not differentiate between shutdown and exit / kill. And from a system perspective it is much better to have annoying loud fans (but a cool and healthy system) than slowly burning away components while no sound is heard I guess that also answers your second question, if you comment those lines away, the fans wont auto speed up if fancontrol crashes or

You need to assign a fix version. Compare yours https://armbian.atlassian.net/browse/AR-600 with this one from Igor: https://armbian.atlassian.net/browse/AR-630

This has been fixed via a patch to mvebu-current (LK5.10) so should be available via nightly or with the next armbian release : https://github.com/armbian/build/blob/master/patch/kernel/mvebu-current/0001-Revert-block-simplify-set_init_blocksize-to-regain-l.patch It is fixed in LK 5.11 in mainline, but unsure if Armbian will get LK5.11 on mvebu or if we wait until the next LTS kernel version.

You will have to check the home-assistant documentation on how to remove it completely. armbian-config/softy does not have a remove feature build in. See also:

For bootable sd card, I'd just burn a fresh armbian image and rsync the original filesystem in there. This way you have an easy spare. Or you could try to shrink your partition before doing the dd.

Can always use rsync to just copy the files of the root. Theres plenty of tutorials on how to backup your root drive with rsync. I use something like: rsync -aAXh --stats --info=progress2 --delete --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*/*","/media/*","/lost+found"} / <TARGET_DIR>

@Mangix probably not, if he hasn't used it for a few months. @pierre LED 8 is the power led, if nothing else shows (not even LED1 / 2 which are system / error) I'd assume your board is not even starting and your SD card might be corrupt. For further debugging you'll need to attach a computer to the micro usb and listen with some serial terminal to the output (and post it here). Or you could burn another SD card and try with that one. For LED meaning: https://wiki.kobol.io/helios4/hardware/ For Setup (also includes connecting serial terminal): https://w

Maybe find a docker image then with Debian and MariaDB?

This seems to be a OMV specific problem. I just checked my clearfogpro with Armbian (Debian Buster) and it reports MariaDB 10.3: user@cfp-router:~# apt list --installed | grep maria WARNING: apt does not have a stable CLI interface. Use with caution in scripts. libmariadbclient18/now 10.1.41-0+deb9u1 armhf [installed,local] mariadb-backup/stable,now 1:10.3.27-0+deb10u1 armhf [installed] mariadb-client-10.3/stable,now 1:10.3.27-0+deb10u1 armhf [installed,automatic] mariadb-client-core-10.3/stable,now 1:10.3.27-0+deb10u1 armhf [installed,automatic] mariadb-common/stable,now 1:10.3.2

Great that you found & fixed it so quickly. If you add the patch via PR please include a mention (in the patch) about the upstream fixed version, so we can easily identify and remember to remove the patch again once we reach 5.11+

Does this only work on full PRs or also on Draft PR? It should only be included on full PR imho.

This seems like a SD card corruption problem. The UUID was always the long one (check any other clean installed device). And it did not get extended but rather the value in fstab got shortened! Regarding the "(in my sight) the same text" maybe unprintable characters had been added by sd card corruption? This is not the first time something like this has occured, I remember posts about corruption in /boot/armbianEnv.txt for example (recently had this myself when often unplugging power from bananapi w/o shutdown). For reference, my fstab and blkid output: root@####:~#