• Content Count

  • Joined

  • Last visited

About PSL

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. NetworkManager is troublemaker. Option "dhcp-duid" configures NM how to generate DUID, see detail in It looks like NM at Armbian uses file "/etc/machine-id", and it transforms machine-id to DUID. And that corresponds to my observations, several Armbian computers have the same /etc/machine-id, like Odroid C4 has the same machine-id as Pine A64 computers. From my point of view, this is a BUG in Armbian. I think this "machine-id" should be generated during install process to be unique for each computer. Other possible
  2. I checked Raspbian and I think it doesn't use Network manager and DHCP client is responsible for generation of DUID. Armbian uses Network Manager and DUID is created by Network manager, so I think that Network manager is troublemaker here. Good introduction to DUID is this blog post: Wikipedia has good overview too and it has link to related RFC document. Timestamp can be used to generate DUID and this is a problem for these small co
  3. I just tried with Odroid C4. I use "unsupported" version with legacy kernel" because "supported" version with mainline kernel doesn't boot... I can post log from "serial console" but I cannot see anything usefull there, the last message from U-Boot is "Starting kernel" It is interesting that Odroid C4 with "unsuported" Armbian gets the same IPv6 address as Pine A64 boards, they use the same DUID: DUID: 00046268261de6497cba3d521a1b6401159c IPv6 address: fdf4:26f8:bebb::723 It could be a bug in dhcpd client. Or it could be HW related, that dhcp client uses some
  4. Another update to DUID issue with Arbmian. I connected RPI4 with the latest Raspi OS to the same network. I think that RPI4 do it right, it uses different type of DUID and MAC address is part of DUID, so I assume that each RPI4 will have unique DUID because the last 12 digits in the UUID is MAC address of eth0 interface (RJ45): DUID: 0001000126d11676dca632b75e57 IPv6: fdf4:26f8:bebb::412
  5. I retested Android on eMMC, Nougat and Oreo and I cannot find any evidence that they modified firmware on Le Potato board. Application AIDA64 on Android reports that board is LePotato, no trace about Z28 PRO. I used better power supply today and I do not have problems with Android on eMMC, so the problems I had the last time and those looked like a problem with video driver were caused by weak power supply; Android Nougat runs from eMMC module in similar way like it runs from good microSDHC. I was able to test even Android Oreo but it has problem to exit application and return to home screen,
  6. I just noticed that my Le Potato board identifies as "Z28 PRO". It is just a cosmetic problem but from a screenshot in this thread I see that it could be a bug... This is welcome message that I see when I connect with ssh client to the Le Potato board: _________ ___ ____ ____ ___ |__ /___ \( _ ) | _ \| _ \ / _ \ / / __) / _ \ | |_) | |_) | | | | / /_ / __/ (_) | | __/| _ <| |_| | /____|_____\___/ |_| |_| \_\\___/ Welcome to Armbian 20.08.7 Focal with Linux 5.8.13-meson64 No end-user support: community creations
  7. I have strange problem with IPv6 address received from DHCP server. Two Pine64+ boards have different IPv4 address but they share the same IPv6 address. I finally installed Armbian "Focal" to Pine64+ from Kickstarter (board with micro USB power connector). I have two such boards. I connected these to a test network where gateway is OpenWrt 19.07.4; there is DHCP server running on OpenWrt. I do not need IPv6 addresses (I do not have IPv6 connectivity enabled) but these were activated by OpenWrt. Problem is that I have found that both Pine64+ boards receive different IPv4 address but IPv6 a
  8. I have two Le Potato boards (, I installed Armbian Focal on them. One of the board has defective HDMI (board from Kickstarter?), it has no HDMI output. Other board was ordered from Amazon, a year later. It has HDMI output but colors are not right (white is green, black is purple, etc, HDMI image is not nice but it is usable; it is interesting that when I use HDMI to VGA adapter, colors are right; when board runs in low resolution, colors are right on HDMI too. But when resolution is high, 1950x1200, then HDMI colors are wrong - I swapped HDMI cable without a
  9. It is possible but ARMBIAN doesn't support this :-( (status of 2020-09) Ubuntu on Odroid C2 or ARM instances runing Ubuntu in Amazon AWS cloud support that. This is the trick: sudo dpkg --add-architecture armhf sudo apt-get update sudo apt-get install libc6:armhf libstdc++6:armhf Problem is that Armbian doesn't support armhf architecture (no packages in the repository). Well that is just one part of the problem. Other part is that ARM CPU has to support "armhf" instructions. Most of these low end CPUs used on SBCs support "armhf" but there are ARM chips for datacentres