Closed peat-psuwit closed 8 months ago
Can you tell me the rationale why it is necessary to spell the slot out after switching it explicitly to a? Also, should the Droidian installation part be updated as well to do the same?
Can you tell me the rationale why it is necessary to spell the slot out after switching it explicitly to a? Also, should the Droidian installation part be updated as well to do the same?
Can't really comment on mimameid
but some bootloader implementations are buggy and require to reboot into bootloader to detect switching slots and may flash a different slot.
Specifying the slot explicitly always works on these buggy implementations. Even if not working around a buggy bootloader, it better expresses what is meant to happen.
Can you tell me the rationale why it is necessary to spell the slot out after switching it explicitly to a?
On Volla Phone 22, its bootloader seems to flash to the currently booted slot, rather than the set-to-be-active slot. For example, if booted as slot b
, fastboot flash boot <image>
will always flash to boot_b
, even though fastboot set_active a
is already run. I don't know why; buggy firmware? (That said, what defines this behavior in fastboot?)
Also, should the Droidian installation part be updated as well to do the same?
Not sure... I guess I'll have to test, although I don't have a VP22 on hand at the moment. You may try to reproduce this by flashing Android and then do the upgrade once.
@peat-psuwit , in that case, I believe it would be necessary to specifically use the slot suffix on boot, dtbo, and vbmeta when installing Droidian.
Ok. Droidian section also updated to use _a
suffix.
Ok. Droidian section also updated to use
_a
suffix.
LGTM now.
@erikinkinen ping, please.
Any reason this is still pending? If Droidian is the blocker I propose moving changes for that to a new PR where it can be finished
Droidian should be dropped from mimameid config anyways. Droidian image generation for mimameid was temporarily halted due to a serious bug found in the adaptation.
@erikinkinen I believe you now have it running again (without LVM), is there anything to do here? I know https://github.com/droidian-releng/droidian-installer & https://github.com/droidian-devices/installer-configs exists as well now, should it be removed or leave a "dummy entry" with a message pointing to use Droidian installer instead?
@JamiKettunen , the configs need to be updated and I will open another PR once I have done that.
Ping @peat-psuwit, I think the way forward and finally get this merged is to drop Droidian entirely from the config for now and add it back later once it's back in working order again
@peat-psuwit Should I resubmit this PR with the change I proposed in my previous message?
Now that CI is working again, are there any updates? :)
@amartinz , regarding the Droidian situation, #257 should fix that. AFAIK, that was the only blocker here.
The PR is rebased, and the commit message is updated to correctly refer to the new bootstrap tarball. Since #257 seems to be made on top of this PR, I think this one should go in first, then #257 can be rebased and merged.
The PR is rebased, and the commit message is updated to correctly refer to the new bootstrap tarball. Since #257 seems to be made on top of this PR, I think this one should go in first, then #257 can be rebased and merged.
Yes, that was my intention on #257 .
Thanks! :)