matrzh Posted July 30, 2021 Posted July 30, 2021 For the second time within about 4 weeks my cubietruck is not coming up anymore after a sudo apt upgrade and reboot. Is there something systematically breaking? I think it is the initramfstools that is breaking it? Now, I have no radio, alarm-clock and I cannot turn on my coffee-maker over the internet and I will probably have to spend a day etching a new SD card etc. I bought a new SD card last time this happened since I figured ist would be related to that, now I think it is a software thing. I use the cubietruck headless over ssh and have no real video output, just audio. I also need to do some cumbersome operations to get it out of the box, it is in from which it is controlling all sorts of remote controls for receivers, projectors etc. So it is almost easier to etch a new card, but I am afraid I will find myself with the same problem in a few weeks again. I used the following image Armbian_21.05.1_Cubietruck_buster_current_5.10.34_xfce_desktop.img The latest upgrade did the following: The following packages will be upgraded: code firefox-esr libgssapi-krb5-2 libjavascriptcoregtk-4.0-18 libk5crypto3 libkrb5-3 libkrb5support0 libnss-myhostname libpam-systemd libsystemd0 libudev1 libwebkit2gtk-4.0-37 linux-u-boot-cubietruck-current systemd systemd-sysv udev In particular: Processing triggers for initramfs-tools (0.133+deb10u1) ... update-initramfs: Generating /boot/initrd.img-5.10.43-sunxi update-initramfs: Converting to u-boot format Is it now trying to boot from ramfs rather than the SD-card? Any suggestions on what I could do in a more "minimally invasive" way to get it back to work? Any updates I should hold back in the future to keep this from happening?
Solution Igor Posted July 30, 2021 Solution Posted July 30, 2021 3 hours ago, matrzh said: Is there something systematically breaking? This is the problem and the solution:
matrzh Posted July 30, 2021 Author Posted July 30, 2021 Thank you. The easiest for me would be to manipulate the SD card in a computer and then hope that it will not enter a bootloop, again. Can you tell me which files I need to revert? The manipulated files from the update in the /boot directory are uInitrd-5.10.43-sunxi (with uInitrd sym-linked to it) initrd.img-5.10.43-sunxi Can I download the files for the A20 processor somewhere without having to burn another SD card?
Werner Posted July 31, 2021 Posted July 31, 2021 None of them.. Read the topic mentioned above again for suggestions to solve.
matrzh Posted July 31, 2021 Author Posted July 31, 2021 I really appreciate your help, but I am not getting it (or at least I am not sure what is happening, the solution is really not that 'easy' to go through for me). The boot.scr file hast a datestamp of May 7 which likely was the initial installation when I etched the SD card (so ok, it's 8 weeks ;)). That apparently did not change, yesterday (as are boot.cmd, boot.bmp) Does this mean the old boot.bmp does not "fit" to the newly created initrd.img.... file (which has a datestamp of July 30, i.e. yesterday) Would locking this to "BOOTBRANCH='tag:v2020.10'" as suggested in the patch of the solution remedy it and avoid this in the future? So a possible solution would be to adopt the boot.* files. I found / am finding this confusing because they did not change. Best Matthias
Werner Posted July 31, 2021 Posted July 31, 2021 19 minutes ago, matrzh said: Would locking this to "BOOTBRANCH='tag:v2020.10'" as suggested in the patch of the solution remedy it and avoid this in the future? In short term, yes. This is the workaround for the issue. However somewhen we need to move forward again. Most likely when this issue is solved upstream. You can try to build a recent u-boot package from scratch using our build tools and then follow this guide: https://docs.armbian.com/User-Guide_Recovery/
matrzh Posted July 31, 2021 Author Posted July 31, 2021 Thanks again. Sorry if I am stuck again. In addition, the environment I had on my VirtualBox crashed completely and I set a new one, based on X64 Debian. compile.sh as suggested here:https://docs.armbian.com/Developer-Guide_Build-Preparation, I get an error Running this tool on non x86-x64 build host is not supported But I do have the an i386 Processor (Mac). dpkg --print-architechture gives 'i386' The code lines in general.sh 1013ff however suggest that only arm64 and amd64 are accepted. Can I build it on a i386 processor with virtualization, at all?
matrzh Posted July 31, 2021 Author Posted July 31, 2021 ok, I am giving up and will reinstall a new card with a working image. It will be faster and only take half a day to get everything re-installed.... I would appreciate if someone could give me any hints on what I need to do that the next "apt upgrade" is not bricking the device, again. Do I need to choose a different bootloader with armbian-config, before? Best Matthias
Werner Posted July 31, 2021 Posted July 31, 2021 1 hour ago, matrzh said: Can I build it on a i386 processor with virtualization, at all? No. 40 minutes ago, matrzh said: what I need to do that the next "apt upgrade" is not bricking the device, again. Use armbian-config to freeze firmware and wait until 21.08 is released. Expected by end of August.
matrzh Posted August 1, 2021 Author Posted August 1, 2021 Thanks, everything back up and running. The firmware freeze held back the correct updates and a run of apt update/upgrade on the new installation worked well without breaking the boot process Matthias
Recommended Posts