• Content Count

  • Joined

About suchende

  • Rank

Recent Profile Visitors

533 profile views
  1. @Tido No, I did not buy the wrong SBC, I just want to try this software. 32bit works so far, but not as a docker container. You need to deploy this directly. I address this as a possible workaround for armbian-config.
  2. Not directly, but maybe mayan-edms should be offered only to arm64 or we need a direct deployment.
  3. The same here on an odroid hc1 docker version Client: Version: 18.09.1 API version: 1.39 Go version: go1.11.6 Git commit: 4c52b90 Built: Tue, 03 Sep 2019 19:59:35 +0200 OS/Arch: linux/arm Experimental: false Server: Engine: Version: 18.09.1 API version: 1.39 (minimum version 1.12) Go version: go1.11.6 Git commit: 4c52b90 Built: Tue Sep 3 17:59:35 2019 OS/Arch: linux/arm Experimental: false docker logs mayan-edms standard_init_linux.go:207: exec user process caused "exec format error"
  4. thank you, I give it a try. Currently I switched to the HDD, the amount of written data is enormous, like about 200GB for mysql and 150GB in two hours! Luckily the responsiveness raised a lot.
  5. hey, I'm having some trouble with my ssh connection to an armbian based server. It feels like a heavy lag within the filesystem, sometimes it takes up to 20 seconds to open a file with vim or use cd with tab-completion. But it is not always there, it feels more like some heavy write operation occurs spontaneously. I start digging but I have no clue why this happens. But at least I found the most disk I/O processes which are influxdb and mysql. [16:54|root@odroidhc1 ~]# cat /syscat /sys/fs/ext4/mmcblk0p1/session_write_kbytes 118811040 [16:55|root@odroidhc1 ~]# uptime 16:56:03 up 10 days, 3:53, 3 users, load average: 0,87, 0,64, 0,59 [17:15|root@odroidhc1 zram-config]# iostat Linux 4.14.150-odroidxu4 (odroidhc1) 12.01.2020 _armv7l_ (8 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 2,03 0,44 0,93 0,85 0,00 95,75 Device tps kB_read/s kB_wrtn/s kB_read kB_wrtn loop0 24,86 12,44 0,00 10932869 668 mmcblk0 8,55 90,30 135,32 79391237 118968040 zram0 0,88 1,54 1,97 1349836 1735284 zram1 2,35 3,83 5,58 3369880 4903220 sda 1,10 110,95 47,61 97549568 41860980 dm-0 24,86 12,43 0,00 10931824 668 [16:36|root@odroidhc1 ~]# cat /etc/fstab # <device> <dir> <type> <options> <dump> <fsck> UUID=8a464498-f41a-4de4-9a05-52e636c8135e / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 UUID=92d36a67-0322-42cf-9a4c-81a0563f58c9 /mnt btrfs defaults,nofail 0 1 tmpfs /tmp tmpfs defaults,nosuid 0 0 tmpfs /var/www/tmp tmpfs defaults,nofail,noatime,nosuid,uid=33,gid=33,mode=0755,size=100m 0 0 tmpfs /var/log/audit tmpfs defaults,nofail,noatime,nosuid,mode=0755,size=100m 0 0 [16:37|root@odroidhc1 ~]# swapon NAME TYPE SIZE USED PRIO /dev/zram1 partition 998,5M 246M 5 However, the value (session_write_kbytes) is constantly rising and not within the commit time delay from fstab file. The mariadb is set to fsync and not o_direct, it should respect the commit entry? However (118811040 KBytes == 116026 MBytes == 113 GBytes) within 10 days? It seems a lot for a single user nextcloud instance? The influxdb takes like 6 values every minute from 5 inputs. Did someone optimize the mariadb setup for a sdcard?
  6. You could use this: Do you have another system to do this offline? Or do you do this under a running armbian on this hc1 board?
  7. Same here, but with a odroid hc1. the bootloader should be the latest (odroidhc1 4.14.150-odroidxu4). The blue led is permanently on, the systems needs a hard power reset
  8. Thank you very much. I fixed it with a different approach in while. Take all necessary files in /boot and /lib/modules and copy them. Save the mbr and partition table with fdisk to a file, then copy straight with the dd if=/dev/mmcblk0 of=/dev/sdc bs=512 count=8192 and restore afterwards the saved fdisk dump. I forget to mentioned it here: the SoC is the odroid HC1.
  9. the dump from fdisk: p device Boot begin end sectors size Kn typ /dev/mmcblk0p1 8192 30396575 30388384 14,5G 83 Linux F beginn end sectors size 2048 8191 6144 3M 30398464 30703615 305152 149M the raw copy with `dd if=/dev/mmcblk0 of=/dev/sdc skip=2048 seek=2048 bs=512 count=6144 conv=notrunc` fails. Did you meant byte #8192 or sector? the kernel modules are still there.
  10. I made a kernel upgrade which was not successful The kernel does not boot up. Unfortunately armbian does not contain a fallback method to load the old kernel. Therefore I need a way to restore the old kernel. I copied a working boot folder from another sdcard which does not work. What did I miss?
  11. So far Kernel 4.14.20 worked for me. (I need however a way to restore it on to the sdcard)
  12. Usually I compile the kernel on my own because I need apparmor. The current 4.14.29 fails with this log. I tried it again with the Debian stretch next nightly. However this leads to the same: Blue and green LEDs get off and that's it. And a little bit offtopic: How do I fix a broken kernel...
  13. I remember this problem with the cubietruck an the armbian 4.9 kernel. With a self compiled 4.10 kernel it works. The same problem occurs with the odroid hc1. The self compiled 4.14 kernel works flawless.
  14. Try the other USB port. It sounds funny, but at my cubietruck it works at least for a 2.5" external drives.
  15. Hey, I compiled and installed the latest kernel (4.7.3 and uboot 2016-09) but something went wrong. The dtb file was missing. while a manually correct the missing dtb from another run a flashed uboot in the wrong way. Instead of using the drive /dev/sdc I used the partition /dev/sdc1. I read this: with these two commands I should have erased the first 1Mb dd if=/dev/zero of=/dev/sdc1 bs=1k count=1023 seek=1 dd if=u-boot-sunxi-with-spl.bin of=/dev/sdc1 bs=1024 seek=8 (Luckily there is no backup at all ) gpart gives me this: gpart -vg /mnt/veracrypt1/Armbian_5.14_Cubietruck_Debian_jessie_4.6.2.raw dev(/mnt/veracrypt1/Armbian_5.14_Cubietruck_Debian_jessie_4.6.2.raw) mss(512) Primary partition(1) type: 131(0x83)(Linux ext2 filesystem) size: 1525mb #s(3123200) s(2048-3125247) chs: (16/0/1)-(1023/3/32)d (0/0/0)-(0/0/0)r hex: 00 00 01 10 83 03 E0 FF 00 08 00 00 00 A8 2F 00 ---------------------------------------------------------------------------------------- gpart -vg /mnt/veracrypt1/broken_cubietruck.img dev(/mnt/veracrypt1/broken_cubietruck.img) mss(512) Primary partition(1) type: 131(0x83)(Linux ext2 filesystem) size: 14991mb #s(30701568) s(2048-30703615) chs: (0/56/33)-(913/88/8)d (0/0/0)-(0/0/0)r hex: 00 38 21 00 83 58 C8 91 00 08 00 00 00 78 D4 01 I try to use the values from the raw image to recover at least some data, but fsch.ext4 fails. Do you see an opportunity to restore the partition table? Or to recover the filesystem? Edit: Topic can be deleted. I wasn't capable of restoring the filesystem.