Jump to content

chymian

Members
  • Posts

    5
  • Joined

  • Last visited

  1. so it was NM who gave the HC1 the dhcp-ip on the "enx001e0630cdfb"-interface, not the ifupdown-scripts. makes sense. and why was it not reachable after I added a bridge-config to interfaces (with eth0), not touching NM. that shouldn't have touched the NM setup of "enx001e0630cdfb" - right? tracing the traffic shows, that both, the fixed bridge-ip (eth0) and the NM-dhcp-ip (enx001e0630cdfb) responds to arp-packages, but not to ping or ssh. it seems to be buggy and leads to inconsistent behavior. so, relaying on NM would also mean removing /etc/network/interfaces and at least add a BFW to the other interfaces.*-files about the changed name, to make it less confusing. it left me with an headless server (HC1) which was not net-reachable. and for an server-like device, I experienced over the years, is an fixed config much more reliable then NM. just my 2cent
  2. may I chime in with my latest experiences on self-build stretch images for the XU4/HC1: in stretch, the former eth0 get renamed to enx001e0630cdfb (on the XU4), and surly to other names on other HW. that does not happen when upgraded from jessie. see also: https://wiki.debian.org/NetworkConfiguration#Predictable_Network_Interface_Names that leads to: 1. the default /etc/network/interface config with 'eth0 dhcp' does work here somehow – but it shouldn't. don't know for other HW. 2. but setting up an bridge br0 with eth0 as interface does not work. it needs the new interface name. so it seems a little bit random and might leave one with an unreachable device. suggestion: adapt all /etc/network/interface* files with an automatic script at firstboot to the interface-name the kernel uses (i.e. in /proc/net/dev) somthing like this should do it: IFNAME=`grep en /proc/net/dev|cut -d: -f1` or IFNAME=`basename $(ls -d /sys/class/net/en*)` sed -i s/eth0/$IFNAME/g /etc/network/interfaces* same applies to wlan-interfaces
  3. hello dear armbian developers, building jessie or stretch with btrfs-root ends up in an boot-loop. this is due to an wrong entry in boot.ini setenv rootfstype "ext4" changing it manually to "btrfs" fixed the Problem the config I used: KERNEL_ONLY="no" # leave empty to select each time, set to "yes" or "no" to skip dialog prompt KERNEL_CONFIGURE="no" # leave empty to select each time, set to "yes" or "no" to skip dialog prompt CLEAN_LEVEL="make,debs,oldcache" # comma-separated list of clean targets: "make" = make clean for selected kernel and u-boot, # "debs" = delete packages in "./output/debs" for current branch and family, # "alldebs" = delete all packages in "./output/debs", "images" = delete "./output/images", # "cache" = delete "./output/cache", "sources" = delete "./sources" # "oldcache" = remove old cached rootfs except for the newest 6 files DEST_LANG="de_DE.UTF-8" # sl_SI.UTF-8, en_US.UTF-8 # advanced KERNEL_KEEP_CONFIG="no" # do not overwrite kernel config before compilation EXTERNAL="yes" # build and install extra applications and drivers EXTERNAL_NEW="prebuilt" # compile and install or install prebuilt additional packages CREATE_PATCHES="no" # wait that you make changes to uboot and kernel source and creates patches BUILD_ALL="no" # cycle through available boards and make images or kernel/u-boot packages. # set KERNEL_ONLY to "yes" or "no" to build all packages/all images BSPFREEZE="" # freeze armbian packages (u-boot, kernel, dtb) INSTALL_HEADERS="" # install kernel headers package BUILD_DESKTOP="no" BOARD=odroidxu4 BRANCH=next RELEASE=stretch ROOTFS_TYPE=btrfs FIXED_IMAGE_SIZE=1888 should I open a bug on github for this? thanks a lot guenter
  4. Hello Tom, sorry for late response, but the forum-sw didn't send me an email per default on reply to my thread… yes, the XU4 was on OMV, but the same thing happens with pure armbian. (see below) not sure what you are asking about: "disabling zram?" sysctl -a |grep swap vm.swappiness = 0 4.9.37-odroidxu4 ii linux-image-next-odroidxu4 5.33 armhf Linux kernel, version 4.9.51-odroidxu4 Sep 29 14:10:14 nas kernel: Unhandled fault: imprecise external abort (0x1406) at 0x00000000 Sep 29 14:10:14 nas kernel: pgd = deb0c000 Sep 29 14:10:14 nas kernel: [00000000] *pgd=00000000 Sep 29 14:10:14 nas kernel: Unhandled fault: imprecise external abort (0x1406) at 0x00000000 Sep 29 14:10:14 nas kernel: pgd = deb0c000 Sep 29 14:10:14 nas kernel: [00000000] *pgd=00000000 Sep 29 14:10:14 nas kernel: Unhandled fault: imprecise external abort (0x1406) at 0x00000000 Sep 29 14:10:14 nas kernel: pgd = deb00000 Sep 29 14:10:14 nas kernel: [00000000] *pgd=00000000 Sep 29 14:10:14 nas kernel: Unhandled fault: imprecise external abort (0x1406) at 0x00000000 Sep 29 14:10:14 nas kernel: pgd = deb00000 Sep 29 14:10:14 nas kernel: [00000000] *pgd=00000000 Sep 29 14:10:14 nas kernel: Unhandled fault: imprecise external abort (0x1406) at 0x00000000 Sep 29 14:10:14 nas kernel: pgd = deb00000 Sep 29 14:10:14 nas kernel: [00000000] *pgd=00000000 Sep 29 14:10:14 nas kernel: Unhandled fault: imprecise external abort (0x1406) at 0x00000000 Sep 29 14:10:14 nas kernel: pgd = deb00000 Sep 29 14:10:14 nas kernel: [00000000] *pgd=00000000 Sep 29 14:10:14 nas kernel: Unhandled fault: imprecise external abort (0x1406) at 0x00000000 Sep 29 14:10:14 nas kernel: pgd = deb00000 Sep 29 14:10:14 nas kernel: [00000000] *pgd=00000000 Sep 29 14:10:14 nas kernel: Unhandled fault: imprecise external abort (0x1406) at 0x00000000 Sep 29 14:10:14 nas kernel: pgd = deb00000 Sep 29 14:10:14 nas kernel: [00000000] *pgd=00000000
  5. hello, during ansible-fact-gathering following errors are logged. no instability has been noticed. uname -a Linux nas 4.9.46-odroidxu4 #10 SMP PREEMPT Fri Sep 1 05:29:13 PDT 2017 armv7l GNU/Linux Sep 06 15:02:36 nas ansible-setup[28480]: Invoked with filter=* gather_subset=['all'] fact_path=/etc/ansible/facts.d gather_timeout=10 Sep 06 15:02:37 nas kernel: Unhandled fault: asynchronous external abort (0x1211) at 0x00000000 Sep 06 15:02:37 nas kernel: pgd = e69ccc80 Sep 06 15:02:37 nas kernel: [00000000] *pgd=42c04003, *pmd=00000000 Sep 06 15:02:37 nas kernel: Unhandled fault: asynchronous external abort (0x1211) at 0x00000000 Sep 06 15:02:37 nas kernel: pgd = e69cc1c0 Sep 06 15:02:37 nas kernel: [00000000] *pgd=66008003, *pmd=00000000 Sep 06 15:02:37 nas kernel: Unhandled fault: asynchronous external abort (0x1211) at 0x00000000 Sep 06 15:02:37 nas kernel: pgd = eb2b2b00 Sep 06 15:02:37 nas kernel: [00000000] *pgd=518bd003, *pmd=00000000 Sep 06 15:02:37 nas kernel: Unhandled fault: asynchronous external abort (0x1211) at 0x00000000 Sep 06 15:02:37 nas kernel: pgd = eb2b2e00 Sep 06 15:02:37 nas kernel: [00000000] *pgd=6c76b003, *pmd=00000000 Sep 06 15:02:37 nas kernel: Unhandled fault: asynchronous external abort (0x1211) at 0x00000000 Sep 06 15:02:37 nas kernel: pgd = eb2b2280 Sep 06 15:02:37 nas kernel: [00000000] *pgd=68d45003, *pmd=00000000 Sep 06 15:02:37 nas kernel: Unhandled fault: asynchronous external abort (0x1211) at 0x00000000 Sep 06 15:02:37 nas kernel: pgd = eb2b28c0 Sep 06 15:02:37 nas kernel: [00000000] *pgd=6505c003, *pmd=00000000 Sep 06 15:02:37 nas kernel: Unhandled fault: asynchronous external abort (0x1211) at 0x00000000 Sep 06 15:02:37 nas kernel: pgd = eb2b2e40 Sep 06 15:02:37 nas kernel: [00000000] *pgd=6a342003, *pmd=00000000 Sep 06 15:02:37 nas kernel: Unhandled fault: asynchronous external abort (0x1211) at 0x00000000 Sep 06 15:02:37 nas kernel: pgd = e69cc700 Sep 06 15:02:37 nas kernel: [00000000] *pgd=6a23e003, *pmd=00000000
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines