MadMax

Members
  • Content Count

    17
  • Joined

  • Last visited

About MadMax

  • Rank
    Member

Recent Profile Visitors

424 profile views
  1. Whats wrong? I'm not a Linux God like you and just ask questions.
  2. I see no stretch there. Seems like i wasted my money on that board. Seems like everything after Jessi has no working HDMI and other problems. And also DietPI stretch that they call stable does not boot.
  3. I tried Armbian_20.05.0-trunk.034_Odroidc1_buster_current_5.4.17_minimal and it does not boot. Seems like there was a Stretch version? Why are older releases that where working are deleted? I'm also confused by the naming now. The last image i downloaded a view month ago was Armbian_5.95 Now it's Armbian_19.11.3 Is that the date now? If yes what was the number meaning before? So there will be support again and Armbian for C1 is not dead?
  4. Hm its a nightly. Is it stable and somebody working on it? Where is the old stuff like Jessie?
  5. Where are the Odroid C1 images? This page is empty: https://dl.armbian.com/odroidc1/archive/ What is/was the latest stable Debian? I don't need Desktop but sound should work over HDMI. Its to bad the C1 has no support anymore. Seems to be the only board that does up to 384kHz Audio.
  6. It's not that I'm fighting for seconds. It was more curiosity. If i can use this thing after ~30 seconds everything is OK. My TV or satellite receiver are slower :D I will buy a Rock64 next month for another use case (surveillance cam display h265) and then i will see how the boot time is there. And if there is no difference in boot time between SD and eMMC i now know i don't need a eMMC there.
  7. That was the answer to my question in the first place. Funny that there is no difference. So no reason for me to buy another board and let the BPi spoil in the drawer.
  8. I still don't know where i see the boot time in armbianmonitor. Where do you see that A1 Samsung? I was using a stopwatch from plugin until i saw the login and that was 27 seconds. I thought booting from the SSD makes a big difference because of I/O but there is no difference to the micro SD. Is the CPU or the SATA on the BPi a bottleneck when it comes to booting? Also just found out that "systemd-analyze blame" command: ~# systemd-analyze blame 9.024s networking.service 4.245s armbian-hardware-monitor.service 3.272s dev-sda1.device 3.151s systemd-rfkill.service 2.406s dev-zram1.device 2.268s dev-zram2.device 2.210s dnsmasq.service 1.692s systemd-udev-trigger.service 1.588s armbian-ramlog.service 1.577s hostapd.service 1.497s keyboard-setup.service 1.285s armbian-zram-config.service 1.224s loadcpufreq.service 1.016s ntp.service 883ms systemd-journald.service 845ms ssh.service 824ms systemd-logind.service 623ms rc-local.service 612ms rsyslog.service 605ms sysstat.service 582ms user@0.service 427ms systemd-fsck@dev-disk-by\x2duuid-e727db0f\x2dc49e\x2d438d\x2dbc29\x2deedf14228e88.service 370ms systemd-modules-load.service 328ms resolvconf.service 325ms systemd-user-sessions.service 312ms systemd-update-utmp.service 289ms kmod-static-nodes.service 280ms cpufrequtils.service 272ms fake-hwclock.service 271ms alsa-restore.service 258ms systemd-tmpfiles-setup.service 251ms sysfsutils.service 230ms systemd-udevd.service 227ms systemd-journal-flush.service 220ms sys-kernel-debug.mount 218ms systemd-tmpfiles-setup-dev.service 184ms systemd-sysctl.service 180ms systemd-remount-fs.service 178ms media-mmcboot.mount 162ms dev-mqueue.mount 144ms sys-kernel-config.mount 136ms systemd-random-seed.service 117ms console-setup.service 96ms armbian-hardware-optimize.service 72ms systemd-update-utmp-runlevel.service 66ms boot.mount 52ms tmp.mount
  9. It's cheaper to buy a 4€ Pololu Step-Up regulator than a 60€ Lime. You do but i want to see it also :-) Here is mine: http://ix.io/1mVc Question was more if eMMC is much faster than a A1 SD and not why mine is so slow. Because i did not think until now it is slow - is it? I have no comparison to eMMC and my RPi's and the Odroid O2 are not faster then the BPi...
  10. On the BPi is no power on the SATA Power connector? So why not just using a 5V Step-Up regulator? I don't see how armbianmonitor is telling me the boot time.
  11. Whats the difference using a LiPo on the BPi or Lime? Where can i see the boot time in that table? Mine takes to long? I don't know what is normal. I was using a stopwatch...
  12. I'm building a portable battery powered NAS because syncing and having everything multiple times on all my Android devices sucks. I took my old Banana Pi connected a SSD to the SATA port and made it a access point (no Samba yet installed). Booting from the 16GB SanDisk Ultra A1 is 27 seconds. Moving everything to the SSD in armbian config is also 27 seconds (no difference?) I know the Banana has not the fastest SATA and NIC and that USB 3 on the Rock64 is faster. But i don't copy tons of gigabyte to the device everyday and for streaming over the WiFi stick it's fast enough. I'm interested on the boot time of the Rock64 (eMMC or USB/SSD). If its not much faster then i see no reason to by a Rock64 for that. Also the Banana has the advantage that you can solder a battery to it.
  13. I ask because i started with Armbian + Softy OMV. There i first made a Hotspot and it was working. Then i found out that the OMV images are based on Armbian and thought i test it. But adding the Wifi stick there in network interfaces did not work and gave errors: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; systemctl start 'networking' 2>&1' with exit code '1': Job for networking.service failed because the control process exited with error code. See "systemctl status networking.service" and "journalctl -xe" for details. Error #0: OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; systemctl start 'networking' 2>&1' with exit code '1': Job for networking.service failed because the control process exited with error code. See "systemctl status networking.service" and "journalctl -xe" for details. in /usr/share/php/openmediavault/system/process.inc:175 Stack trace: #0 /usr/share/php/openmediavault/system/systemctl.inc(86): OMV\System\Process->execute(Array, 1) #1 /usr/share/php/openmediavault/system/systemctl.inc(146): OMV\System\SystemCtl->exec('start', NULL, false) #2 /usr/share/openmediavault/engined/module/networking.inc(44): OMV\System\SystemCtl->start() #3 /usr/share/openmediavault/engined/rpc/config.inc(194): OMVModuleNetworking->startService() #4 [internal function]: OMVRpcServiceConfig->applyChanges(Array, Array) #5 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array) #6 /usr/share/php/openmediavault/rpc/serviceabstract.inc(149): OMV\Rpc\ServiceAbstract->callMethod('applyChanges', Array, Array) #7 /usr/share/php/openmediavault/rpc/serviceabstract.inc(565): OMV\Rpc\ServiceAbstract->OMV\Rpc\{closure}('/tmp/bgstatusEw...', '/tmp/bgoutputKS...') #8 /usr/share/php/openmediavault/rpc/serviceabstract.inc(159): OMV\Rpc\ServiceAbstract->execBgProc(Object(Closure)) #9 /usr/share/openmediavault/engined/rpc/config.inc(213): OMV\Rpc\ServiceAbstract->callMethodBg('applyChanges', Array, Array) #10 [internal function]: OMVRpcServiceConfig->applyChangesBg(Array, Array) #11 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array) #12 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('applyChangesBg', Array, Array) #13 /usr/sbin/omv-engined(536): OMV\Rpc\Rpc::call('Config', 'applyChangesBg', Array, Array, 1) #14 {main}
  14. Is there a difference between installing Armbian and then OMV via Softy vs the OMV images?
  15. I was searching for a UPS for the Banana classic and then saw you just can connect a battery to it. What i can't find information about if it needs to be unprotected or if i can use my protected Keeppower 18650 Li-Ionen's that i already have for my flashlight anyway. And is there anything special i need to do in Armbian? Just connect the battery and it works? Hard to find information :-(