HI,

 

Yesterday night I upgraded from 3.4.112- 5.22 to 5.23

 

Today I made a reboot as login screen suggested.

 

 

xxx@nuc:~$ ssh 192.168.1.50
  ____      _     _      _                         _
 / ___|   _| |__ (_) ___| |__   ___   __ _ _ __ __| |
| |  | | | | '_ \| |/ _ \ '_ \ / _ \ / _` | '__/ _` |
| |__| |_| | |_) | |  __/ |_) | (_) | (_| | | | (_| |
 \____\__,_|_.__/|_|\___|_.__/ \___/ \__,_|_|  \__,_|
                                                     

Welcome to ARMBIAN Debian GNU/Linux 8 (jessie) 3.4.112-sun4i
System load:   0.00                Up time:       1 day        
Memory usage:  8 % of 873Mb      IP:            192.168.1.50
CPU temp:      23°C               
Usage of /:    38% of 3.7G       

Last login: Mon Oct 24 11:50:13 2016 from 192.168.1.22

[ Kernel was updated, please reboot ]
xxx@trumoi:~$ sudo reboot
[sudo] password for xxx
Connection to 192.168.1.50 closed by remote host.
 

 

Next, U-boot error appears.

 

I took an screen photo.

 

 

Thanks a lot

 

Josemari

 

 

 

Hi,

 

Because of a chance I found that, when I start the Cubieboard1 and the ethernet cable is not connected, the startup occurs normally. Naturally then I connect the cable and the plate works with no problems.

It's a bug within U-boot. I made a workaround, so next upgrades / images will be fine. You need to flash new, old 2015.10 u-boot and it will be fine.

@Igor,

 

Excellent. Thanks a lot !!!

@Igor,

 

Excuse me. Where could I find the old 2015.10 u-boot files or images ?

 

Thanks

Already fixed binaries in our beta / daily build repository, sources at denx.de/wiki/U-Boot/SourceCode

Hey, I experience cracshes of my cubietrucks (2x Xenial, 1x Wheezy) with 5.23 Armbian packages ... Can these also be because of newest u-boot?

Hey, I experience cracshes of my cubietrucks (2x Xenial, 1x Wheezy) with 5.23 Armbian packages ... Can these also be because of newest u-boot?

In most cases yes. Which kernel do you use?

2x Xenial: Linux cubietruck3 4.8.4-sunxi #6 SMP Sun Oct 23 15:55:47 CEST 2016 armv7l armv7l armv7l GNU/Linux

... and here I had the crashes independent of the package differences on both Cubies (see http://forum.armbian.com/index.php/topic/2692-package-differences-after-cubietruck-trusty-xenial-and-520-523-upgrade/)
... linux-u-boot-cubietruck-next 5.23 is installed

 

1x Wheezy (but here I had crashes before 5.23 ... no since the upgrade): Linux cubietruck 3.4.112-sun7i #10 SMP PREEMPT Sun Oct 23 15:49:51 CEST 2016 armv7l GNU/Linux

... but noticed here that "linux-u-boot-cubietruck" in 5.00 (2016-01) is installed. Can I install "linux-u-boot-cubietruck-next" there too?

 

Before that it was more stable with 5.20 Armbian

NEXT u-boot packages is for NEXT (Vanilla) kernel only. What you get from 

armbianmonitor -u

 on each machine. This way we can rule out many problems.

Cubietruck 1 - Wheezy (Legacy kernel) ... currently the "Main" server for my home-automation stuff ... planned to re-setup with Xenial hopefully soon

http://sprunge.us/HaaG

 

Cubietruck 2 - Xenial, original Trusty, upgraded with dist-upgrade to Xenial:

http://sprunge.us/QWGD

 

Cubietruck 3 - Xenial:

http://sprunge.us/gOab

 

Thank you for all your great work&support!

@maruprez @apollon77

 

I guess you share problems.

 

Our upgrading procedure from very old images is not perfect - that's my first conclusion from those logs.

 

1. Make sure you have this in your sources list or armbian.list

deb http://apt.armbian.com wheezy main utils

Change to jessie, xenial, trusty ... 

 

run apt-get update

 

2. Remove all those packages (dpkg -r name):

ii linux-firmware-image-sun7i 5.23 armhf Linux kernel firmware, version 3.4.112-sun7i
ii linux-headers-3.4.107-cubietruck 3.7 armhf Linux kernel headers for 3.4.107-cubietruck on armhf
ii linux-headers-3.4.108-cubietruck 4.0 armhf Linux kernel headers for 3.4.108-cubietruck on armhf
ii linux-headers-sun7i 5.23 armhf Linux kernel headers for 3.4.112-sun7i on armhf
ii linux-image-3.4.107-cubietruck 3.7 armhf Linux kernel, version 3.4.107-cubietruck
rc linux-image-3.4.108-cubietruck 4.0 armhf Linux kernel, version 3.4.108-cubietruck
ii linux-image-cubietruck 4.1 armhf Linux kernel, version 3.4.108-cubietruck
ii linux-image-sun7i 5.23 armhf Linux kernel, version 3.4.112-sun7i
ii linux-image-sunxi 4.4 armhf Linux kernel, version 3.4.109-sunxi
ii linux-libc-dev:armhf 3.2.82-1 armhf Linux support headers for userspace development
ii linux-u-boot-3.4.107-cubietruck 3.7 all Uboot loader
ii linux-u-boot-3.4.108-cubietruck 4.0 all Uboot loader
ii linux-u-boot-cubietruck 5.00 armhf Uboot loader 2016.01
ii linux-wheezy-root-cubietruck 5.23 armhf Armbian tweaks for wheezy on cubietruck (default branch)

3. Install those, just run under root:

apt-get install linux-wheezy-root-cubietruck linux-u-boot-cubietruck-default linux-image-sun7i linux-headers-sun7i armbian-firmware-full a10disp armbian-tools-jessie sunxi-tools

4. Reboot.

 

Cleaning on other board is similar. Please refer to this page for help with proper naming.

Hey Igor, is this mainly the advise for my first machine (the Wheezy/Legacy one?) ...

 

The others for Trusty and Xenial should not be that old and both using Vanilla kernels ...

Hey Igor, is this mainly the advise for my first machine (the Wheezy/Legacy one?) ...

 

Yes.

 

I haven't check others, I guess you got the picture what to fix there if you found some old packages.

First thank you for the detailed answer!

 

The wheezy computer was not my real problem to be honest. it was stable a long time and that's good and I soon want to move to Xenian also on that Cubietruck.

 

But because of this it was interesting that after the last version of Armbian both Cubietrucks that I had with Xenial (so Nr 2 and 3) crashed 1-2 times ... before that last update with 5.20 they were also quite stable.

 

So the question was more what to do about them to make them stable again? Downgrade to last u-boot?

 

PS: I followed the instructions above on the wheezy system and have the following errors:

On removing:

dpkg: dependency problems prevent removal of linux-libc-dev:armhf:
 libc6-dev:armhf depends on linux-libc-dev.

dpkg: error processing linux-libc-dev:armhf (--remove):
 dependency problems - not removing

on installing

root@cubietruck:~# apt-get install armbian-tools-jessie sunxi-tools
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 armbian-tools-jessie : Depends: libudev1 but it is not installable
 sunxi-tools : Depends: libusb-1.0-0 (>= 2:1.0.16) but 2:1.0.11-1 is to be installed
E: Unable to correct problems, you have held broken packages.

Additionally while comparing the both Xenial cubietricks I had "armbian-hostapd  5.13" on one and "armbian-hostapd-xenial 5.14", but both packages do not seems to be existant anymore:

root@cubietruck2:~# apt-get install armbian-hostapd-xenial
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package armbian-hostapd-xenial
root@cubietruck2:~# apt-get install armbian-hostapd
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package armbian-hostapd is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  hostapd-realtek hostapd

E: Package 'armbian-hostapd' has no installation candidate

By what they were replaced? I now installed hostapd ... I'm not using Wifi spo far so schould be unimportant :-)

The problems (at least the dependencies to install the *-tools packages could be solved using wheezy backports, or ?! is that the way to go there?

 

Are those two packages (sunxi-tools and armbian-tools-jessie) important enough for a "normal server user" to start with using backports?!