Cubietruck updates break?

[matrzh]

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?

 

 

 

[Igor]

3 hours ago, matrzh said:

Is there something systematically breaking?

 

This is the problem and the solution:
 

 

[matrzh]

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]

None of them.. Read the topic mentioned above again for suggestions to solve.

[matrzh]

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]

 

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]

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]

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]

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]

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