Building Gerda: always getting a bootloop

[saperski]

Hello,

I have successfully installed Gerda on Nokia 8110 4G using the original (updated on 2019-04-10 - build version 730c6b1) images and it works fine.

I have build the system installer myself out of git (both master b381b495d4d7 and 730c6b1) on two different systems - FreeBSD with some slight changes to the Makefiles

and a 100% clean build on Fedora 25 and the resulting images always end up in a penguin logo boot loop, before adb even starts.

I am using "adb sideload xxx" to load them or putting them on SD card.

The same happens to me with a self-built recovery (this one I could build on Fedora only because of https://gitlab.com/project-pris/recovery/issues/1).

Any hints how to troubleshoot this before we have reproducible builds?

Next steps: I will try to sideload system partition image only and see if other partitions are making some trouble. If system does not work, I'll try comparing the images on a filesystem level.

How do you deal with boot loops on Nokia 4110?

saper

[speeduploop]

Depends on why the bootloop happens:

-- for failures on /data I create a repair-zip on the fly or just do a factory-reset...

-- for failures on /system I create a repair-zip on-the-fly or just reflash system completely...

(I always keep a more or less recent rflash-zip with my modded /system on sdcard)

But you could also flash Gerda's recovery - this way you would have adb in recovery to repair things manually....

[saperski]

On Saturday, June 8, 2019 at 1:13:13 PM UTC+2, speeduploop wrote:

Depends on why the bootloop happens:

-- for failures on /data I create a repair-zip on the fly or just do a factory-reset...

I have wipe my data for testing this...

 

-- for failures on /system I create a repair-zip on-the-fly or just reflash system completely...

(I always keep a more or less recent rflash-zip with my modded /system on sdcard

My problem is that I do not know what happens at all.  How do I know where it breaks?

If there were some userland logs saved to /cache...

 

But you could also flash Gerda's recovery - this way you would have adb in recovery to repair things manually....

.

Thanks, yes, I have Gerda's recovery. By the way, somehow once it reverted to "KaiOS recovery", do you know why and how this happens?

I had to flash Gerda recovery again. Is there a magic key combination to boot "alt recovery"?

Now there is progress: I have flashed ONLY the system partition and it works. So maybe there is a problem with rebuilding boot or something else?

saper

[speeduploop]

On Saturday, June 8, 2019 at 1:24:31 PM UTC+2, saperski wrote:

Thanks, yes, I have Gerda's recovery. By the way, somehow once it reverted to "KaiOS recovery", do you know why and how this happens?

I had to flash Gerda recovery again.

A stock system-image checks the recovery at boot and replaces it with it's stock-recovery...

(there is an install-script in /bin you have to disable if you want to mix stock-system with non-stock-recovery)

[saperski]

Thanks, yes, I have Gerda's recovery. By the way, somehow once it reverted to "KaiOS recovery", do you know why and how this happens?

I had to flash Gerda recovery again.

A stock system-image checks the recovery at boot and replaces it with it's stock-recovery...

(there is an install-script in /bin you have to disable if you want to mix stock-system with non-stock-recovery)

Thank you! This I didn't know that .... that must have been the first time I have installed Gerda recovery.

Now on to figure out which partition update breaks my system... 

saper

[saperski]

Update: looks like the boot image it is. Now on to unpacking it and comparing.

Looks like there are some differences in the way initrd filesystem image is built with "find" and "cpio".

saper

[Luxferre]

Yes, there is an issue with a boot image building when done on a cloud Linux system for some configurations. Still trying to figure that out (otherwise build automation would make no sense) and the only suggestions that come to my mind are: 1) it's happening because of incompatible compression modes (should we really bring our own cpio/gzip? we can try...),  2) it's happening because of wrong permission management in the packed tree.

Stay tuned, this thing is now among the ones with highest priority.

[Luxferre]

Just so you know, the CI/build issue has been fixed in the master commit 221edb83 of Pris repo.

Special thanks to @saper and @oleole for investigating this.