EtlARM Posted February 13, 2016 Posted February 13, 2016 When doing apt-upgrade to get the latest linux-jessie-root-cubieboard2, it fails with this error message: # apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: linux-jessie-root-cubieboard2 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 3 not fully installed or removed. Need to get 0 B/1.810 kB of archives. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] Y (Reading database ... 51863 files and directories currently installed.) Preparing to unpack .../linux-jessie-root-cubieboard2_5.00_armhf.deb ... Unpacking linux-jessie-root-cubieboard2 (5.00) over (4.81) ... dpkg: error processing archive /var/cache/apt/archives/linux-jessie-root-cubieboard2_5.00_armhf.deb (--unpack): unable to make backup link of `./boot/bin/cubieboard.bin' before installing new version: Operation not permitted dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Processing triggers for systemd (215-17+deb8u3) ... Errors were encountered while processing: /var/cache/apt/archives/linux-jessie-root-cubieboard2_5.00_armhf.deb E: Sub-process /usr/bin/dpkg returned an error code (1) When /boot is on NAND it is not possible to link files there, maybe that is the problem? 1
Igor Posted February 13, 2016 Posted February 13, 2016 Workaround: manually remove dpkg -r linux-jessie-root-cubieboard2 and install apt-get install linux-jessie-root-cubieboard2 2
amhairghin Posted February 14, 2016 Posted February 14, 2016 Same error with `linux-jessie-root-cubietruck`. Manually workaround works like a charm. BUT THE SYSTEM DEAD AFTER REBOOT!!!! # cd /tmp # apt-get download linux-jessie-root-cubietruck # dpkg -r linux-jessie-root-cubietruck # dpkg -i linux-jessie-root-cubietruck_5.00_armhf.deb # rm linux-jessie-root-cubietruck_5.00_armhf.deb
EtlARM Posted February 15, 2016 Author Posted February 15, 2016 "Good" to hear other have the same problem... after the workaround went fine on my CubieBoard2 I bricked my production system CubieTruck the same way, you described. The workaround trick went fine on the CubieTruck. But after reboot the system does not start anymore: red power LED near power jack is lit network LEDs show some activity SATA disk stays off front LEDs stay off VGA has no signal no other reaction observable I had similar NAND boot problems in the past, so I assumed it is the same case again. The last time it was sufficient to leave the board unpowered for some hours (discharging battery a bit), but this time nothing helped. So I migrated my complete system back to SDCARD, and it is working like before. After thinking a night about the problem, it might be sufficient to manually update all kernel files on NAND1. I did not test that. Do you have a serial cable to watch the boot output? (I don't have one.) 1
Igor Posted February 15, 2016 Posted February 15, 2016 I am about to do close inspection ... gimme some time.
Igor Posted February 15, 2016 Posted February 15, 2016 Temporally workaround if you can't boot from NAND. 1. Boot from SD card 2. Edit boot.cmd and change root=/dev/nand2 + recompile 3. Reboot with SD card inserted
Igor Posted February 15, 2016 Posted February 15, 2016 I made a test on a Cubietruck NAND install which had some old build and upgrade was done successfully with this workaround: dpkg -r linux-jessie-root-cubietruck and install apt-get install linux-jessie-root-cubietruck Your NAND1 must be mounted under /boot otherwise upgrade can't be done properly. In another words - if you were changing core system settings, upgrading might not work.
EtlARM Posted February 15, 2016 Author Posted February 15, 2016 I did not change system settings, except minor modifications to script.bin (VGA mode and LEDs). NAND1 was mounted as /boot (and NAND2 as /). Probably it was bad luck or a weak power supply (I doubt that, as I also have the battery connected). But as I migrated to SD card anyway, I will stay there for the near future. Maybe I will find some time during the next days to compare the kernel files from NAND1 and SD card. But as this is my "production" system, I would like to avoid additional down time.
Igor Posted February 15, 2016 Posted February 15, 2016 If your system don't (NAND) boot than I would need to see serial console boot log otherwise we are guessing. Even with log sometimes we don't see a problem. I'll fix this problem that workaround won't be needed and do few more tests too see if I could crash the system.
EtlARM Posted February 15, 2016 Author Posted February 15, 2016 Any recommendation for buying a serial cable to get that console boot log?
vlad Posted February 16, 2016 Posted February 16, 2016 get something based on ftdi devices they are know to work across all platform windows/linux/osx but make sure you get a genuine device since ftdi are again abusing, at least on windows operating systems, that updates system and bricks non genuine ftdi chips ebay has hundreds of listings for ft232 starting at around $2.2 only problem it could take a while to arrive. Based on where you live check out sparkfun or adafruit or pololu - they are US based and they will sell you a genuine part but it will cost like 5-6x or more than the ebay listings if you are EU based check olimex or exp-tech.de 1
Igor Posted February 16, 2016 Posted February 16, 2016 http://www.ebay.com/itm/6Pin-USB-2-0-to-TTL-UART-Module-Serial-Converter-CP2102-STC-Replace-Ft232-Module-/400565980256?hash=item5d4397cc60 + good quality + cheap + trusted seller + fast delivery 1
zador.blood.stained Posted February 16, 2016 Posted February 16, 2016 Any recommendation for buying a serial cable to get that console boot log? Any adapter that has 3.3v-5v jumper or switch will do, if you don't want to implement level shifting by yourself PL2303 based should be good too.
jobenvil Posted February 16, 2016 Posted February 16, 2016 After Upgrade "armbian ...| bash" my system banana pro was broken as well. rootfs are in SATA disk. My questions: Which is the official installation procedure of the *.deb packages (kernel, boot, firmware, dtbs, etc) that were compiled with the ./compile.sh script? I could not find anything. And which one *deb files are mandatory in top of the prebuilt release? For example, when I compiled the 3.10.96 for odroidxu4 on the top of a prebuilt 3.10.94 I didn't know certanly which of them were necessary and which not. For example the *.deb of DTBs was giving error because the original file could not be copied, but it looks like that it works nice now. Thanks in advance
zador.blood.stained Posted February 16, 2016 Posted February 16, 2016 "Upgrade script" was created mainly for older distributions that didn't have Armbian apt repository set up. For more or less fresh versions upgrade should be done with apt (apt-get update && apt-get upgrade). Sometimes though you may need to additionally tweak something manually here or there (like modifying u-boot script or installing fake-hwclock package). For installing self-compiled stuff - kernel and DTB (if kernel requires it) should be installed always in pair; updating headers and firmware may be necessary if you use them (i.e. self-compiled drivers of Wi-Fi modules that require firmware). Updating u-boot is generally not needed unless there were device-specific fixes made for it. DTB deb package may give error with FAT /boot partition (i.e. with rootfs on NAND or devices with older u-boot), deleting old package and removing files in /boot manually should solve this issue. 1
EtlARM Posted February 16, 2016 Author Posted February 16, 2016 Any adapter that has 3.3v-5v jumper or switch will do, if you don't want to implement level shifting by yourself PL2303 based should be good too. I ordered this one: Amazon PL2303HX USB to TTL Probably shipped from China, so further details from my side will be earliest next month...
jobenvil Posted February 16, 2016 Posted February 16, 2016 "Upgrade script" was created mainly for older distributions that didn't have Armbian apt repository set up. For more or less fresh versions upgrade should be done with apt (apt-get update && apt-get upgrade). Sometimes though you may need to additionally tweak something manually here or there (like modifying u-boot script or installing fake-hwclock package). For installing self-compiled stuff - kernel and DTB (if kernel requires it) should be installed always in pair; updating headers and firmware may be necessary if you use them (i.e. self-compiled drivers of Wi-Fi modules that require firmware). Updating u-boot is generally not needed unless there were device-specific fixes made for it. DTB deb package may give error with FAT /boot partition (i.e. with rootfs on NAND or devices with older u-boot), deleting old package and removing files in /boot manually should solve this issue. I was sure, that you will answer, thank you. I try to revert to old kernels to get the banana pro working again (but not right now). Yes, I realized about the armbian repository using the usual apt-get upgrade in new armbian builts. The point is that I'm using the Debian testing packages and therefore I have #commented the armbian repository list, therefore not getting these automatically. Probably there is another smarter solution to cohexist both of them, but I'm not aware and because it is so easy to compile own kernels now, due to your efforts on compile script, I don't care anymore that I have #commented armbian repository. However will be nice if some aditional infos could be pushed on the docus, focushing on people that is installing kernel on top of igors prebuilt images and how to revert to old kernels. I see that this was commented sometimes here or there in the Forum. Yes, indeed, you are totally right mentioning the /boot problem.
zador.blood.stained Posted February 16, 2016 Posted February 16, 2016 The point is that I'm using the Debian testing packages and therefore I have #commented the armbian repository list, therefore not getting these automatically. Probably there is another smarter solution to cohexist both of them, but I'm not aware and because it is so easy to compile own kernels now, due to your efforts on compile script, I don't care anymore that I have #commented armbian repository. However will be nice if some aditional infos could be pushed on the docus, focushing on people that is installing kernel on top of igors prebuilt images and how to revert to old kernels. I see that this was commented sometimes here or there in the Forum. I'm using Debian testing too with commented Armbian repository, but it should work with jessie-specific config since both jessie and stretch are systemd-based. ➜ ~ % cat /etc/apt/sources.list.d/armbian.list deb http://apt.armbian.com jessie main Downgrading kernel, u-boot and other packages should be possible by manually downloading and installing packages from apt repository, or by specifying package version for apt-get manually (apt-get install <package>=<version>) You can check available versions using i.e. apt-cache madison linux-image-next-sunxi linux-image-next-sunxi | 5.00 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.81 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.70 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.6 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.5 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.4 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.3 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.2 | http://apt.armbian.com jessie/main armhf Packages BTW, if you are experiencing SATA issues on Banana Pro, please check this topic, it might be u-boot related and may be already fixed in new u-boot release. 1
jobenvil Posted February 16, 2016 Posted February 16, 2016 I'm using Debian testing too with commented Armbian repository, but it should work with jessie-specific config since both jessie and stretch are systemd-based. ➜ ~ % cat /etc/apt/sources.list.d/armbian.list deb http://apt.armbian.com jessie main Downgrading kernel, u-boot and other packages should be possible by manually downloading and installing packages from apt repository, or by specifying package version for apt-get manually (apt-get install <package>=<version>) Youcan check available versions using i.e. apt-cache madison linux-image-next-sunxi linux-image-next-sunxi | 5.00 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.81 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.70 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.6 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.5 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.4 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.3 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.2 | http://apt.armbian.com jessie/main armhf Packages BTW, if you are experiencing SATA issues on Banana Pro, please check this topic, it might be u-boot related and may be already fixed in new u-boot release. thanks!!! very interesting both tips and where the armbian repository is placed on.
Don Pedro Posted February 19, 2016 Posted February 19, 2016 As an alternative, if you want/need a PL2303 based converter that's also operable on latest windows system I could recommend this here: http://www.amazon.de/PL2303TA-RS232-Konverter-Serial-Cable/dp/B00T60QTUK/ref=sr_1_19?ie=UTF8&qid=1455911912&sr=8-19&keywords=pl2303 This has a PL2303TA chip inside, means it will work with Win 8 and 10 out of the box (i. e. with the drivers that come with windows). It is 3.3V (but has no 5V switch), so it can operate savely on a cubie or raspberry. The cable coloring the supplier states in the link is correct (at least for mine it was). The only disadvantage is that it's beeing shipped directly from China, so it may be you'll have to wait 1 or even 2 months for delivery (depends on how fast it will pass the toll). BTW: Good to hear in time that enforcing an update might brick the installation, I was already tempted to do it, too. So I will wait for what Igor's research will yield. I'm also using my cubie as a production system (Backup, Owncloud, AP), so of course I'm not keen on bricking it! ;-) This is a bit OT, I know, nevertheless: Syncthing plus dirvish plus samba (with RO shares) make up an open-source-only, fully automated, versatile and almost maintenance-free backup system, where even unexperienced (Windows-only) users can access their backups themselves and without the risk of any ransomware gaining write access to the backups. This is highly recommended! HTH Don
Don Pedro Posted February 27, 2016 Posted February 27, 2016 Hi, I ran into the same problem "unable to make backup link of `./boot/bin/cubieboard.bin' before installing new version: Operation not permitted" when doing a regular apt-get update/upgrade. After reading this thread and getting aware it may cause problems when booting from NAND I did not install Igor's workaround. Nevertheless I had to realize my Cubie is bricked after a reboot. I guess this is due to some other updates apt-get spilled on the NAND during the update that triggered the error. Igor, is there any news why this break NAND booting and how to overcome this? If this is of any help I attach the console output of my cubie here. Maybe this eases determining the reason why things broke: HELLO! BOOT0 is starting!boot0 version : 2.0.0â–’read dram para.dram driver version: 1.15dram size =2048MB0xffffffffsuper_standby_flag = 0Succeed in opening nand flash.block from 2 to 6deal block 2Succeed in reading Boot1 file head.The size of Boot1 is 0x00068000.The file stored in 0x00000000 of block 2 is perfect.Check is correct.Ready to disable icache.Succeed in loading Boot1.Jump to Boot1.[ 0.148] boot1 version : 2.0.0[ 0.148] script installed early ok[ 0.149] pmu type = 3[ 0.254] bat vol = 4504 mv[ 0.268] axi:ahb:apb=4:2:2[ 0.268] set dcdc2=1450mv, clock=912M successed[ 0.270] key[ 0.283] no key found[ 0.283] flash init start[ 0.283] NB1 : enter NFB_Init[ 0.286] NB1 : enter phy init[ 0.289] [NAND] nand driver( version: 0x0x00000002, 0x0x00000012, data: 0x20130627[ 0.298] get the good blk ratio from hwscan : 944[ 0.302] NB1 : nand phy init ok[ 3.177] _RepairLogBlkTbl start[ 3.180] Log Block Index 0x00000000, LogicBlockNum: 0x0000032a, LogBlockType: 0x00000000[ 3.183] log0: 0x000000a2, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.189] datablock: 0x000000b3, lastusedpage: 0x00000010[ 3.198] Log Block Index 0x00000001, LogicBlockNum: 0x00000346, LogBlockType: 0x00000000[ 3.204] log0: 0x0000019b, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.210] datablock: 0x00000232, lastusedpage: 0x00000002[ 3.218] Log Block Index 0x00000002, LogicBlockNum: 0x0000020c, LogBlockType: 0x00000000[ 3.224] log0: 0x0000023b, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.231] datablock: 0x000000a8, lastusedpage: 0x00000006[ 3.239] Log Block Index 0x00000003, LogicBlockNum: 0x00000108, LogBlockType: 0x00000000[ 3.245] log0: 0x00000388, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.251] datablock: 0x00000141, lastusedpage: 0x00000012[ 3.260] Log Block Index 0x00000004, LogicBlockNum: 0x00000318, LogBlockType: 0x00000000[ 3.265] log0: 0x0000013c, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.272] datablock: 0x0000042c, lastusedpage: 0x00000002[ 3.280] Log Block Index 0x00000005, LogicBlockNum: 0x0000007d, LogBlockType: 0x00000000[ 3.286] log0: 0x00000110, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.293] datablock: 0x0000047f, lastusedpage: 0x00000006[ 3.300] Log Block Index 0x00000006, LogicBlockNum: 0x00000308, LogBlockType: 0x00000000[ 3.307] log0: 0x000004b9, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.313] datablock: 0x000001a0, lastusedpage: 0x000001a4[ 3.321] Log Block Index 0x00000007, LogicBlockNum: 0x0000030c, LogBlockType: 0x00000000[ 3.327] log0: 0x000001bf, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.334] datablock: 0x0000051b, lastusedpage: 0x00000188[ 3.342] Log Block Index 0x00000008, LogicBlockNum: 0x0000007e, LogBlockType: 0x00000000[ 3.348] log0: 0x0000052b, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.354] datablock: 0x000000e9, lastusedpage: 0x00000008[ 3.362] Log Block Index 0x00000009, LogicBlockNum: 0x00000327, LogBlockType: 0x00000000[ 3.369] log0: 0x0000005f, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.375] datablock: 0x0000056a, lastusedpage: 0x000000b2[ 3.383] Log Block Index 0x0000000a, LogicBlockNum: 0x00000208, LogBlockType: 0x00000000[ 3.389] log0: 0x000001aa, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.396] datablock: 0x00000570, lastusedpage: 0x00000068[ 3.404] Log Block Index 0x0000000b, LogicBlockNum: 0x00000328, LogBlockType: 0x00000000[ 3.410] log0: 0x0000051f, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.416] datablock: 0x000005c7, lastusedpage: 0x0000009e[ 3.425] Log Block Index 0x0000000c, LogicBlockNum: 0x0000010b, LogBlockType: 0x00000000[ 3.430] log0: 0x0000049f, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.437] datablock: 0x000005fd, lastusedpage: 0x00000008[ 3.445] Log Block Index 0x0000000d, LogicBlockNum: 0x0000007c, LogBlockType: 0x00000000[ 3.451] log0: 0x0000068c, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.458] datablock: 0x00000657, lastusedpage: 0x000000f2[ 3.466] Log Block Index 0x0000000e, LogicBlockNum: 0x0000007b, LogBlockType: 0x00000000[ 3.472] log0: 0x0000069c, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.478] datablock: 0x00000683, lastusedpage: 0x000000d8[ 3.486] Log Block Index 0x0000000f, LogicBlockNum: 0x00000008, LogBlockType: 0x00000000[ 3.492] log0: 0x00000703, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.499] datablock: 0x000007f4, lastusedpage: 0x00000028[ 3.507] Log Block Index 0x00000000, LogicBlockNum: 0x0000007e, LogBlockType: 0x00000000[ 3.513] log0: 0x000000ef, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.519] datablock: 0x000002b8, lastusedpage: 0x00000002[ 3.527] Log Block Index 0x00000001, LogicBlockNum: 0x00000052, LogBlockType: 0x00000000[ 3.534] log0: 0x000002bc, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.540] datablock: 0x0000022e, lastusedpage: 0x000000ea[ 3.548] Log Block Index 0x00000002, LogicBlockNum: 0x000000c9, LogBlockType: 0x00000000[ 3.554] log0: 0x00000233, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.561] datablock: 0x000002ca, lastusedpage: 0x00000078[ 3.569] Log Block Index 0x00000003, LogicBlockNum: 0x00000162, LogBlockType: 0x00000000[ 3.575] log0: 0x000002fa, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.581] datablock: 0x0000004e, lastusedpage: 0x0000004a[ 3.590] Log Block Index 0x00000004, LogicBlockNum: 0x00000083, LogBlockType: 0x00000000[ 3.595] log0: 0x00000109, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.602] datablock: 0x00000314, lastusedpage: 0x00000002[ 3.610] Log Block Index 0x00000005, LogicBlockNum: 0x00000063, LogBlockType: 0x00000000[ 3.616] log0: 0x000002db, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.623] datablock: 0x000003d2, lastusedpage: 0x00000004[ 3.631] Log Block Index 0x00000006, LogicBlockNum: 0x00000056, LogBlockType: 0x00000000[ 3.637] log0: 0x000003ea, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.643] datablock: 0x0000026c, lastusedpage: 0x00000016[ 3.651] Log Block Index 0x00000007, LogicBlockNum: 0x00000152, LogBlockType: 0x00000000[ 3.657] log0: 0x00000259, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.664] datablock: 0x000003fc, lastusedpage: 0x0000003a[ 3.672] Log Block Index 0x00000008, LogicBlockNum: 0x00000062, LogBlockType: 0x00000000[ 3.678] log0: 0x00000428, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.684] datablock: 0x0000021a, lastusedpage: 0x00000002[ 3.693] Log Block Index 0x00000009, LogicBlockNum: 0x00000156, LogBlockType: 0x00000000[ 3.699] log0: 0x00000406, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.705] datablock: 0x00000495, lastusedpage: 0x00000008[ 3.713] Log Block Index 0x0000000a, LogicBlockNum: 0x00000103, LogBlockType: 0x00000000[ 3.719] log0: 0x000003cc, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.726] datablock: 0x00000499, lastusedpage: 0x000001a2[ 3.733] Log Block Index 0x0000000b, LogicBlockNum: 0x000000ce, LogBlockType: 0x00000000[ 3.740] log0: 0x000004cd, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.746] datablock: 0x00000159, lastusedpage: 0x00000176[ 3.754] Log Block Index 0x0000000c, LogicBlockNum: 0x00000252, LogBlockType: 0x00000000[ 3.760] log0: 0x00000359, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.767] datablock: 0x00000653, lastusedpage: 0x0000000a[ 3.775] Log Block Index 0x0000000d, LogicBlockNum: 0x00000074, LogBlockType: 0x00000000[ 3.781] log0: 0x00000161, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.788] datablock: 0x00000679, lastusedpage: 0x00000002[ 3.796] Log Block Index 0x0000000e, LogicBlockNum: 0x00000076, LogBlockType: 0x00000000[ 3.802] log0: 0x000006a3, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.808] datablock: 0x0000045e, lastusedpage: 0x00000002[ 3.816] Log Block Index 0x0000000f, LogicBlockNum: 0x00000081, LogBlockType: 0x00000000[ 3.822] log0: 0x000007be, Log1: 0x0000ffff, WriteIndex: 0x00000000[ 3.829] datablock: 0x000004c5, lastusedpage: 0x0000000c[ 3.834] _RepairLogBlkTbl end[ 3.851] NB1 : init ok[ 3.851] flash init finish[ 3.852] fs init ok[ 3.854] fattype FAT16[ 3.856] fs mount ok[ 3.859] nand good_block_ratio=944[ 3.862] storage_type=0[ 3.873] 0[ 3.874] set pc[ 3.874] usbdc_vol = 4000, usbdc_cur = 0[ 3.875] usbpc_vol = 4200, usbpc_cur = 0[ 3.880] init to usb pc[ 3.883] set pc[ 3.898] can't find c:\drv_de.drv[ 3.898] ERR: wBoot_driver_install display driver failed[ 3.902] key value = 0[ 3.905] recovery key high 40, low 4[ 3.909] show pic finish[ 3.911] load kernel start[ 3.933] load kernel successed[ 3.933] start address = 0x4a000000[ 3.934] ERR: display driver not open yet[ 3.939] ERR: display driver not open yet[ 3.943] power exit detectU-Boot 2011.09-rc1-00000-gf75abad-dirty (Oct 21 2013 - 18:44:22) Allwinner TechnologyCPU: SUNXI FamilyBoard: A20-CubietruckDRAM: 2 GiBNAND: NB1 : enter NFB_Init[NAND] nand driver( version: 0x2, 0x12, data: 20130526[NAND] set nand_good_block_ratio 944NB1 : nand phy init okNB1 : init ok2816 MiBUsing default environmentIn: serialOut: serialErr: serial--------fastboot partitions---------total partitions:2--name- -start- -size-bootloader : 10000 10000rootfs : 20000 560000-----------------------------------no misc partition is foundHit any key to stop autoboot: 0Failed to mount ext2 filesystem...** Unrecognized filesystem type **reading /uEnv.txt293 bytes read## Warning: defaulting to text formatFailed to mount ext2 filesystem...** Unrecognized filesystem type **reading /script.bin46360 bytes readFailed to mount ext2 filesystem...** Unrecognized filesystem type **reading uImage** Unable to read "uImage" from nand 0:0 **sun7i# Remarkable things in the output: Dunno what this "_RepairLogBlkTbl start" ... "_RepairLogBlkTbl end" section should tell me. It is being output at every boot try, maybe this is normal. There's a really strange line at 3.898:"can't find c:\drv_de.drvERR: wBoot_driver_install display driver failed"WTF is it searching for a DOS path??? Then there's a complaint about a missing misc partition and several entries complaining about mount failures for an unrecognized filesystem type. Then it finally fails to read the uImage and of course and this brings the boot process to a halt. The Cubie is still alive however, I end up on a promt with limited functionality, a "?" gives a list of commands but this seems to be all very low level (no ls but fatls, ext2ls, etc. with strange syntax, e.g. "usage: fatls <interface> <dev[:part]> [directory]"). I managed to do a "fatls nand 0:0", this gives me 118912 boot.axf 106 boot.ini linux/ 512 magic.bin 293 uenv.txt 46360 script.bin 2006492 system.map-3.4.110-sun7i 5608120 vmlinuz-3.4.110-sun7i bin/ 96449 config-3.4.110-sun7i8 file(s), 2 dir(s) As you can easily see there ain't no such thing as a "uImage" (while the other files needed are there). So now the questions are: How come something has killed uImage? How can I bring it back there? I dont want to reinstall the Cubie, it's a lot of work and I made a lot of settings specific to my needs. How to avoid this will happen again? So, does this help fixing the problem? Hopefully there will be a quick solution... Regards Don
Don Pedro Posted February 27, 2016 Posted February 27, 2016 One additinal remark I forgot to mention, dunno if this is relevant for the problem: I'm using a Cubie with 16GB Nand (instead of the standard 8GB). Regards Don
Igor Posted February 28, 2016 Posted February 28, 2016 Bootloader which we use for NAND boot process is as is. Currently the only one which allows us boot this way and it was designed for Android. That's the reason of strange messages during boot. What you need to do is - boot from SD card and convert vmlinuz-3.4.110-sun7i to uImage. (they are on /dev/nand1) The reason why this was not done during the upgrade is that your NAND probably run out of space. Some our old nand installations had to small boot partition so make sure that you have enough free space to issue this command. In case you don't, do it elsewhere and remove vmlinuz file before moving uImage there: mkimage -A arm -O linux -T kernel -C none -a "0x40008000" -e "0x40008000" -n "Linux kernel" -d vmlinuz-3.4.110-sun7i uImage
Don Pedro Posted February 28, 2016 Posted February 28, 2016 Hello, yep, that did the trick, Cubie is alive again: Image Name: Linux kernelCreated: Sun Feb 28 22:49:04 2016Image Type: ARM Linux Kernel Image (uncompressed)Data Size: 5608120 Bytes = 5476.68 kB = 5.35 MBLoad Address: 40008000Entry Point: 40008000 Failed to mount ext2 filesystem...** Unrecognized filesystem type **reading uImage5608184 bytes read## Booting kernel from Legacy Image at 48000000 ... Image Name: Linux kernel Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 5608120 Bytes = 5.3 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK Loading Kernel Image ... OKOKUsing machid 0x10bb from environmentStarting kernel ... Strange however that nand1 does have sufficient space: ~$ df Filesystem 1K-blocks Used Available Use% Mounted on... /dev/nand1 32686 8852 23834 28% /boot I was able to create the image directly where it belongs and I didn't have to delete vmlinuz. Thus insufficient space couldn't be the reason uImage did get lost. Guess I'll never find out... Anyway, thanks a lot Igor, you saved my day! So, amhairghin and EtlARM, maybe this is also the problem of your bricked systems? BR Don
EtlARM Posted February 29, 2016 Author Posted February 29, 2016 So, amhairghin and EtlARM, maybe this is also the problem of your bricked systems? Yes, it is very likely the same or similar problem. On my NAND1 I found only a zImage identical to the vmlinuz file but not an uImage. When creating an uImage it is binary different than the zImage. (Expected behavior, as uImage can be a zImage with additional header.) I will do more tests (e.g. booting) when I find some spare time and the serial cable has arrived...
Don Pedro Posted February 29, 2016 Posted February 29, 2016 Yep, serial console cable is indeed helpful, if not indispensable. Without it I wouldn't have been able to quickly analyse the problem, as Igor's image is completely headless. You don't even get a text console output if you plug in a monitor and keyboard. So until the cubie has completed booting and you can ssh the box you're nailed down to the serial. One additional fact I forgot to mention: After I was able to reanimate my Cubie I dared to install Igor's workaround, provoking re-bricking it: dpkg -r linux-jessie-root-cubietruck apt-get install linux-jessie-root-cubietruck Guess what, this did install without a hitch. To be safe I also did a reboot and it came up alive again without a problem. So I guess the following: I did a regular apg-get update/upgrade at that time. This installed some updates but failed to install linux-jessie-root-cubietruck. It was one of those other updates that seemingly installed correctly but bricked the Cubie, not linux-jessie-root-cubietruck. I didn't realize at that time because I didn't reboot - why should I, it's not a Windows machine ;-) I learned that days later when I shut down the Cubie for some hardware changes and it wouldn't come up again. So, as linux-jessie-root-cubietruck isn't the culprit this easily explains why Igor did not succeed reproducing the failure when testing this. The interesting remnant would be to find out which update bricked the Cubie. Unfortunately I don't know if I could backtrack which updates were installed in conjunction with linux-jessie-root-cubietruck, so this leaves plenty of room for speculations. BR Don
Jens Bauer Posted March 11, 2016 Posted March 11, 2016 http://www.ebay.com/itm/6Pin-USB-2-0-to-TTL-UART-Module-Serial-Converter-CP2102-STC-Replace-Ft232-Module-/400565980256?hash=item5d4397cc60 + good quality + cheap + trusted seller + fast delivery I definitely second that. I've bought plenty of the CP2102 USB-to-UART adapters (more than 10); all of them works well. Just one thing: I change the resistors connected to the LEDs with 2K7 resistors, so that they don't blind me. Bonus advantage of the CP2102 module: SiLabs actually made a driver for PowerPC based Macintosh (which is my primary computer) - many of the others don't want to support anything but Windows. In addition, Prolific requires you to pay a mountain of money, if you want to change the VID/PID of PL2303, which was why I moved to CP2102.
amhairghin Posted May 28, 2016 Posted May 28, 2016 For me, after every update I must do: mkimage -A arm -O linux -T kernel -C none -a "0x40008000" -e "0x40008000" -n "Linux kernel" -d zImage uImage The system never builds uImage and I not have disk space problems.
mxpycoder Posted July 1, 2016 Posted July 1, 2016 I'm not sure if this is the exact same issue, but I had a similar error message with my most recent apt-get upgrade. As can be seen, the issue here was that dpkg tried to make a backup of a directory to a location that was not empty: # apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: linux-firmware-image-sun7i linux-headers-sun7i linux-image-sun7i linux-jessie-root-cubietruck 4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 20.4 MB of archives. After this operation, 12.3 kB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 http://apt.armbian.com/ jessie/main linux-firmware-image-sun7i armhf 5.15 [285 kB] Get:2 http://apt.armbian.com/ jessie/main linux-headers-sun7i armhf 5.15 [5,786 kB] Get:3 http://apt.armbian.com/ jessie/main linux-image-sun7i armhf 5.15 [14.0 MB] Get:4 http://apt.armbian.com/ jessie/main linux-jessie-root-cubietruck armhf 5.15 [372 kB] Fetched 20.4 MB in 11s (1,778 kB/s) (Reading database ... 61165 files and directories currently installed.) Preparing to unpack .../linux-firmware-image-sun7i_5.15_armhf.deb ... Unpacking linux-firmware-image-sun7i (5.15) over (5.11) ... Preparing to unpack .../linux-headers-sun7i_5.15_armhf.deb ... Unpacking linux-headers-sun7i (5.15) over (5.11) ... Preparing to unpack .../linux-image-sun7i_5.15_armhf.deb ... Unpacking linux-image-sun7i (5.15) over (5.11) ... Preparing to unpack .../linux-jessie-root-cubietruck_5.15_armhf.deb ... mv: cannot move ‘/boot/bin’ to ‘/boot/bin.old/bin’: Directory not empty Unpacking linux-jessie-root-cubietruck (5.15) over (5.11) ... dpkg: error processing archive /var/cache/apt/archives/linux-jessie-root-cubietruck_5.15_armhf.deb (--unpack): unable to make backup link of `./boot/bin/bananapi.bin' before installing new version: Operation not permitted Processing triggers for systemd (215-17+deb8u4) ... Errors were encountered while processing: /var/cache/apt/archives/linux-jessie-root-cubietruck_5.15_armhf.deb E: Sub-process /usr/bin/dpkg returned an error code (1) A close look at /boot/bin.old revealed that inside /boot/bin.old was another bin folder: root@xxxxxx:/boot/bin.old# ls -la total 984 drwxr-xr-x 3 root root 4096 May 27 18:12 . drwxr-xr-x 5 root root 16384 Jul 1 09:10 .. -rwxr-xr-x 1 root root 45936 Feb 11 23:48 aw-som-a20.bin -rwxr-xr-x 1 root root 50560 Feb 11 23:48 bananapi.bin -rwxr-xr-x 1 root root 50624 Feb 11 23:48 bananapilcd7.bin -rwxr-xr-x 1 root root 50656 Feb 11 23:48 bananapipro.bin -rwxr-xr-x 1 root root 50500 Feb 11 23:48 bananapiprolcd7.bin drwxr-xr-x 2 root root 4096 May 6 10:37 bin -rwxr-xr-x 1 root root 46308 Feb 11 23:48 cubieboard2.bin -rwxr-xr-x 1 root root 46248 Feb 11 23:48 cubieboard2dual.bin -rwxr-xr-x 1 root root 43716 Feb 11 23:48 cubieboard.bin -rwxr-xr-x 1 root root 46404 Feb 11 23:48 cubietruck.bin -rwxr-xr-x 1 root root 51012 Feb 11 23:48 lamobo-r1.bin -rwxr-xr-x 1 root root 53480 Feb 11 23:48 lime2.bin -rwxr-xr-x 1 root root 43508 Feb 11 23:48 lime-a10.bin -rwxr-xr-x 1 root root 52616 Feb 11 23:48 lime.bin -rwxr-xr-x 1 root root 52252 Feb 11 23:48 micro.bin -rwxr-xr-x 1 root root 29804 Feb 11 23:48 olinux-som-a13.bin -rwxr-xr-x 1 root root 35888 Feb 11 23:48 orangepi2.bin -rwxr-xr-x 1 root root 50972 Feb 11 23:48 orangepi.bin -rwxr-xr-x 1 root root 35996 Feb 11 23:48 orangepione.bin -rwxr-xr-x 1 root root 36000 Feb 11 23:48 orangepipc.bin -rwxr-xr-x 1 root root 36768 Feb 11 23:48 orangepiplus.bin -rwxr-xr-x 1 root root 49300 Feb 11 23:48 pcduino3nano.bin -rwxr-xr-x 1 root root 4229 Jan 2 13:53 upgrade.log I suspect that this issue may be caused by multiple updates due to some error in the update scripts. The first time, the old /boot/bin directory is renamed to /boot/bin.old. The second time, the directory /boot/bin.old already exists and the /boot/bin directory is moved into that directory. The third time: we already have /boot/bin.old/bin and a move of /boot/bin to /boot/bin.old/bin causes this failure. I've solved this by moving bin.old and the bin folder inside it to another name and running apt-get upgrade again: # apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: linux-jessie-root-cubietruck 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 3 not fully installed or removed. Need to get 0 B/372 kB of archives. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] y (Reading database ... 61134 files and directories currently installed.) Preparing to unpack .../linux-jessie-root-cubietruck_5.15_armhf.deb ... Unpacking linux-jessie-root-cubietruck (5.15) over (5.11) ... Processing triggers for systemd (215-17+deb8u4) ... Setting up linux-firmware-image-sun7i (5.15) ... Setting up linux-headers-sun7i (5.15) ... Compiling headers - please wait ... Setting up linux-image-sun7i (5.15) ... Image Name: Linux kernel Created: Fri Jul 1 09:30:02 2016 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 5606240 Bytes = 5474.84 kB = 5.35 MB Load Address: 40008000 Entry Point: 40008000 Setting up linux-jessie-root-cubietruck (5.15) ... As can be seen, the uImage is created as well. I still have to reboot the system, but I guess that it will work normally. Please confirm if other have seen this as well, I can create a small bug report if this is indeed a mistake in the upgrade scripts... Edit: reboot works normally, boot from nand...
amhairghin Posted July 1, 2016 Posted July 1, 2016 For me not work. My update. $ sudo apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: linux-firmware-image-sun7i linux-headers-sun7i linux-image-sun7i linux-jessie-root-cubietruck 4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 20.4 MB of archives. After this operation, 12.3 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://apt.armbian.com/ jessie/main linux-firmware-image-sun7i armhf 5.15 [285 kB] Get:2 http://apt.armbian.com/ jessie/main linux-headers-sun7i armhf 5.15 [5,786 kB] Get:3 http://apt.armbian.com/ jessie/main linux-image-sun7i armhf 5.15 [14.0 MB] Get:4 http://apt.armbian.com/ jessie/main linux-jessie-root-cubietruck armhf 5.15 [372 kB] Fetched 20.4 MB in 5s (3,561 kB/s) (Reading database ... 52931 files and directories currently installed.) Preparing to unpack .../linux-firmware-image-sun7i_5.15_armhf.deb ... Unpacking linux-firmware-image-sun7i (5.15) over (5.11) ... Preparing to unpack .../linux-headers-sun7i_5.15_armhf.deb ... Unpacking linux-headers-sun7i (5.15) over (5.11) ... Preparing to unpack .../linux-image-sun7i_5.15_armhf.deb ... Unpacking linux-image-sun7i (5.15) over (5.11) ... Preparing to unpack .../linux-jessie-root-cubietruck_5.15_armhf.deb ... Unpacking linux-jessie-root-cubietruck (5.15) over (5.11) ... Processing triggers for systemd (215-17+deb8u4) ... Setting up linux-firmware-image-sun7i (5.15) ... Setting up linux-headers-sun7i (5.15) ... Compiling headers - please wait ... Setting up linux-image-sun7i (5.15) ... Setting up linux-jessie-root-cubietruck (5.15) ... The update not make the magic line: mkimage -A arm -O linux -T kernel -C none -a "0x40008000" -e "0x40008000" -n "Linux kernel" -d zImage uImage
Recommended Posts