Kernel update procedure has been changed

Recommended Posts

Hmm, maybe you need to do some manual file system checking? Enable / change loglevel=7 in kernel command line that you will see things ...


And yes, some USB keyboards doesn't work properly with u-boot. I have one of such. If it's attached booting always stops at u-boot prompt :)

Link to post
Share on other sites
Donate and support the project!

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 wily InRelease
Ign wily InRelease
Ign wily-updates InRelease
Ign wily Release.gpg
Get:1 wily Release.gpg [933 B]
Hit wily-updates Release.gpg 
Ign wily Release
Get:2 wily Release [217 kB]
Hit wily-updates Release                        
Err wily/main armhf Packages                     
  404  Not Found [IP: 80]
Get:3 wily/main armhf Packages [1,386 kB]
Ign wily/main Translation-en                          
Get:4 wily/universe armhf Packages [6,617 kB]        
Get:5 wily/multiverse armhf Packages [118 kB]                                                                                                                                           
Get:6 wily/main Translation-en [837 kB]                                                                                                                                                 
Get:7 wily/multiverse Translation-en [107 kB]                                                                                                                                           
Get:8 wily/universe Translation-en [4,597 kB]                                                                                                                                           
Hit wily-updates/main armhf Packages                                                                                                                                                    
Hit wily-updates/universe armhf Packages                                                                                                                                                
Hit wily-updates/multiverse armhf Packages                                                                                                                                              
Hit wily-updates/main Translation-en                                                                                                                                                    
Hit wily-updates/multiverse Translation-en                                                                                                                                              
Hit wily-updates/universe Translation-en                                                                                                                                                
Fetched 13.9 MB in 1min 10s (198 kB/s)                                                                                                                                                                          
W: Failed to fetch  404  Not Found [IP: 80]

E: Some index files failed to download. They have been ignored, or old ones used instead.

Link to post
Share on other sites

There are two separate problems here. First is network, which is out of my power - real server problem or you were just trying to download it to quickly - files might not be on all servers yet ... at the moment of writing they sure are.


Second is kernel issues. I'll look if I can make a quick fix, otherwise I can suggest you to roll back one kernel version. Use kernel linux-image-sunxi-next v4.3

Link to post
Share on other sites

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 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?

Link to post
Share on other sites

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 …

Link to post
Share on other sites

Supporting a stable system is a hard work but supporting alfa / beta is insane. That's why I am not thinking to move anywhere.


It's simply not possible for a single person nor a small group supporting a system which is full of bugs. The core goal is away from fixing base system - that's what should work out of the box!


This is exactly the case with recent Jessie / systemd problem. I already spent few days and haven't made any progress :/ Next Jessie build will come without it by default. I got enough of it.  :angry: (systemd will remain inside but it will be disabled)


It's much more simple to use sources and build latest version of the stuff you need and leave base system as is ... Just an idea. I am using this for hostapd. None is better than self compiled ...


Regarding R1 and Trusty. I need to check. Uboot is telling which dtb to load.

Link to post
Share on other sites

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?


I just did a fresh installation of latest (4.4) Lamobo R1 Trusty.


Working w/o problem.

Link to post
Share on other sites

Hi Igor,

i read your post ....


This is exactly the case with recent Jessie / systemd problem. I already spent few days and haven't made any progress :/ Next Jessie build will come without it by default.



and tried this:


and afterwards upgraded from 4.2.0 via apt-get update && apt-get upgrade to 4.2.2



Boots && works like a charm ...





Link to post
Share on other sites

Hi there,


the update script doesn't work correctly if lsb-release is sid or testing, so it first treis to load the wrong package infos and then after fixing that tries to install linux-sid-root-next-bananapi.


Solution: update scripts to handle sid or testing as if they were jessie

Link to post
Share on other sites



just upgraded my little homeserver-truck to the next-branch. After dealing with a few problems on my old installation (no aptitude installed, somehow /bin/mountpoint was missing) I got erverything working. The update script uninstalled the old kernel but didn't install a new one, I had to manually install the packages with apt-get. After that everything is working great. Unfortunatly I can't tell why this was happening. When upgradeding to Jessie I accidently upgraded to testing and did a downgrade back to jessie. Perhaps this messed up my installation...


It seems the 4.2 kernel brings some perforamnce improvements, when copying with samba I get 10-15 MB/s more than with the legacy 3.4 kernel.


I've got a "feature request" for the kernel, too. Would you mind adding the usblp module (USB printing support) to the kernel? I'm using my truck as a printserver, too. My Canon Printer seems to have problems with the cups USB implementation and gets stuck sometimes. This is why I always used the old way for this.


Thank you very much for your effort, I appreciate it since my cubietruck is the heart of my little home network ;-)

Link to post
Share on other sites
Hello Igor.
Thank you implementing repository for system update. It is usful.  :)
I was updating my Orange PI from v3.5 to the current kernel, u-boot, etc using
wget -q -O -| bash
It failed saying
W: GPG error: http://apt.armbian.comwheezy Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 93D6889F9F0E78D5
Old kernel was removed by the script but the new one was not installed. So that I installed updates manually.


Is there a way to update rootfw incrementally from v3.5? E.g. current rootfs update deb does not contain utility like a10disp


Another question. Does kernel supports SATA multiport (PMP) out of the box?

cat /boot/config-3.4.109-sun7i |grep PMP says CONFIG_SATA_PMP=y

Or I stilll need to recompile kernel without AHCI_HFLAG_NO_PMP in sata driver?


P.S. I'm trying connect my board to DAS though SATA port (â€-HDD-Enclosure/USB3-0/1040-35-inch-usb30-4bay-hdd-enclosure.html) but didn't succed yet :mellow:

Link to post
Share on other sites

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 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. ;)

Link to post
Share on other sites



Thanks! It's normal that packets and repository are named trusty. I don't have direct support for Willy or any other. Nice to hear that upgrade can be done. For now I don't think to add support for yet another base OS.




PMP support is not compatible with SATA boot. That's the reason why it's not enabled by default. Perhaps this can be fixed with driver fixing and setting a proper kernel parameter but I haven't got this far yet. The errors you are describing are most likely network related. I had some server troubles in that time so it could be that. I checked this moment and keys are found and downloaded w/o error. Regarding rootfs upgrade ... some things doesn't go into a packages since I treat them as an external addon. I can fix this in once ... until then you can try to compile it by yourself.

Link to post
Share on other sites


Thank you. I have recently upgraded my Debian wheezy v3.5 to the latest Debian wheezy desktop v4.5 following lib scripts. And I have also manage to complile legacy kernel with PMP and all external tools. 

I have notice the following

- apt-get install didn't install all required packages (PAKETKI) from and from and  :mellow: so I had to install them by myself

BOOTLOADER="" works faster then BOOTLOADER="git://" in Russia. I had no big delay using http. Previously I was pushed by timeout.


My Agestar DAS is able to see the HDD now. But what I do not understand now is how the default 3.4.109 kernel from linux-image-sun7i_4.51_armhf.deb sees the HDD in DAS now (I have installed kernel upgrade debs to perform some check on your "golden" kernel). ?!

root@orangepi:~# ls /boot/ -l
drwxr-xr-x 2 root root    4096 Окт 27 14:29 bin
-rw-r--r-- 1 root root    1937 Окт 27 14:31 boot.cmd
-rw-r--r-- 1 root root    2009 Окт 27 14:31 boot.scr
-rw-r--r-- 1 root root   97046 Окт 14 21:33 config-3.4.109-sun7i
-rw-r--r-- 1 root root 2452596 Окт 26 22:03 initrd.img-3.4.109-sun7i
lrwxrwxrwx 1 root root      22 Окт 15 22:20 script.bin -> /boot/bin/orangepi.bin
-rw-r--r-- 1 root root 2004410 Окт 14 21:33
-rwxr-xr-x 1 root root 5605936 Окт 14 21:33 vmlinuz-3.4.109-sun7i
-rwxr-xr-x 1 root root 5606464 Окт 22 17:40 ~vmlinuz-3.4.109-sun7i.pmp
lrwxrwxrwx 1 root root      27 Окт 26 22:03 zImage -> /boot/vmlinuz-3.4.109-sun7i

root@orangepi:~# dpkg -l | grep linux-
ii  linux-firmware-image-sun7i            4.51                               armhf        Linux kernel firmware, version 3.4.109-sun7i
ii  linux-headers-sun7i                   4.51                               armhf        Linux kernel headers for 3.4.109-sun7i on armhf
rc  linux-image-3.4.107-orangepi          1.2                                armhf        Linux kernel, version 3.4.107-orangepi
ii  linux-image-sun7i                     4.51                               armhf        Linux kernel, version 3.4.109-sun7i
ii  linux-libc-dev:armhf                  3.2.68-1+deb7u5                    armhf        Linux support headers for userspace development
ii  linux-u-boot-orangepi                 4.5                                armhf        Uboot loader 2015.07.
ii  linux-wheezy-root-orangepi            4.5                                armhf        Various root file system tweaks for ARM boards

root@orangepi:~# dpkg -L linux-image-3.4.107-orangepi
Package `linux-image-3.4.107-orangepi' does not contain any files (!)

root@orangepi:~# parted /dev/sdc print
Model: ATA WDC WD30EFRX-68E (scsi)
Disk /dev/sdc: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      4194kB  3001GB  3001GB  ext4         primary
Model: ATA WDC WD30EFRX-68E (scsi)
Disk /dev/sdc: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Link to post
Share on other sites
Okay, as a beginner my update procedere went wrong.
What i did:
Update Kernel from 3.4.105 -> Vanilla 4.2.3
I use the update script:
wget -q -O -| bash
After update i got a successfull message, look at boot.script and reboot.
Okay. But after a reload nothing happened.
I switch a HDMI cable to a monitor-> NOTHING, just BLACK
My system is:
  • Cubietruck
  • boot directory on SD
  • root and everything else on SSD
I pick the SD and look into the boot.cmd, but the root info is the same as in my backup.
What can i do?

This was the content of my SD card before update:



And this is the content after update:



And here is the content of boot.cmd (before and after)

setenv bootargs console=tty1 root=/dev/sda1 rootwait sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 disp.screen0_output_mode=EDID:1280x720p60 panic=10 consoleblank=0
ext4load mmc 0 0x43000000 /boot/cubietruck.bin
ext4load mmc 0 0x48000000 /boot/vmlinuz-3.4.105-cubieboard
bootz 0x48000000
setenv bootargs console=tty1 root=/dev/sda1 rootwait rootfstype=ext4 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1
# Boot loader script to boot with different boot methods for old and new kernel
if ext4load mmc 0 0x00000000 /boot/.next || fatload mmc 0 0x00000000 .next
# sunxi mainline kernel
ext4load mmc 0 0x49000000 /boot/dtb/${fdtfile} || fatload mmc 0 0x49000000 /dtb/${fdtfile}
ext4load mmc 0 0x46000000 /boot/zImage || fatload mmc 0 0x46000000 zImage
env set fdt_high ffffffff
bootz 0x46000000 - 0x49000000
# sunxi android kernel
ext4load mmc 0 0x43000000 /boot/script.bin || fatload mmc 0 0x43000000 script.bin
ext4load mmc 0 0x48000000 /boot/zImage || fatload mmc 0 0x48000000 zImage
bootz 0x48000000
# Recompile with:
# mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr 

Link to post
Share on other sites

Since you had your system already on HDD, probably /dev/sda1, what is the content there? 


I see upgrade is not working properly in this scenario. 


What you can do? First unbrick SD card by installing kernel, DTB, firmware, headers to it.


Also set boot to SD

... setenv bootargs console=tty1 root=/dev/mmcblk0p1  ...

Than check if you have all this already on your HDD drive. If not, manually copy kernel files /boot /lib/modules /usr/src (if you need headers) ... 


than set boot back to /dev/sda1 and boot.

Link to post
Share on other sites

While still being on 3.4.108 with my Cubietruck I was wondering, why I got several u-boot updates, but none for the kernel, so I came across this post, realising that


is no longer supported. Thus I followed the hint and did a

apt-get remove linux-firmware-image-cubietruck linux-headers-cubietruck linux-image-cubietruck

followed by a

apt-get install linux-image-sun4i linux-headers-sun4i linux-firmware-image-sun4i linux-$(lsb_release -cs)-root-cubietruck

However, that didn't work.


I now see on your page that you're mentioning 7i


for Allwinner A20 which is conflicting with the info 4i given here! I'll try the latter now, but I think either page needs to be updated!?

Link to post
Share on other sites

PS: I think when using "4i" yesterday I got a 3.4.110 kernel, while upgrading today "just" delivers

drwxr-xr-x  5 root root    4096 Nov 26 13:46 .
drwxr-xr-x 22 root root    4096 Apr 30  2015 ..
drwxr-xr-x  2 root root    4096 May 24  2015 bin
-rwxr-xr-x  1 root root 6220856 May 21  2015 boot.bmp
-rw-r--r--  1 root root    1476 May 21  2015 boot.cmd
-rw-r--r--  1 root root    1548 May 21  2015 boot.scr
-rw-r--r--  1 root root   97046 Oct 14 20:33 config-3.4.109-sun7i
drwxr-xr-x  2 root root    4096 May 21  2015 dtb
drwxr-xr-x  2 root root    4096 May 24  2015 KernelUpdates
lrwxrwxrwx  1 root root      24 May 21  2015 script.bin -> /boot/bin/cubietruck.bin
-rw-r--r--  1 root root 2004410 Oct 14 20:33
-rwxr-xr-x  1 root root 5605936 Oct 14 20:33 vmlinuz-3.4.109-sun7i
lrwxrwxrwx  1 root root      27 Nov 26 13:42 zImage -> /boot/vmlinuz-3.4.109-sun7i

while your News tells me


What’s new

v4.6 / 24.11.2015 Update only (apt-get update && apt-get upgrade)

– Legacy kernel for Allwinner based boards upgraded to 3.4.110


(don't read as complaing - appreciate your effort!)

Link to post
Share on other sites

First, you choose a wrong upgrade ... Cubietruck is sun7i not sun4i .. and which you figured out and solved properly.


The other problem is in my repository ( and I haven't got a chance to fix it. Sun7i kernel doesn't download proper update: version (4.6) but (4.51). The case here is that v4.51 was a quick fix only for sun7i, not for other boards. The problem is Debian package numbering which I haven't pay enough attention too. When it will be fixed it will be fixed the standard apt-get update way.


Thanks for bringing up and sorry for this confusion.

Link to post
Share on other sites



first, many thanks for your work! I highly apprechiate your effort.


I tried to upgrade from 3.4.105 to 3.4.110 on a Cubietruck (boot from NAND, System on SSD) via update script. The script finished with no recognizable error and everything seems to be fine. But after the reboot kernel 3.4.105 is still active.


I am willing to learn. Any hint apprchiated.


Best regards,



Link to post
Share on other sites
  • Igor unpinned this topic
This topic is now closed to further replies.