Jump to content

Learnincurve

Members
  • Posts

    122
  • Joined

  • Last visited

Everything posted by Learnincurve

  1. Hi, Having successfully installed and configured Armbian on my Orangepiåplus2e, I just installed armbian next (5.34.171020 | armhf | armv7l | 4.13.8-sunxi) to sd card and booted from there Then downloaded the script from http://forum.armbian.com/index.php/topic/1070-install-to-emmc/?p=11374 installed p7zip and tried to run the script, but it looks like all the dialog "--" options are failing with command not found. Eg: ./backup_to_sd.sh: line 228: --gauge: command not found I checked that doalog is installed in the latest version. Google is noth throwing up anythingb useful. I can do an ordinary dd if=/dev/mmcblk1 | gzip > ./image.gz but wondering why dialog is not working in the script. System info at: http://sprunge.us/faZC BR. --Marius--
  2. Please disregard. I managed to interrupt the boot process from uboot and boot from sd.
  3. Hi, I have a OrangePi+ 2E running ARMBIAN 5.33 user-built Debian GNU/Linux 8 (jessie) 4.13.5-sunxi The system is installed and runs well from EMMC, but now that I have it set up more or less as I want it, I tried to boot from sdcard to do a emmc backup as here I tried first plugging the original SD that was nand-installed to emmc, but the system would only boot to emmc, su did a fresh install of armbian next to a new sd card, but the system will still only boot from emmc. Any ideas? BR.
  4. Point taken. I gave no information. Board is Orangepiplus2e running ARMBIAN 5.33 user-built Debian GNU/Linux 8 (jessie) 4.13.5-sunxi Reason I'm using mainline is that I had a lot of trouble with oom errors on this board with the legacy kernel (known issue). Thanks for the suggestion to remove/purge avahi-autoipd. I wasn't sure if that was so tightly integrated into the rest of the networking stuff that it would break the whole network setup. I'll follow the suggestion as dhcp will be available wherever I connect. No further action needed. BR. --M--
  5. Sorry to revive an old thread: The problem (on my system) is that something seems to be constantly monitoring the interfaces and reconfiguring avahi for eth0, even if there is no link. The default route is therefore being assigned to a disconnected interface. Removing the route will only work until the next time the interface comes up. It won't permanently disable Avahi for the interface. I tried doing a ifconfig eth0 down on the disconnected interface, which also kills the route, but a couple of minutes later it's back up and so is the route. What we need is something equivalent to: Johnrego found the standard solutionas follows: I think I was able to solve the problem as follows: Edit the / etc / default / avahi-daemon file Change the line: AVAHI_DAEMON_START = 1 In: AVAHI_DAEMON_START = 0 Sudo update-rc.d -f avahi-daemon remove but on my orangepiplus2e there is no /etc/default/avahi-daemon file. It looks like the whole shabang is being triggered by /etc/avahi/avahi-autoipd.action but I don't see any way to turn it off. As a test I did an ifconfix wlanX up without assigning a wireless network to wlanX. The same think happened. The interface came up with a 169.254 address and was assigned the default route. It looks as if avahi is assigning a 169.254 address to any interface that is brought up, even if no link is available. Any ideas about where the misconfiguration is, or how to cure it? BR. --Marius--
  6. For information, I sorted this using "triggerhappy": Apt installed created a "triggerhappy" system user and modified the init script to use it. crated a trigger configuration for the button press event (BTN_0 1) creted a simple script invoking systemctl poweroff -I modified sudoers accordingly. Tested:. Buttonpress shuts down the system even if users are currently logged in. The system can be started again by pressing the other, rectangular switch by the power intake, which as zador.blood.stained correctly pointed out, is hardwired as reset.
  7. Thanks. Killed the process. The rest of apt appeared to be finished and I did a new apt upgrade just to be sure. Killed the process again and now am doing a dpkg-reconfigure on the header package, to see if it will compile to conclusion.
  8. Hi, I downloaded and installed v. 5.30-next yesterday - kernel 4.11.4-mvebu. The board apppears to run slightly cooler than with v.5.25 and has been stable. This morning an apt upgrade to 5.31 was available and I started running the update. Apt upgrade has now been running for about 4 hours, compiling linux-headers-next-mvebu (5.31), with most cpu time going to cc1. Top is dynamic, with cc1 taking anything from 0% to 100% cpu, so I am guessing that nothing has hung but that header compilation will take a long time on this system. A similar very long linux header update was experienced when I tried to update this system once before. I aborted that update and failed thye next boot, as the kernel was then inconsistent. I'd like to avoid a similar problem now, but am wondering how long I should expect to wait before giving up and taking remedial action. I have not had any problems with linux header updates on other ARMbian systems (orangepi plus2e and Pine64+). Any experience/advice? BR. --Marius--
  9. Thanks for clearing that up. For the record, I haven't added anything to dts, but I guess there's enough there already. BR. --Marius--
  10. Sorry if this is stupid. This is what I found so far: From the dts file link that zador posted: gpio-keys { compatible = "gpio-keys"; pinctrl-0 = <&rear_button_pins>; pinctrl-names = "default"; button_0 { /* The rear SW3 button */ label = "Rear Button"; gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; linux,can-disable; linux,code = <BTN_0>; }; }; }; Then doing cat /sys/kernel/debug/gpio and looking for "Rear Button", I find that that is on pin 44: grep -i "Rear Button" /sys/kernel/debug/gpio gpio-44 (Rear Button ) in hi (act lo) - IRQ edge (clear ) but if I try to export pin 44, I get device or resource busy: root@clearfogbase:~# echo 44 > /sys/class/gpio/export -bash: echo: write error: Device or resource busy I compiled gpio_watch from http://blog.oddbit.com/2014/07/26/gpiowatch-run-scripts-in-respo/ which I though looked like a good way to do what I wanted. What am I doing wrong? BR. --Marius--
  11. I found the key between the USB port and the Ethernet ports at /dev/input/by-path/platform-gpio-keys-event but the other button, beside the power input is still a mystery. BR. --Marius--
  12. Hi again, The Clearfog base has two push buttons, but these don't seem to be hard-wired to any hardware functionality. Does anyone know how to find them in the system and monitor them for events? They could then be used for example to reboot or power down the system. BR. --Marius--
  13. I'm ready to embrace evil at any time, was just a little confused as both methods seemed to be partially used by default (but of course, both were examples, right?). Anyway, now that I know that the good-old anachronisms override the new and untrustworthy, I'm happy and will do a new, dark-side-only test tomorrow
  14. SOLVED: I simply disregarded nmtui and edited /etc/network/interfaces as follows: # LAN Interface allow-hotplug eth1 #no-auto-down eth1 iface eth1 inet dhcp # Internal Ethernet allow-hotplug eth0 #no-auto-down eth0 iface eth0 inet static address 172.16.0.100 netmask 255.255.255.0 #gateway 172.16.0.100 #dns-nameservers 8.8.8.8 8.8.4.4 # hwaddress ether # if you want to set MAC manually # pre-up /sbin/ifconfig eth0 mtu 3838 # setting MTU for DHCP, static just: mtu 3838 #Make sure this is never used for default route post-up ip route del default eth0 # Local loopback auto lo iface lo inet loopback Both interfaces come up and only eth1 is defined in the default route. I would like to remove network manager to avoid any pollution of the network configuration. Please advise if this can be done without breaking anything.
  15. Perfect! That worked! Thank you for replying. BR. --Marius--
  16. Hi, On my Clearfog base, I have one bootable SDHC card that I made some time ago, using Title: Armbian 5.25 Clearfogbase Debian Jessie next Kernel: Linux 4.9.7 Build date: 02.02.2017 I can't remember, but think that I flashed the card from Linux using dd bs=1M What I do remember was having some trouble back then, flashing a card that would boot and remember several attempts, using several different images. I also remember that the board dip switches were in the wrong positions as delivered from the factory and that my first attempts failed because of that. Having sorted that out and using the image described above, the system now boots (mostly) using this card, but I did want to try using a stable image now, so have been trying to flash an identical sd card using one of the current, stable images. I have now been forced over to using a Windows 10 machine, so am trying the recommended, 7zip, then Etcher approach. I clean format the card, then point Etcher at the image and card. I have tried this approach with: Armbian_5.27_Clearfogbase_Ubuntu_xenial_default_4.4.70.img Armbian_5.27_Clearfogbase_Debian_jessie_next_4.11.3.img Armbian_5.27_Clearfogbase_Debian_jessie_default_4.4.70.img All of them are giving the same boot problem: __ __ _ _ | \/ | __ _ _ ____ _____| | | | |\/| |/ _` | '__\ \ / / _ \ | | | | | | (_| | | \ V / __/ | | |_| |_|\__,_|_| \_/ \___|_|_| _ _ ____ _ | | | | | __ ) ___ ___ | |_ | | | |___| _ \ / _ \ / _ \| __| | |_| |___| |_) | (_) | (_) | |_ \___/ |____/ \___/ \___/ \__| ** LOADER ** U-Boot 2013.01 (Apr 07 2017 - 21:42:19) Marvell version: 2015_T1.0p11 Board: A38x-Customer-Board-1 SoC: MV88F6828 Rev A0 running 2 CPUs CPU: ARM Cortex A9 MPCore (Rev 1) LE CPU 0 CPU @ 1600 [MHz] L2 @ 800 [MHz] TClock @ 250 [MHz] DDR3 @ 800 [MHz] DDR3 32 Bit Width,FastPath Memory Access, DLB Enabled, ECC Disabled DRAM: 1 GiB MMC: mv_sdh: 0 *** Warning - bad CRC, using default environment PCI-e 0: Detected No Link. PCI-e 1: Detected No Link. USB2.0 0: Host Mode USB3.0 0: Host Mode USB3.0 1: Host Mode Map: Code: 0x3fed4000:0x3ff9831c BSS: 0x3ffefd5c Stack: 0x3f9c3f20 Heap: 0x3f9c4000:0x3fed4000 U-Boot Environment: 0x000f0000:0x00100000 (MMC) Board configuration detected: Net: | port | Interface | PHY address | |--------|-----------|--------------| | egiga0 | RGMII | 0x00 | | egiga1 | SGMII | In-Band | | egiga2 | SGMII | In-Band | egiga0 [PRIME], egiga1, egiga2 Hit any key to stop autoboot: 0 Trying to boot from MMC 1565 bytes read in 68 ms (22.5 KiB/s) ## Executing script at 03000000 Boot script loaded from mmc Unknown command 'load' - try 'help' Unknown command 'load' - try 'help' Unknown command 'load' - try 'help' Unknown command 'load' - try 'help' Bad Linux ARM zImage magic! Trying to boot from USB (Re)start USB... USB0: Port (usbActive) : 1 Interface (usbType = 3) : USB XHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found ** Bad device usb 0 ** ** Bad device usb 0 ** ## Executing script at 03000000 Boot script loaded from usb Unknown command 'load' - try 'help' Unknown command 'load' - try 'help' Unknown command 'load' - try 'help' Unknown command 'load' - try 'help' Bad Linux ARM zImage magic! Default boot sequence failed - falling back to TFTP Using egiga0 device TFTP from server 10.4.50.38; our IP address is 10.4.50.170 Filename 'uImage'. Load address: 0x2000000 Loading: T T T T T T T T T T Retry count exceeded; starting again Using egiga0 device TFTP from server 10.4.50.38; our IP address is 10.4.50.170 Filename 'armada-388-clearfog.dtb'. Load address: 0x2000000 Loading: T T T T T T T T T T Retry count exceeded; starting again Bad Linux ARM zImage magic! Marvell>> Please can someone suggest what I am doing wrong? Best regards Marius
  17. Hi, I'm running armbian 5.27 xenial / kernel 4.9.12-mvebu on a Clearfog base, where eth0 should have a static address and eth1 gets its config. from DHCP. The system has three possible interfaces (including the empty SFP port - eth2). By default both Ethernet ports eth0 and eth1 came up with DHCP, however, I couldn't find any config covering both of them. nmtui had a config for eth1 and eth2 (if I remember correctly), while the /etc/network/interfaces file only had a config for eth0. I have now tried to configure eth0 with a static config, both by adding it in nmtui (which didn't seem to have any effect) and then by manually editing /etc/network/interfaces. Here are my current configs: nmtui (eth1): nmtui (eth0): Both eth0 and eth1 now come up when I start the system, but I also get a default route for each of them, despite attempting in both config methods to not use eth0 for the default route. After connecting I can then go in and manually do a route del default eth0, which gives me the routing table that I want. I suspect that eth0 is being set first, from /etc/network/interfaces, but that something is reassigning it later and giving it a default route. To keep things stupid and simple, how can I remove all config methods except one, then use that to configure eth0 with a static address and route to 172.16.0.0/24 only eth1 as a dhcp interface Many thanks for your help. BR. --Marius--
  18. Thank you Tkaiser and Igor. Excellent news that we will be able to rely on the readings. BR. --Marius--
  19. Hi, I am setting up a Clearfog base as the backend for my music player. As a high-end audio device it would be a clear advantage if all processing could be passively cooled. Running Armbian_5.27_Clearfogbase_Ubuntu_xenial_default_4.4.70 the default heatsink gets very hot to the touch and feels much hotter than the reported 49 degrees. Does anyone know if there are any differences between the available kernel and armbian versions regarding temperature? Does anyone know of any inaccuracies in the temperature reporting for the ARMADA 38x? What could be regarded as a safe (reported) operating temperature for the ARMADA 38x? Does anyone know of alternative heatsinks that might be made to fit the Clearfog base with minimal modification? BR. Marius
  20. To answer my first question (and ask another): CONFIG_HWMON was set to be a loadable module. I chenged it to compile in ( CONFIG_HWMON=y ) and the build went through. BUT, now I'm facing a new issue with the script. ' at the end of the build process, it loks as if the deb package is not being built: ... ... │ INSTALL include/asm (35 files) │ │ /home/marius/temp/sources/linux-pine64/pine64-hacks-1.2/scripts/package/Makefile:90: recipe for target 'deb-pkg' failed │ │ make[1]: *** [deb-pkg] Error 1 │ │ Makefile:1082: recipe for target 'deb-pkg' failed │ │ make: *** [deb-pkg] Error 2 │ └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ mv: cannot stat '*.deb': No such file or directory [ error ] ERROR in function compile_kernel [ common.sh:273 ] [ error ] Failed moving kernel DEBs [ o.k. ] Process terminated ... ... Looking at common.sh line 273 (last line) I see: # produce deb packages: image, headers, firmware, dtb eval CCACHE_BASEDIR="$(pwd)" ${toolchain:+env PATH=$toolchain:$PATH} \ 'make -j1 $KERNEL_PACKING KDEB_PKGVERSION=$REVISION LOCALVERSION="-"$LINUXFAMILY \ KBUILD_DEBARCH=$ARCH ARCH=$ARCHITECTURE DEBFULLNAME="$MAINTAINER" DEBEMAIL="$MAINTAINERMAIL" CROSS_COMPILE="$CCACHE $KERNEL_COMPILER" 2>&1' \ ${PROGRESS_LOG_TO_FILE:+' | tee -a $DEST/debug/compilation.log'} \ ${OUTPUT_DIALOG:+' | dialog --backtitle "$backtitle" --progressbox "Creating kernel packages..." $TTY_Y $TTY_X'} \ ${OUTPUT_VERYSILENT:+' >/dev/null 2>/dev/null'} cd .. mv *.deb $DEST/debs/ || exit_with_error "Failed moving kernel DEBs" Any way to try running gthe script from that point with some extra debugging....to see why it's breaking? BR.
  21. Hi again, For a dedicated digital audio system (squeezebox) I would like to set up my Pine64 board with a preemptible kernel. I have been trying to use the procedure from https://docs.armbian.com/Developer-Guide_Build-Preparation/ to build a patched 3.10.104 kernel using the RT patch from: https://www.kernel.org/pub/linux/kernel/projects/rt/3.10/ patch-3.10.104-rt117 patch set The patches are applied successfully by the script, but break a number of things so the kernel doesn't compile. A number of the problems are linked to ip tunnelling, which I simply removed from the config as my system won't need them, but now I'm hitting: MODPOST vmlinux.o │ │ WARNING: modpost: Found 2 section mismatch(es). │ │ To see full details build your kernel with: │ │ 'make CONFIG_DEBUG_SECTION_MISMATCH=y' │ │ GEN .version │ │ CHK include/generated/compile.h │ │ UPD include/generated/compile.h │ │ CC init/version.o │ │ LD init/built-in.o │ │ drivers/built-in.o: In function `mbus_pmu_remove': │ │ arisc_dram_crc.c:(.text+0x1d38): undefined reference to `hwmon_device_unregister' │ │ arisc_dram_crc.c:(.text+0x1d38): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `hwmon_device_unregister' │ │ drivers/built-in.o: In function `mbus_pmu_probe': which looks harder to fix. Can anyone help by pointing to a RT patch set that is better suited to the A64? BR. --Marius--
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines