Dave Hylands [:dhylands] Assignee
	Description • 9 years ago

The lightsaber phone doesn't currently include a recovery partition. So this bug is to add the equivalent functionality.

Cyanogen Mod has a way to get into a recovery mode, so this bug will be to implement a similar mechanism.

	Dave Hylands [:dhylands] Assignee
	Comment 1 • 9 years ago

Inspired from Cyanogen Mod's init.sh script for support recovery on the Z3 and Z3C.

This requires that we flash the FOTAKernel partition with the recovery.img file which is built as part of the aries build.

Alternatively, we could store the recovery ramdisk on the initial ramdisk used during normal boot.

I took the flash recovery.img route initially because it meant I didn't have to make any modifications to the build/core/Makefile

	Dave Hylands [:dhylands] Assignee
	Comment 2 • 9 years ago

Point RECOVERY_EXTERNAL_STORAGE to internal sdcard so that you don't have to have a physical sdcard in order to perform recovery.

This means certain types of recovery won't be possible (i.e. anything related with moving partitions containing /data), but seems to me to tbe the way we'd want to do things for normal FOTA.

	Dave Hylands [:dhylands] Assignee
	Comment 3 • 9 years ago

This adds recovery.fstab which is needed so that /cache can be mounted by the recovery ROM.

	:gerard-majax [PTO 01/08/2023-10/09/2023]
	Comment 4 • 9 years ago

Woo nice. I may also request feedback from people who are very knowledgeable regarding FOTAKernel partitions :)

	:gerard-majax [PTO 01/08/2023-10/09/2023]
	Comment 5 • 9 years ago

Comment on attachment 8580421 [details]
New repository to go into external/init_sh

Adding Adam who knows a lot about hacking this kind of stuff.

	:gerard-majax [PTO 01/08/2023-10/09/2023]
	Comment 6 • 9 years ago

Comment on attachment 8580424 [details]
Point RECOVERY_EXTERNAL_STORAGE to internal sdcard

Adding Adam who knows a lot about hacking this kind of stuff.

	:gerard-majax [PTO 01/08/2023-10/09/2023]
	Comment 7 • 9 years ago

Comment on attachment 8580425 [details]
Add recovery.fstab for aries device

Adding Adam who knows a lot about hacking this kind of stuff.

	:gerard-majax [PTO 01/08/2023-10/09/2023]
	Comment 8 • 9 years ago

(In reply to Dave Hylands [:dhylands] from comment #1)

[...]

> 
> This requires that we flash the FOTAKernel partition with the recovery.img
> file which is built as part of the aries build.

I know this is specific to Sony's devices, but maybe we will have to hack flash.sh for supporting this, right?

	Adam Farden [:adfad666]
	Comment 9 • 9 years ago

I currently use this repo on AOSP 5.0 for Sony recoveries: https://github.com/fxpdev/device-sony-recovery and this solution has been used successfully on CM for years.

It simply bundles a prebuilt CM-recovery ramdisk into the boot.img, with a script to select the correct ramdisk at boot (it's just a simplified version of what we do on CM).

the important part is extract_elf_ramdisk which is open source, but you'll probably want to build busybox rather than use the prebuilt like I have.

The readme mentions the two commits you'll need to override img generation with "custombootimg.mk". 

We use "BOARD_CUSTOM_MKBOOTIMG := mkqcdtbootimg" to deal with dtb files on AOSP, but you won't need that if you are using qcom's solutions, and I don't think this works on AOSP 4.4 anyway.

	:gerard-majax [PTO 01/08/2023-10/09/2023]
	Comment 10 • 9 years ago

Comment on attachment 8580425 [details]
Add recovery.fstab for aries device

Why only for aries? Shouldn't we also be able to get this on shinano ?

	:gerard-majax [PTO 01/08/2023-10/09/2023]
	Comment 11 • 9 years ago

Building and flashing recovery to FOTAKernel partition works.
Rebooting into recovery mode works, even though it seems to be taking some time.
Building FOTA update package works.
Sideloading FOTA update package works.

For now, I only found mounting the sdcard that was failing.

	:gerard-majax [PTO 01/08/2023-10/09/2023]
	Comment 12 • 9 years ago

> $ grep sdcard recovery.fstab 
> /dev/block/mmcblk1p1                              /sdcard           ext4    nosuid,nodev,barrier=1,data=ordered,nodelalloc                  wait

So as far as I remember, mmcblk1p1 will be the first partition of the physical sdcard, not the internal one. Hence why mounting /sdcard will fail. Since we are building librecovery with the /data/media/0 value it should not be a problem for applying from Gecko, but it may be one if people put their update on the sdcard itself.

	:gerard-majax [PTO 01/08/2023-10/09/2023]
	Comment 13 • 9 years ago

> E:failed to mount /sdcard (Invalid argument)

	:gerard-majax [PTO 01/08/2023-10/09/2023]
	Comment 14 • 9 years ago

Moving recovery.fstab to shinano-common, adding "TARGET_RECOVERY_FSTAB := device/sony/shinano-common/recovery.fstab" to shinano-common/BoardConfig.mk, changing ext4 to vfat in recovery.fstab and I get sdcard to be mounted properly in recovery mode.

	:gerard-majax [PTO 01/08/2023-10/09/2023]
	Comment 15 • 9 years ago

Comment on attachment 8580425 [details]
Add recovery.fstab for aries device

I'm fine with this, but I would prefer that we have the external sdcard being in vfat rather than ext4, and that we move this to shinano-common, as documented just above.

	:gerard-majax [PTO 01/08/2023-10/09/2023]
	Comment 16 • 9 years ago

Comment on attachment 8580421 [details]
New repository to go into external/init_sh

That works, but we will need a patch for the shinano.xml manifest of course.

	:gerard-majax [PTO 01/08/2023-10/09/2023]
	Comment 17 • 9 years ago

Comment on attachment 8580424 [details]
Point RECOVERY_EXTERNAL_STORAGE to internal sdcard

> 03-20 14:26:04.890  1612  1612 I Gecko   : *** AUS:SVC UpdateService:applyOsUpdate - Rebooting into recovery to apply FOTA update: /storage/emulated/legacy/updates/fota/update.zip
> 03-20 14:26:04.890  1612  1612 I GeckoConsole: AUS:SVC UpdateService:applyOsUpdate - Rebooting into recovery to apply FOTA update: /storage/emulated/legacy/updates/fota/update.zip
> 03-20 14:26:04.900  1612  1612 D librecovery: Rebooting into recovery: --update_package=/data/media/0/updates/fota/update.zip

	Dave Hylands [:dhylands] Assignee
	Comment 18 • 9 years ago

Comment on attachment 8580421 [details]
New repository to go into external/init_sh

Adding mwu for feedback.

I'm going to file followup bugs to build busybox and extract_ramdisk_elf from source, and I'll also update flash.sh to flash the recovery when doing a full flash.

	Dave Hylands [:dhylands] Assignee
	Comment 19 • 9 years ago

This updates flash.sh to flash the recovery partition on an aries or shinano device when doing a full flash.

	Dave Hylands [:dhylands] Assignee
	Comment 20 • 9 years ago

Comment on attachment 8580425 [details]
Add recovery.fstab for aries device

I'm obsoleting this PR and updated the shinano-common pull request to include the recovery.fstab instead.

	:gerard-majax [PTO 01/08/2023-10/09/2023]
	Comment 21 • 9 years ago

Comment on attachment 8580928 [details]
Update flash.sh to flash recovery partition when doing a full flash

./flash.sh properly flashes the FOTAKernel partition. Could we also take the time to support:
 (1) flashing recovery by doing ./flash.sh recovery ?
 (2) supporting flashing multiple partitions at once ? Like |./flash.sh boot system recovery| if I want to keep my userdata partition.

	Michael Wu [:mwu]
	Comment 22 • 9 years ago

Comment on attachment 8580421 [details]
New repository to go into external/init_sh

Looks alright. The ramdisk switching idea also sounds pretty good, but up to you guys to figure out what solution we use.

	Dave Hylands [:dhylands] Assignee
	Comment 23 • 9 years ago

(In reply to Michael Wu [:mwu] from comment #22)
> Comment on attachment 8580421 [details]
> New repository to go into external/init_sh
> 
> Looks alright. The ramdisk switching idea also sounds pretty good, but up to
> you guys to figure out what solution we use.

Partly, this boils down to the way that the ramdisk images are built.

The way that the current build (build/core/Makefile) creates things is that it does the following:

1 - Creates the ramdisk used for normal booting
2 - Creates the recovery ramdisk by unpacking the ramdisk from 1 and makes some modifications

There are basically 2 schemes I can see:

1 - Have the initial ramdisk be neither the normal one, nor the recovery one. It would have just enough to figure out which one to use and then load the real ramdisk.

2 - What I did was to have the initial ramdisk be the normal one, and for doing recovery, it removes most of the contents of the initial one and overlays the contents of the recovery one.

And then for each scheme you have some choices about where the contents of the ramdisk come from.

What CM does works well for "modify an existing image", but doesn't work so well as "build it from scratch". I'm sure that part of this is I'm still learning various bits and pieces of the android build system. It may very well be not too difficult to implement scheme 1, and it would probably be preferred, but I'll defer it until I get a bit more familiar with some of the build stuff.

	Dave Hylands [:dhylands] Assignee
	Comment 24 • 9 years ago

(In reply to Alexandre LISSY :gerard-majax from comment #21)
> Comment on attachment 8580928 [details]
> Update flash.sh to flash recovery partition when doing a full flash
> 
> ./flash.sh properly flashes the FOTAKernel partition. Could we also take the
> time to support:
>  (1) flashing recovery by doing ./flash.sh recovery ?
>  (2) supporting flashing multiple partitions at once ? Like |./flash.sh boot
> system recovery| if I want to keep my userdata partition.

I like this, and will file a followup bug.

I'll also need to modify the manifests in order to land this properly, but I think that the first step will be getting the init_sh repository created and populated, and then update the manifest, and finally, land the other 2 patches.

	Dave Hylands [:dhylands] Assignee
	Comment 25 • 9 years ago

Now that I've created the init_sh repository, we can add it to the manifest.

Then the other 2 parts of this bug can land.

	[:fabrice] Fabrice Desré
	Comment 26 • 9 years ago

Comment on attachment 8582050 [details]
Add init_sh repository to the shinano/aries builds

lgtm, but this should be reviewed by mwu.

	:gerard-majax [PTO 01/08/2023-10/09/2023]
	Comment 27 • 9 years ago

Comment on attachment 8582050 [details]
Add init_sh repository to the shinano/aries builds

I think we will have to mirror this on git.mozilla.org too

	Dave Hylands [:dhylands] Assignee
	Comment 28 • 9 years ago

https://github.com/mozilla-b2g/init_sh/commit/3bdd26e092db9c47c5beb04b4809a35f8f767b8a
https://github.com/mozilla-b2g/b2g-manifest/commit/b5c2ba0387db79686c33b579e8584775cb1b514f
https://github.com/mozilla-b2g/device-shinano-common/commit/43be4615072aa43649d459bab91278e0ec7caa62
https://github.com/mozilla-b2g/B2G/commit/9260e00c890c1cd385fd281296d5037fa7e4dece