Igor Posted October 2, 2015 Author Posted October 2, 2015 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 1
typingArtist Posted October 2, 2015 Posted October 2, 2015 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.
Igor Posted October 2, 2015 Author Posted October 2, 2015 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 http://askubuntu.com/questions/138284/how-to-downgrade-a-package-via-apt-get
typingArtist Posted October 3, 2015 Posted October 3, 2015 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?
typingArtist Posted October 4, 2015 Posted October 4, 2015 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 …
Igor Posted October 4, 2015 Author Posted October 4, 2015 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. (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.
Igor Posted October 5, 2015 Author Posted October 5, 2015 [ 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 There was a little too much debug. Fixed. https://github.com/igorpecovnik/lib/commit/58dee9986c0d9e76d8b3e9dc840f51d0c21b4bad
Igor Posted October 5, 2015 Author Posted October 5, 2015 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.
Andreas Mueller Posted October 7, 2015 Posted October 7, 2015 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: http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation and afterwards upgraded from 4.2.0 via apt-get update && apt-get upgrade to 4.2.2 Boots && works like a charm ... Regards, A.
xnyle Posted October 9, 2015 Posted October 9, 2015 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
Boostar Posted October 18, 2015 Posted October 18, 2015 Hi, 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 ;-)
OPUser Posted October 18, 2015 Posted October 18, 2015 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 - http://upgrade.armbian.com| 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 (http://agestar.com/en/Products/3-5â€-HDD-Enclosure/USB3-0/1040-35-inch-usb30-4bay-hdd-enclosure.html) but didn't succed yet
typingArtist Posted October 29, 2015 Posted October 29, 2015 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.
Igor Posted November 1, 2015 Author Posted November 1, 2015 @typingArtist 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. @OPUser 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.
OPUser Posted November 2, 2015 Posted November 2, 2015 @Igor 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 main.sh and from deboostrap.sh and desktop.sh so I had to install them by myself - BOOTLOADER="http://git.denx.de/u-boot.git" works faster then BOOTLOADER="git://git.denx.de/u-boot.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 System.map-3.4.109-sun7i -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
HansDampf Posted November 10, 2015 Posted November 10, 2015 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 - http://upgrade.armbian.com| 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 hdmi.audio=EDID:0 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 hdmi.audio=EDID:0 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 then # 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 #-------------------------------------------------------------------------------------------------------------------------------- else # 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 #-------------------------------------------------------------------------------------------------------------------------------- fi # Recompile with: # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
Igor Posted November 11, 2015 Author Posted November 11, 2015 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.
HansDampf Posted November 11, 2015 Posted November 11, 2015 Thank you for your great achievement! Without so much input I would my small home server do not get to run. I now have the system reinstalled, copy my backup and within minutes again a running system. Everything else exceeds my competence ;-)
Igor Posted November 12, 2015 Author Posted November 12, 2015 Thanks! OK, that's an option too. But I need to fix script bugs in any case
rumburak Posted November 20, 2015 Posted November 20, 2015 udoo-quad [ error ] Unsupported hw Linux udoo 4.2.3-udoo #1 SMP Sun Oct 11 21:56:52 CEST 2015 armv7l GNU/Linux
Igor Posted November 20, 2015 Author Posted November 20, 2015 Yes, like it said For those boards its not that critical because they are mostly already shipped with proper packages, but I'll eventually add this too.
odoll Posted November 26, 2015 Posted November 26, 2015 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 linux-firmware-image-cubietruck linux-headers-cubietruck linux-image-cubietruck (linux-u-boot-cubietruck) 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 http://www.armbian.com/kernel/ that you're mentioning 7i linux-image-sun7i linux-headers-sun7i linux-firmware-image-sun7i 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!?
odoll Posted November 26, 2015 Posted November 26, 2015 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 System.map-3.4.109-sun7i -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 newv4.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!)
Igor Posted November 27, 2015 Author Posted November 27, 2015 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 (apt.armbian.com) 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.
odoll Posted November 27, 2015 Posted November 27, 2015 Thanks for bringing up and sorry for this confusion. np, we all have to thank you! - but pls don't forget to fix the 4i vs 7i typos in your first post of this thread :-) 1
odoll Posted December 1, 2015 Posted December 1, 2015 Thx (3.4.110 came in yesterday, while doing an upgrade ) OT here, but is the cubietruck u-boot 4.70 version able to work in / replace the stock version in NAND?
Igor Posted December 1, 2015 Author Posted December 1, 2015 Not sure about U-boot NAND support ... didn't try.
Markymark Posted December 18, 2015 Posted December 18, 2015 Igor, 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, Mark
Toast Posted December 19, 2015 Posted December 19, 2015 @Igor i see you finally got around to making a repo gonna try it out for my cubieboard2, been a bit preoccupied with OSMC and support work but im glad that your work has progressed
Recommended Posts