Cubietruck updates break?


matrzh
 Share

0
Go to solution Solved by Igor,

Recommended Posts

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?

 

 

 

Link to post
Share on other sites

Donate and support the project!

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?

Link to post
Share on other sites

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

 

Link to post
Share on other sites

 

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/

Link to post
Share on other sites

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?

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

0