Jump to content

Recommended Posts

Posted

Judging by the log kernel (or specifically the pinctrl driver) doesn't like the DT it was booted with. Unfortunately it's impossible to see the kernel version in the video, but to me it looks like zImage file is too old (generic pinctrl bindings are supported since kernel 4.10).

Posted
2 minutes ago, zador.blood.stained said:

Judging by the log kernel (or specifically the pinctrl driver) doesn't like the DT it was booted with. Unfortunately it's impossible to see the kernel version in the video, but to me it looks like zImage file is too old (generic pinctrl bindings are supported since kernel 4.10).

 

Ok there we come closer ;-)

 

uname -a
Linux omv 4.9.12-sunxi #4 SMP Thu Feb 23 19:46:51 CET 2017 armv7l GNU/Linux

What can I do?

Posted
2 minutes ago, Aux said:

What can I do?

Make sure that the main kernel package (linux-image-next-sunxi) is upgraded and /boot/zImage symlink piints to the new vmlinuz-* file)

 

"apt-cache policy linux-image-next-sunxi" may provide some useful info

Posted

 

before update process:

 

# apt-cache policy linux-image-next-sunxi
linux-image-next-sunxi:
  Installed:           5.26
  Install kandidat: 5.26
  Paket-Pinning: (not found)
  Versionstabelle:
     5.31 500
        500 http://apt.armbian.com/ jessie/main armhf Packages
     5.30 500
        500 http://apt.armbian.com/ jessie/main armhf Packages
 *** 5.26 500
        500 http://apt.armbian.com/ jessie/main armhf Packages
        100 /var/lib/dpkg/status
     5.25 500
        500 http://apt.armbian.com/ jessie/main armhf Packages
     5.23 500
        500 http://apt.armbian.com/ jessie/main armhf Packages
     5.22 500
        500 http://apt.armbian.com/ jessie/main armhf Packages
     5.20 500
        500 http://apt.armbian.com/ jessie/main armhf Packages
     5.16 500
        500 http://apt.armbian.com/ jessie/main armhf Packages
     5.15 500
        500 http://apt.armbian.com/ jessie/main armhf Packages

 

Posted
1 minute ago, zador.blood.stained said:

This is not right. Please show output of "apt-mark showhold"

hmm nothing no output

Posted

 

2 minutes ago, zador.blood.stained said:

Then try running "sudo apt install linux-image-next-sunxi", it should upgrade the package manually.

The output say 

is linux-image-next-sunxi already the newest version

Posted

Look I cann these updates install:

 

aptitude upgrade
Die folgenden Pakete werden aktualisiert:
  armbian-firmware armbian-tools-jessie hostapd linux-dtb-next-sunxi linux-jessie-root-next-bananapi linux-u-boot-bananapi-next
  openmediavault sunxi-tools

 

Posted

As you can see, apt doesn't think that linux-image-next-sunxi needs to be upgraded, though a more recent version is present in the repository.  It is definitely not an Armbian fault since upgrade on unmodified images works fine, the only thing that needs to be improved is additional packages dependencies and relationships.

 

I already suggested what can be done next for some reason, even though the most logical solution in this case would be to erase this image, forget it ever existed and start from scratch.

Posted

Thank you  @zador.blood.stained  for the help!

 

You and @martinayotte since the only ones who really wanted to help or tried to help. Thanks for the efforts.
Very unfortunate that because of update the complete system had to reinstall, somehow disappointing.
Wishes all still much fun with system reinstall ...

 

With kind regards,

Aux

Posted
2 minutes ago, martinayotte said:

Hoping that next time in the future, the upgrade will be less tedious...

Yep,  A German proverb says "the hope dies last ..."  ;-)

Posted
7 hours ago, zador.blood.stained said:

That's why it's best to reference cards by a name instead of the device number (use "aplay -L" to get card names).

Example for sunxi mainline:


audio_output {
        type            "alsa"
        name            "Integrated"
        device          "hw:CARD=sun4icodec,DEV=0"
        format          "44100:16:2"
        mixer_type      "hardware"
        mixer_device    "hw:CARD=sun4icodec"
        mixer_control   "Power Amplifier"
        auto_resample   "no"
        buffer_time     "1000000"
}

 

Yes, a good advice! But I have several USB Audio devices...........every USB Audio device is working with hw:2,0.  I reported this problem a bit ironicaly - it's not a (real) problem.
But, never set a format in mpd.conf, only with real need. To set 'format   "*:32:*"' (or 24)is ok, it could(!) improve sonic quality because some dacs (or usb to spdif converters) prefer specific bit setting.

That governor is reset is a (half) minor problem - believe it or not, I heared it!

But - many, many, big, big thanks to the "armbians" - my cubox-i was less or more useless without armbian! You are doing a real fine "job"!

 

Posted

Try to update to 5.31 over serial console with second (working!) USB ethernet device, but somethings wrong with the update server?

 

Spoiler

Err http://apt.armbian.com/ jessie/utils hostapd armhf 1:2.5~armbian5.31+1
  500  Internal Server Error
Err http://apt.armbian.com/ jessie/utils sunxi-tools armhf 1.4.2-1~armbian5.31+1
  500  Internal Server Error
0% [Working]E: Failed to fetch http://apt.armbian.com/pool/utils/w/wpa/hostapd_2.5~armbian5.31+1_armhf.deb: 500  Internal Server Error

 

Network ist working on USB ethernet device...

Spoiler

root@heimdall:~# ping armbian.com
PING armbian.com (93.103.15.56) 56(84) bytes of data.
64 bytes from 93-103-15-56.static.t-2.net (93.103.15.56): icmp_seq=1 ttl=55 time=36.0 ms
64 bytes from 93-103-15-56.static.t-2.net (93.103.15.56): icmp_seq=2 ttl=55 time=32.5 ms
64 bytes from 93-103-15-56.static.t-2.net (93.103.15.56): icmp_seq=3 ttl=55 time=30.1 ms
64 bytes from 93-103-15-56.static.t-2.net (93.103.15.56): icmp_seq=4 ttl=55 time=42.8 ms
^C
--- armbian.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 30.191/35.416/42.864/4.776 ms

 

Posted

Ok, update is running ... just 2 minutes later ...

 

Mostly...

Spoiler

root@heimdall:~# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  hostapd linux-dtb-next-sunxi linux-headers-next-sunxi linux-image-next-sunxi
  linux-jessie-root-next-bananapi linux-u-boot-bananapi-next sunxi-tools
7 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 27.4 MB of archives.
After this operation, 697 kB disk space will be freed.
Do you want to continue? [Y/n]
Get:1 http://apt.armbian.com/ jessie/utils hostapd armhf 1:2.5~armbian5.31+1 [306 kB]
Err http://apt.armbian.com/ jessie/main linux-dtb-next-sunxi armhf 5.31
  500  Internal Server Error
Err http://apt.armbian.com/ jessie/main linux-headers-next-sunxi armhf 5.31
  500  Internal Server Error
Get:2 http://apt.armbian.com/ jessie/main linux-image-next-sunxi armhf 5.31 [16.0 MB]
21% [2 linux-image-next-sunxi 5,487 kB/16.0 MB 34%]         31.5 kB/s 11min 26s

 

Edit:
Update works fine for me, problem fixed! Thank you!

Posted
6 hours ago, RSU said:

Update works fine for me, problem fixed! Thank you!


Too many people wanted to update their system at the same time and server could not handle requests any more. You had luck.

Now this "Too many open files" error at server side is solved.

Posted

@Igor

 

4.11 kernel has a broken crypto functions. So we cannot use a lot of programs with this kernel like hostapd or openvpn. Can you move mainline kernel to experimental for the Banana pi, please ?

Posted
10 minutes ago, Charizard said:

4.11 kernel has a broken crypto functions. So we cannot use a lot of programs with this kernel like hostapd or openvpn. Can you move mainline kernel to experimental for the Banana pi, please ?

 

Thank for notify - didn't know that. Is there a patch for this?

Posted
47 minutes ago, Charizard said:

So we cannot use a lot of programs with this kernel like hostapd or openvpn


I just made an WPA2 based AP with my Cubietruck running 4.11.5 and it's working fine ... ?

Posted
On 6/15/2017 at 0:29 AM, Igor said:


Most likely u-boot configuration which initialised network is broken for Bananapi. Still checking if this is it. U-boot upgrade has been removed until this is not resolved.

 

Repeat the apt-get upgrade, although very slow, but manage to go from 5.30 to 5.31. Now everything back to normal. Thanks.

Posted

5.30 may have been impacted by a u-boot issue.  I have attempted to use 5.31 image on a Lamobo R1, and the ethernet device would detect, but not send traffic.  To test it, I downloaded the 5.25 image and ethernet worked perfectly immediately.  To determine if u-boot or something else was the problem, I proceeded to upgrade a single package at a time to determine which was stopping the ethernet from working.  I start by upgrading linux-image-next-sunxi and reboot.  Upon reboot, the ethernet device stopped working exactly as it did with the 5.31 image.

 

I'm currently in the process of downgrading the kernel on a 5.31 image to determine if it fixes the issue.  But that is taking a very long time.  I only seem to be able to get between 300 bytes and 3 Kilobytes per second from the apt.armbian.com server.  So I'll post in a couple of hours with my results.  If you would like an specific details about my setup, please let me know.  I'm relatively new to using armbian and any commands that might be required to get specific data.  However I am experienced in Linux.

Posted
1 hour ago, Russell Smith said:

the ethernet device would detect, but not send traffic.

uff, it is not me. I already formated the SDcard manually to be safe it is properly written.

Since the upgrade to 5.3x the R1 doesn't work with mainline Kernel 4.11.x

Posted
19 minutes ago, Tido said:

Since the upgrade to 5.3x the R1 doesn't work with mainline Kernel 4.11.x

 

Easy solution: https://github.com/armbian/build/issues/511

 

But obviously I'm the only one and it seems a way better idea to roll out updates that can't be tested appropriately on every device so that at least there's some update drama involved all the time. By dropping support for Lamobo R1 everyone would be happy. Users aren't annoyed by disrupting updates (security isn't an issue at all since otherwise R1 users would have to switch to a different device or solder components), 'support staff' can focus on devices worth the efforts, developers could do fun stuff instead.

Posted
3 hours ago, tkaiser said:

But obviously I'm the only one and it seems a way better idea to roll out updates that can't be tested appropriately on every device so that at least there's some update drama involved all the time. By dropping support for Lamobo R1 everyone would be happy.

 

I also support this idea with similar passion. The hardest part is done and we moved few boards to deprecated section and I also think its better to froze packages  (a new switch / feature has to be added to the build script that we don't need to use user patching method), rebuild, move working frozen kernel and bsp packages R1 images to deprecated and forget about this board. If you are bored, add switch to the build script and I'll do the rest when I got back to office.

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines