Jump to content

typingArtist

Members
  • Posts

    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 installed them just like the following on the BPI-R1 (Note: I don’t know whether the order of package installs is relevant, but this order did work for me): $ sudo dpkg -i linux-image-*.deb linux-dtb-*.deb linux-firmware-*.deb linux-headers-*.deb $ sudo reboot I assumed (right) that the newer u-boot is quite okay, and I’d assume that newer dtb packages should work as well, but let’s be on the safe side now and install all 4 packages. Before the reboot you can take a look at /boot and ensure that the right softlinks have been created.
  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 external interfaces works, and configuring the VLAN on each port works (as long as you don’t forget to specify the option `self` to the `bridge` command). However, I haven’t been able to assign VIDs to the eth0 port, the same applies to my VLAN’ed internal ports for wan and lan. So I wonder how connecting the external VLANs to the internal port is supposed to work. I also played with brctl, but this didn’t have any significant effect either. A final attempt was done using the non-VLANed eth0. However, the packet loss was so high (1 out of 10 pings replied) that I refrained from further experimenting and just swapped back to 5.20. I suppose the next step is to fix the driver regarding the high packet loss. I’d expect that to be a regression or something. Only then it makes sense to start playing with the iproute2 stuff again.
  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.com 2. apt-get update shows weak SHA1 An apt-get update shows the following message: W: http://apt.armbian.com/dists/xenial/InRelease: Signature by key DF00FAF1C577104B50BF1D0093D6889F9F0E78D5 uses weak digest algorithm (SHA1) Ubuntu is signing InRelease with SHA512 … perhaps Armbian could catch up here as well? Thanks for consideration, – typingArtist
  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 with rsyslog dependency loop conflict resolved after a reboot. After full upgrade of wily I did an upgrade to 4.5 kernel (still marked as trusty on armbian.com download URL), and after reboot everything works. Thank you, Igor, for the support! Great!!! It would be really cool to actually claim support for wily because … well, it works.
  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 30 21:21 sun7i-a20-lamobo-r1.dtb Now I’m still at the freshly installed trusty, but I’m really suffering from the old ppp that comes with it (2.4.5). 2.4.6 comes with vivid onwards, so not even an update to utopic would fix it. OTOH, vivid comes with systemd which seems to be one of the major problem points, and from what I read in the meantime in other threads, you’re not (yet) in favor of systemd …
  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 hangs), so I don’t know the CPU load or the kernel logs. After shutting down and inspecting /var/log on the card, there is nothing suspicious on it as it seems. I will retry once more with freshly installed trusty and then upgrade just to vivid. I need proper systemd support … What are your plans for supporting wily?
  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-0034: uevent [ 783.710503] axp20x 0-0034: uevent [ 783.712724] axp20x 0-0034: uevent [ 783.714080] axp20x 0-0034: uevent [ 783.715340] axp20x 0-0034: uevent [ 783.717095] axp20x 0-0034: uevent [ 783.718352] axp20x 0-0034: uevent [ 783.720370] axp20x 0-0034: uevent [ 783.722504] axp20x 0-0034: uevent [ 783.723808] axp20x 0-0034: uevent [ 783.725765] axp20x 0-0034: uevent [ 783.727074] axp20x 0-0034: uevent [ 783.728549] axp20x 0-0034: uevent [ 783.730249] axp20x 0-0034: uevent [ 783.732059] axp20x 0-0034: uevent [ 783.733499] axp20x 0-0034: uevent [ 783.735591] axp20x 0-0034: uevent [ 783.736788] axp20x 0-0034: uevent [ 783.737902] axp20x 0-0034: uevent [ 783.739632] axp20x 0-0034: uevent [ 783.740900] axp20x 0-0034: uevent [ 783.743762] axp20x 0-0034: uevent [ 783.745107] axp20x 0-0034: uevent [ 783.746368] axp20x 0-0034: uevent [ 783.747599] axp20x 0-0034: uevent As you see I get one of these log entries about every millisecond! Seems that this is actually holding journald to do its service without running into timeouts. My /var/log/{kern,sys}.log files are growing quickly ... Do you have any suggestions? Edit: I get errors when trying apt-get update root@lamobo:/var/log# apt-get update Ign http://ports.ubuntu.com wily InRelease Ign http://apt.armbian.com wily InRelease Ign http://ports.ubuntu.com wily-updates InRelease Ign http://apt.armbian.com wily Release.gpg Get:1 http://ports.ubuntu.com wily Release.gpg [933 B] Hit http://ports.ubuntu.com wily-updates Release.gpg Ign http://apt.armbian.com wily Release Get:2 http://ports.ubuntu.com wily Release [217 kB] Hit http://ports.ubuntu.com wily-updates Release Err http://apt.armbian.com wily/main armhf Packages 404 Not Found [IP: 213.168.13.40 80] Get:3 http://ports.ubuntu.com wily/main armhf Packages [1,386 kB] Ign http://apt.armbian.com wily/main Translation-en Get:4 http://ports.ubuntu.com wily/universe armhf Packages [6,617 kB] Get:5 http://ports.ubuntu.com wily/multiverse armhf Packages [118 kB] Get:6 http://ports.ubuntu.com wily/main Translation-en [837 kB] Get:7 http://ports.ubuntu.com wily/multiverse Translation-en [107 kB] Get:8 http://ports.ubuntu.com wily/universe Translation-en [4,597 kB] Hit http://ports.ubuntu.com wily-updates/main armhf Packages Hit http://ports.ubuntu.com wily-updates/universe armhf Packages Hit http://ports.ubuntu.com wily-updates/multiverse armhf Packages Hit http://ports.ubuntu.com wily-updates/main Translation-en Hit http://ports.ubuntu.com wily-updates/multiverse Translation-en Hit http://ports.ubuntu.com wily-updates/universe Translation-en Fetched 13.9 MB in 1min 10s (198 kB/s) W: Failed to fetch http://apt.armbian.com/dists/wily/main/binary-armhf/Packages 404 Not Found [IP: 213.168.13.40 80] E: Some index files failed to download. They have been ignored, or old ones used instead.
  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. Soft reboot (CTRL-ALT-DEL) can be triggered, but doesn’t complete. I already tried to hit a key on the USB keyboard during uboot start to stop autostart and let me enter "setenv bootargs_target rescue" but it seems that uboot doesn’t like (this) USB keyboard. It just autostarts anyway. Should this work with a USB keyboard or just over serial console which I’m currently not prepared to use? Update: I patched /boot/boot.cmd’s bootargs to include target=rescue, but it seems it does the normal start anyway. Within a couple of boot attempts it finally managed to boot once to the end and let me log in, but after the next reboot (entering 'reboot' also hangs in the shutdown process, so once more hard rebooting) the problem again persists. *sigh* Do you know of any reason why journald should refuse to start? And why should logind not start properly? There is no /var/log/journal directory, so I created one, but it didn’t help either.
  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 since), also about nstall_ like seen by others, but I was quite confident that it would turn out good. However, now it’s bricked in uboot. See the following image. Do you have any suggestions for fixing the boot process without overwriting the root partition? I’m going to make a backup of it, but it would be great if there would be a solution without a fresh install.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines