typingArtist

  • Content Count

    15
  • Joined

  • Last visited

Everything posted by typingArtist

  1. If you have a problem with the enabled switch forwarding after boot and you don’t mind some SMD resistor soldering, you can populate R1308 as described here.
  2. Ah, I forgot: @Igor, @tkaiser, I really appreciate your work! Can you tell to which degree you anticipated the b53 changes in Kernel 4.8? Since the ports are automagically named correctly after their positions on the back I’d assume that *some* work has been done. Any clue about my first attempts with high packet loss? I’m not sure whether this is actually an issue or just an artifact of a bad overall configuration.
  3. I’d really recommend to go back to 5.20 immediately at this time. Only if you don’t mind not having access to your Ethernet ports, which is the point of using a BPI-R1 in the first place for most people, you can go on with any Kernel 4.8. Update: Returning to 5.20 is not hard, just remember that you need the respective packages, which sometimes are hard to fetch if the network interfaces don’t work anymore. I took all files from here: http://apt.armbian.com/pool/main/l/linux-4.7.3-sunxi/ (, put them on the uSD from another computer via a tethered Wifi from my smartphone) and install
  4. Have been trapped by the same issue today. The trouble comes from the new b53 driver which now uses switchdev for the configuration of the Broadcom 53125 switch, not the old switch configuration tool. I have played a little with it but without any good documentation on the switchdev topic it’s actually quite hard to set up things. After modprobe’ing all the modules from the b53 folder I was rewarded with 5 new interfaces, lan1…lan4 and wan (watch the dmesg output). Note that no additional interface representing the internal eth0 port was added. Setting the link up on the virtual
  5. ​Just noticed that the most recent repository update fixed both issues. ​ ​Well done, Igor! ​
  6. Just tried a gpg --clearsign locally, so I can confirm that just the first of the two lines is required to get SHA512 signatures for --sign and --clearsign. I think that no new GPG key is required this time. Using a specific algorithm for signing a message/file is completely independent from the key, so we can stick with the current key and just instruct gpg to use the right hashing.
  7. Hi Igor, thanks for looking into this. 1. Seems to be fixable by specifying -origin=Armbian -label=Armbian when calling aptly publish repo. Also, the description field –currently “Generated by aptlyâ€â€“ would be cool to reflect some info about Armbian instead, however, a necessary patch to aptly is still sitting and waiting. 2. I’m not a GPG expert, but it seems the following two lines have to be added/updated in the relevant gpg.conf file: personal-digest-preferences SHA512 cert-digest-algo SHA512 Perhaps just one of these lines is enough. Cheers, – typingArtist
  8. I think that the Armbian repository needs some fixes. 1. apt-cache policy shows the following: 500 http://apt.armbian.com xenial/main armhf Packages release o=. xenial,a=xenial,n=xenial,l=. xenial,c=main,b=armhf origin apt.armbian.com I think that o=. xenial is not intended. I’d expect o=Armbian or that like. Same applies l=. xenial. The following is the output for a standard Ubuntu repo: 100 http://ports.ubuntu.com xenial-backports/universe armhf Packages release v=16.04,o=Ubuntu,a=xenial-backports,n=xenial,l=Ubuntu,c=universe,b=armhf origin ports.ubuntu.
  9. Hi Igor, Sorry for the late reply. I had some reconnection issues with my DSL uplink so I refrained from touching the running/connected system at all … Today I made another attempt to upgrade the system from trusty to wily. Kernel was on 4.4 already. First tried do-release-upgrade, but it didn’t find any new release, and do-release-upgrade -d was heading for xenial already, so I tweaked the apt sources for wily and went on with a standard apt-get dist-upgrade. It had some interruptions which were easily fixed by `apt-get -f install` and re-running dist-upgrade, some other problems
  10. Hi Igor, what also puzzles me is that when I log on to the console with a non-working setup, the big ASCII-Art text after logging in to the console gives me the letters "Micro" instead of indicating Lamobo R1 as with a fresh trusty installation, and it hangs at this point. Could it be that a wrong dtb is loaded? Wouldn’t that also explain the axp20x message flooding? BTW, why are there two separate and obviously different dtb files for the Lamobo-R1? root@lamobo-r1:/boot/dtb# ls -la *r1.dtb -rw-r--r-- 1 root root 27261 Sep 30 21:21 sun7i-a20-bananapi-r1.dtb -rw-r--r-- 1 root root 26911 Sep
  11. Hi Igor. Seems the download problem is due to me being already with wily (Ubuntu 15.10), and the script actually tried to migrate the apt-get sources for armbian.com to wily as well, where there is no wily support yet. Do you agree? The second problem I’m not sure. I just fully wiped the uSD card and installed a fresh Vanilla CLI Ubuntu trusty 4.2.2 image. Everything runs smooth there. Again, I tried an upgrade to wily, and once it boots with systemd, there start again trouble with journald running into timeouts. However, this time I was unable to reach the command line (console login ha
  12. Hi Igor, thanks for the hint. I performed a file system check, and the next reboot was the first which I could reach the console. However, the boot took quite long, especially logging on (console as well as ssh) was very slow. The reason for this seems to be that my CPUs are quite busy logging the following useless stream of information. I already saw that earlier today but didn't take that into account. This was *not* present before the kernel upgrade. [ 783.704487] axp20x 0-0034: uevent [ 783.706436] axp20x 0-0034: uevent [ 783.708075] axp20x 0-0034: uevent [ 783.709338] axp20x 0-0
  13. Hi Igor, thanks for your quick help! It turned out to not work immediately after your suggested procedure, but at least the first message (not finding some dtb file) went away. zImage was still not found, so I corrected the soft link /boot/zImage to the actual kernel. Now it boots again! Horray! However still it doesn’t work and I don’t have access to it. Network (LAN) works up to the ping level which is already great, but I can neither login via ssh nor on the console. It seems some basic services (logind, journald) are not correctly starting up according to the systemd messages.
  14. Hi Igor, thank you very much for Armbian. I’ve been using it on my BPI-R1 with great success since April this year. I installed Ubuntu and the latest big upgrade was the one to Wily which worked also like a charm. But I never cared about uboot or the Kernel. Boot media is a 16 GB uSD card. Last night I tried your described procedure for upgrading the kernel. I chose the vanilla kernel for Lamobo-R1 – there isn’t much you can do wrong wget -q -O - http://upgrade.armbian.com | bash It gave some warnings (still a lot about locale problems because locale support has been broken ever