0
General - Boot/Vbmeta IMGs for November Firmware / SD1A.210817.036 | Page 3 | XD...
source link: https://forum.xda-developers.com/t/boot-vbmeta-imgs-for-november-firmware-sd1a-210817-036.4353807/page-3#post-85862303
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Boot/Vbmeta IMGs for November Firmware
Hey everybody,
I skimmed the threads and it seems nobody tried to extract the boot.img from a device that´s been updated to November firmware.
So at the moment there´s no easy way to root devices where users took the november firmware update already, since factory images are only available for October firmware.
TLDR: Attached to this post are boot.img and vbmeta.img of November firmware that will allow you to root your pixel 6 pro running the updated firmware.
If you´re interested how these were obtained here´s a rough guideline:
Starting point is being a Pixel 6 pro on October firmware rooted.
Taking OTA will fail as boot and vbmeta partitions are altered due to the rooted installation.
Solution: restore those partitions to stock while the device is running, take the OTA but don´t reboot (this will flash OTA to the inactive slot), backup the now updated but still inactive partitions again.
I´ll write a quick mockup how this works, but it´s for advanced users only. So if you´re not comfortable with this I´d suggest to not attempt this.
I was on slot B with October firmware as starting point.
So the goal is to restore original B partitions while the OS is running, apply OTA (which would fail if you´re running altered partitions, boot/vbmeta) and backup updated inactive slot, in my case A.
First problem: Partitions to restore while OS is running need to be unblocked via the command:
Otherwise you get this error:
To determine which partition you need to unblock run:
Example how to restore changed partitions: (if you flashed a modified boot.img and vbmeta.img to root, you need to restore those two while the device is running otherwise the OTA will fail.)
This will restore boot_b to the original one so that partition won´t fail to apply the incremental OTA to.
After the OTA was successfully flashed we want to backup the updated boot slot. That would be boot_a in my case.
Command for doing so:
I backed up november boot.img and vbmeta.img that way. Please note that I had to flash vbmeta again and disable verity to obtain those imgs. OTA won´t flash if partitions are altered in any way. This wiped my device.
Attached to this post are completely stock boot.img and vbmeta.img from the November build I´m on.
This will allow people to root their devices on November firmware if they took the OTA.
Please note that those boot.imgs are from build SD1A.210817.036.
It´s a european Pixel 6 pro. I don´t think there should be a difference to the factory images from the other carriers like verizon etc regarding the boot.img. If you want to be absolutely sure, somebody on a different firmware needs to follow this process or we just wait for the factory images with nov security patch to drop.
I skimmed the threads and it seems nobody tried to extract the boot.img from a device that´s been updated to November firmware.
So at the moment there´s no easy way to root devices where users took the november firmware update already, since factory images are only available for October firmware.
TLDR: Attached to this post are boot.img and vbmeta.img of November firmware that will allow you to root your pixel 6 pro running the updated firmware.
If you´re interested how these were obtained here´s a rough guideline:
Starting point is being a Pixel 6 pro on October firmware rooted.
Taking OTA will fail as boot and vbmeta partitions are altered due to the rooted installation.
Solution: restore those partitions to stock while the device is running, take the OTA but don´t reboot (this will flash OTA to the inactive slot), backup the now updated but still inactive partitions again.
I´ll write a quick mockup how this works, but it´s for advanced users only. So if you´re not comfortable with this I´d suggest to not attempt this.
I was on slot B with October firmware as starting point.
So the goal is to restore original B partitions while the OS is running, apply OTA (which would fail if you´re running altered partitions, boot/vbmeta) and backup updated inactive slot, in my case A.
First problem: Partitions to restore while OS is running need to be unblocked via the command:
Code:
blockdev --setrw <block>
Code:
1|raven:/ # dd if=/data/local/tmp/boot.img of=/dev/block/by-name/boot_b
dd: /dev/block/by-name/boot_b: write error: Operation not permitted
1+0 records in
0+0 records out
0 bytes (0 B) copied, 0.002125 s, 0 B/s
Code:
126|raven:/ # cd dev/block/platform/14700000.ufs/by-name/
raven:/dev/block/platform/14700000.ufs/by-name # ls -al
total 0
drwxr-xr-x 2 root root 1020 2021-10-28 21:58 .
drwxr-xr-x 3 root root 1120 2021-10-28 21:58 ..
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 abl_a -> /dev/block/sdb5
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 abl_b -> /dev/block/sdc5
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 bl1_a -> /dev/block/sdb1
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 bl1_b -> /dev/block/sdc1
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 bl2_a -> /dev/block/sdb3
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 bl2_b -> /dev/block/sdc3
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 bl31_a -> /dev/block/sdb6
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 bl31_b -> /dev/block/sdc6
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 boot_a -> /dev/block/sda13
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 boot_b -> /dev/block/sda21
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 devinfo -> /dev/block/sdd1
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 dpm_a -> /dev/block/sdb10
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 dpm_b -> /dev/block/sdc10
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 dram_train_a -> /dev/block/sdb4
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 dram_train_b -> /dev/block/sdc4
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 dtbo_a -> /dev/block/sda10
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 dtbo_b -> /dev/block/sda18
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 efs -> /dev/block/sda5
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 efs_backup -> /dev/block/sda6
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 fips -> /dev/block/sda9
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 frp -> /dev/block/sda4
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 gsa_a -> /dev/block/sdb8
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 gsa_b -> /dev/block/sdc8
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 klog -> /dev/block/sda2
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 ldfw_a -> /dev/block/sdb9
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 ldfw_b -> /dev/block/sdc9
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 metadata -> /dev/block/sda8
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 mfg_data -> /dev/block/sdd2
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 misc -> /dev/block/sda3
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 modem_a -> /dev/block/sda12
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 modem_b -> /dev/block/sda20
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 modem_userdata -> /dev/block/sda7
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 pbl_a -> /dev/block/sdb2
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 pbl_b -> /dev/block/sdc2
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 persist -> /dev/block/sda1
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 pvmfw_a -> /dev/block/sda17
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 pvmfw_b -> /dev/block/sda25
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 super -> /dev/block/sda26
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 tzsw_a -> /dev/block/sdb7
lrwxrwxrwx 1 root root 15 2021-10-28 21:58 tzsw_b -> /dev/block/sdc7
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 userdata -> /dev/block/sda27
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 vbmeta_a -> /dev/block/sda14
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 vbmeta_b -> /dev/block/sda22
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 vbmeta_system_a -> /dev/block/sda15
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 vbmeta_system_b -> /dev/block/sda23
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 vbmeta_vendor_a -> /dev/block/sda16
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 vbmeta_vendor_b -> /dev/block/sda24
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 vendor_boot_a -> /dev/block/sda11
lrwxrwxrwx 1 root root 16 2021-10-28 21:58 vendor_boot_b -> /dev/block/sda19
Code:
raven:/ # blockdev --setrw /dev/block/sda21
raven:/ # dd if=/data/local/tmp/boot.img of=/dev/block/by-name/boot_b
131072+0 records in
131072+0 records out
67108864 bytes (64 M) copied, 8.790461 s, 7.2 M/sAfter the OTA was successfully flashed we want to backup the updated boot slot. That would be boot_a in my case.
Command for doing so:
Code:
dd if=/dev/block/bootdevice/by-name/boot_a of=/storage/emulated/0/boot_a.imgAttached to this post are completely stock boot.img and vbmeta.img from the November build I´m on.
This will allow people to root their devices on November firmware if they took the OTA.
Please note that those boot.imgs are from build SD1A.210817.036.
It´s a european Pixel 6 pro. I don´t think there should be a difference to the factory images from the other carriers like verizon etc regarding the boot.img. If you want to be absolutely sure, somebody on a different firmware needs to follow this process or we just wait for the factory images with nov security patch to drop.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK