• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

Pixel 2/Pixel 2 XL Support

Search This thread

DespairFactor

Recognized Developer / Inactive RC
Mar 13, 2013
5,786
12,341
Toronto
I will spend some time on Pixel 2 (XL) a while later, maybe recruiting more testers too.
I didn't have much time to update my official documentation to include magiskinit, but here is everything you need to know about it, with more details than normal documentations will contain.
I hope providing the process and how I think at that time will guide developers to investigate porting Magisk over to Pixel 2.

Warning: The following is a huge block of words with technical terms. After reading the whole block, you should have a clear idea how I ported Magisk to the first gen Pixel. Also, you will know the process and struggles I've gone through chronologically, so you can know how I tackle the problems one by one

The ramdisk stored in boot image only contains files for recovery. The actual root folder files are in the system partition.
If the bootloader set the kernel cmdline with the skip_initramfs flag, the kernel will mount system to root (doing verity at the same time), then execute /init to continue the booting.
So the first thing to do is to let the kernel ignore the skip_initramfs cmdline. The patch is simply just replacing the string to anything else, in my case I used want_initramfs.
At this point, the device will boot into recovery under any circumstances.

The next step is to make the device to actually boot up. We need to replace the init binary in the ramdisk, since this is the next thing the kernel will do once rootfs is setup. Here are the steps our init has to do:
  1. Mount procfs to /proc, so we can read kernel cmdline (/proc/cmdline) to check skip_initramfs flag, and also the current boot slot
  2. If skip_initramfs flag detected, it means we need to boot to system not recovery. Remove everything in rootfs (we will add in contents later)
  3. Mount sysfs to /sys, so we can access block uevents. Traverse and parse /sys/dev/block/*/uevent, until we found the major and minor node id for target system partition (with the correct slot)
  4. Make a new device block under /dev based on the major and minor id we got in the last step, and mount it to /system_root
  5. Copy everything in /system_root (except /system_root/system, obviously) to rootfs. These are the actual files and folders for rootfs
  6. Bind mount /system_root/system to /system, so the contents for the actual system is actually in the correct place
  7. Finally, execute /init (which should be the one copied from system partition)
At this point, the device will properly boot up, but it is pure stock without any modifications. You might notice that I didn't mention the dtb patch anywhere, because is not actually necessary. The only thing it does is to make init mount /vendor without dm-verity. The kernel thinks it is booting to recovery, so it will not handle mounting the system and verify the partition.
It took me nearly 3 full days to get to this stage, and this is the most difficult part in porting Magisk to first gen Pixel. If anyone can find a way to this stage, it will definitely help a lot!

Regarding Pixel 2, people can start with the same steps I've went through: the first step would be making the device to boot into recovery as we need to force the kernel to think it is booting into recovery mode.
I have checked the posts above, people have mentioned AVB 2.0. I do not have a device on hand and haven't checked any code yet (I'm no expert in AOSP and kernel code reviewing, people can help me out with this), but I don't think AVB will be enforced in recovery mode. We need to transfer all the heavy work for booting up the device to our modified init binary, which are the steps I've mentioned above.
The code for the modified init binary is located here: magiskinit.c. Note that this code also contains a large portion that is not related to the procedures mentioned above, they are stuffs to bring up Magisk, which I will continue to explain in detail in the following passage.
But please note our primary goal should be: make the kernel load rootfs from ramdisk, and boot up properly.

The following is just for information for developers to know what steps to continue once previous stages have been overcome.

To add some Magisk magic, we need to add files into rootfs. A new folder named overlay is created, and new files (init.magisk.rc and sbin/magisk) are added into the folder. magiskinit will skip this folder when it is cleaning rootfs (the second step in the list above). Before the last step, we move all files in the overlay folder to root. So now we have a device that can properly boot, with a few additional files in rootfs.

Next we need to tackle selinux. Usually, a monolithic sepolicy binary is placed in root directory in ramdisk, so logically it is expected that sepolicy should be in the root folder in system partition. However the first gen Pixel doesn't (fun fact: a similar device with A/B partition - Xiaomi A1 actually does place sepolicy in system root folder, just as expected). Instead, it splits the policies into several parts: platform policies (placed in system), non-platform policies (placed in vendor), mappings (placed in system) in Common Intermediate Language (CIL) format. The stock init binary will detect there is split policies available, so it will compile these cil files and load them as selinux policies. In reality though, Google have shipped a precompiled sepolicy in vendor, so init will load that instead.
We do not want to modify system or vendor, what can we do before init loads the stock policies? We either patch the precompiled sepolicy or compile the split cil files, and then dump the complete stock policies along with new rules into a monolithic binary to /sepolicy. We then have to patch the stock init (which is possible, since it is now copied to rootfs, not in the actual system partition) to always load from /sepolicy, not anywhere else.

The final step is to load the rc scripts to launch Magisk daemon. We inject a new line into the init.rc (same as /init, it is copied to rootfs so we are not modifying system), and things are all done!
To summarize, in addition to the list above, before we execute /init to give control back, we still need to do these to start Magisk:
  1. Patch init binary to not load from split or precompiled policies
  2. Inject a new line in init.rc to load init.magisk.rc
  3. Parse sysfs to create node for vendor block (same as step 3 above), and mount vendor
  4. Load / compile sepolicy, and dump monolithic sepolicy to root folder
  5. Finally execute /init

Conclusion, since magiskinit have done so much, patching a Pixel boot image with Magisk support is actually much easier than normal traditional devices! We only need to
  • Hex patch kernel to never skip_initramfs
  • For ramdisk: Replace init with magiskinit; add two files: overlay/init.magisk.rc, overlay/sbin/magisk
  • (Optional): Patch dtb to remove vendor dm-verity

That's all! Hope people has a more clear idea to start working with Pixel 2 :)
Do you know of a way we can force it to never skip at source level? when I did it, it just boots recovery.
 
  • Like
Reactions: jrbxx7

romracer

Senior Member
Apr 4, 2010
718
4,323
Kansas City
Do you know of a way we can force it to never skip at source level? when I did it, it just boots recovery.

It should be pretty easy to do. The code for this is in init/initramfs.c around line 624-625. Just comment out the if-block; this will force the kernel to use the initramfs included in the boot.img (ie. not skipping it).

I don't understand the second part of your question. As @topjohnwu stated, the boot.img initramfs only contains recovery files. By not skipping it, you are booting into recovery - so it sounds like you got what you wanted already? To re-quote:

So the first thing to do is to let the kernel ignore the skip_initramfs cmdline. The patch is simply just replacing the string to anything else, in my case I used want_initramfs.
At this point, the device will boot into recovery under any circumstances.

It sounds like you've made it to step 1 (getting the device always booting recovery AKA ignoring the "skip_initramfs" kernel command line option).

The next step would be to repack the initramfs included in boot.img to replace the init binary with magiskinit. Then you would need to begin stepping through magiskinit's code as it works steps 1-7 @topjohnwu outlined, looking for differences or failures between Pixel 1 and Pixel 2.

It may not contain anything useful, but one other area I would point out for investigation is the init/noinitramfs.c source file. This code is executed to setup a bare-bones root partition (the "/" partition) when you ARE skipping the built-in initramfs (remember: we are not skipping the built-in initramfs, so this code isn't executed if Magisk is done properly). Perhaps it contains clues to improperly or missing setup of the root partition (compare this source with OG Pixel's same source).

Based on everything I've read in these threads (this one and the one in the P2XL forums), you guys think SELinux or the hex patching is failing. Well it sounds like hex-patching is working fine. Theoretically, it should be possible to comment out the SELinux policy patching (and maybe init.rc patching) in magiskinit and replace the original init with it. You'd have a magiskinit that sets up the root partition and not much else. It wouldn't provide root, but it might let you know if magiskinit contains enough code to even get the Pixel 2 XL to boot.

Unfortunately, right now, I do not have the time to spend getting Magisk running on my Pixel 2 XL. Hopefully this helps someone else get the ball rolling though.
 

Itachisasuke

Senior Member
Apr 27, 2010
153
62
Southeastern PA
Hopefully the below will make porting to the Pixel 2 XL a bit easier.

qUnupBI.png
 

topjohnwu

Senior Recognized Developer / Recog. Contributor
Jan 31, 2012
1,849
61,093
Taipei
Sorry for the lack of support for developers here. I'll start actively working on Pixel 2 support, developers might receive PMs from me in the upcoming days :)
I've spent all my precious free time on optimizing Magisk. The latest upstream changes might confuse developers working on Magisk, so I think I would leave some notes here.

As stated in my long post in this thread, you should all know that the Magisk setup for Pixel (or devices with skip_initramfs in general) and non-Pixel devices differs quite significantly. The latest commit changes this fact: all devices in the future will install Magisk in the complete same configuration - that is replacing init with a new binary called monogisk.

Monogisk is a monolithic binary that has magisk, magiskinit, and init.magisk.rc compressed and embedded. What it only does is decompress and dump these three files into the correct places, and will give control to magiskinit ASAP. Things are done this way to make the installation more elegant, and it's a result of my "over-optimization" and "perfectionism". You shouldn't need to pay too much attention to this part, as the adjustments are done mostly in boot patch scripts and build scripts. What you should know is that after this change, installing Magisk is as simple as replacing /init in boot image with monogisk (and a ramdisk backup is required on non-Pixel devices, this has been done for nearly a year), no more overlay folder, no more sepolicy patch. Super simple.

The most important changes are done in magiskinit (now moved to jni/init/magiskinit.c) to be adjusted to also run on non-Pixel devices. These changes result in the fact that most of the ramdisk patches will be handled on-the-fly each time a device boots up, not done directly into ramdisk in boot image.

These updates might not affect skip_initramfs devices, but the quite drastic changes might confuse a few developers, so this post is to clarify the new situation.
A simple documentation are done in the beginning of magiskinit and monogisk source code, you can check them out along with the code :)
 
Last edited:

bryantjopplin

Senior Member
Sep 15, 2010
1,635
724
Sorry for the lack of support for developers here. I'll start actively working on Pixel 2 support, developers might receive PMs from me in the upcoming days :)
I've spent all my precious free time on optimizing Magisk. The latest upstream changes might confuse developers working on Magisk, so I think I would leave some notes here.

As stated in my long post in this thread, you should all know that the Magisk setup for Pixel (or devices with skip_initramfs in general) and non-Pixel devices differs quite significantly. The latest commit changes this fact: all devices in the future will install Magisk in the complete same configuration - that is replacing init with a new binary called monogisk.

Monogisk is a monolithic binary that has magisk, magiskinit, and init.magisk.rc compressed and embedded. What it only does is decompress and dump these three files into the correct places, and will give control to magiskinit ASAP. Things are done this way to make the installation more elegant, and it's a result of my "over-optimization" and "perfectionism". You shouldn't need to pay too much attention to this part, as the adjustments are done mostly in boot patch scripts and build scripts. What you should know is that after this change, installing Magisk is as simple as replacing /init in boot image with monogisk (and a ramdisk backup is required on non-Pixel devices, this has been done for nearly a year), no more overlay folder, no more sepolicy patch. Super simple.

The most important changes are done in magiskinit (now moved to jni/init/magiskinit.c) to be adjusted to also run on non-Pixel devices. These changes result in the fact that most of the ramdisk patches will be handled on-the-fly each time a device boots up, not done directly into ramdisk in boot image.

These updates might not affect skip_initramfs devices, but the quite drastic changes might confuse a few developers, so this post is to clarify the new situation.
A simple documentation are done in the beginning of magiskinit and monogisk source code, you can check them out along with the code :)
So is it staying Magisk or changing the name to Monogisk lol. Thanks for looking into everything.
 

123SIT

Senior Member
Oct 4, 2007
693
841
Greenville, NC
What you actually see when booted up is Magisk, there is no place you can find monogisk. Monogisk is the "behind-of-scene" kinda guy :D

I'm working with some of the other guys on the Pixel 2 XL and would love to chat if you have about 5 minutes. I'm adding some logging into magiskinit.c to write to a log file so we can see why and exactly where we are boot looping, but I'm not really sure what's mounted at the time magiskinit runs. Any suggestions are welcome and appreciated :)
 
  • Like
Reactions: cmo220

Top Liked Posts

  • There are no posts matching your filters.
  • 66
    I will spend some time on Pixel 2 (XL) a while later, maybe recruiting more testers too.
    I didn't have much time to update my official documentation to include magiskinit, but here is everything you need to know about it, with more details than normal documentations will contain.
    I hope providing the process and how I think at that time will guide developers to investigate porting Magisk over to Pixel 2.

    Warning: The following is a huge block of words with technical terms. After reading the whole block, you should have a clear idea how I ported Magisk to the first gen Pixel. Also, you will know the process and struggles I've gone through chronologically, so you can know how I tackle the problems one by one

    The ramdisk stored in boot image only contains files for recovery. The actual root folder files are in the system partition.
    If the bootloader set the kernel cmdline with the skip_initramfs flag, the kernel will mount system to root (doing verity at the same time), then execute /init to continue the booting.
    So the first thing to do is to let the kernel ignore the skip_initramfs cmdline. The patch is simply just replacing the string to anything else, in my case I used want_initramfs.
    At this point, the device will boot into recovery under any circumstances.

    The next step is to make the device to actually boot up. We need to replace the init binary in the ramdisk, since this is the next thing the kernel will do once rootfs is setup. Here are the steps our init has to do:
    1. Mount procfs to /proc, so we can read kernel cmdline (/proc/cmdline) to check skip_initramfs flag, and also the current boot slot
    2. If skip_initramfs flag detected, it means we need to boot to system not recovery. Remove everything in rootfs (we will add in contents later)
    3. Mount sysfs to /sys, so we can access block uevents. Traverse and parse /sys/dev/block/*/uevent, until we found the major and minor node id for target system partition (with the correct slot)
    4. Make a new device block under /dev based on the major and minor id we got in the last step, and mount it to /system_root
    5. Copy everything in /system_root (except /system_root/system, obviously) to rootfs. These are the actual files and folders for rootfs
    6. Bind mount /system_root/system to /system, so the contents for the actual system is actually in the correct place
    7. Finally, execute /init (which should be the one copied from system partition)
    At this point, the device will properly boot up, but it is pure stock without any modifications. You might notice that I didn't mention the dtb patch anywhere, because is not actually necessary. The only thing it does is to make init mount /vendor without dm-verity. The kernel thinks it is booting to recovery, so it will not handle mounting the system and verify the partition.
    It took me nearly 3 full days to get to this stage, and this is the most difficult part in porting Magisk to first gen Pixel. If anyone can find a way to this stage, it will definitely help a lot!

    Regarding Pixel 2, people can start with the same steps I've went through: the first step would be making the device to boot into recovery as we need to force the kernel to think it is booting into recovery mode.
    I have checked the posts above, people have mentioned AVB 2.0. I do not have a device on hand and haven't checked any code yet (I'm no expert in AOSP and kernel code reviewing, people can help me out with this), but I don't think AVB will be enforced in recovery mode. We need to transfer all the heavy work for booting up the device to our modified init binary, which are the steps I've mentioned above.
    The code for the modified init binary is located here: magiskinit.c. Note that this code also contains a large portion that is not related to the procedures mentioned above, they are stuffs to bring up Magisk, which I will continue to explain in detail in the following passage.
    But please note our primary goal should be: make the kernel load rootfs from ramdisk, and boot up properly.

    The following is just for information for developers to know what steps to continue once previous stages have been overcome.

    To add some Magisk magic, we need to add files into rootfs. A new folder named overlay is created, and new files (init.magisk.rc and sbin/magisk) are added into the folder. magiskinit will skip this folder when it is cleaning rootfs (the second step in the list above). Before the last step, we move all files in the overlay folder to root. So now we have a device that can properly boot, with a few additional files in rootfs.

    Next we need to tackle selinux. Usually, a monolithic sepolicy binary is placed in root directory in ramdisk, so logically it is expected that sepolicy should be in the root folder in system partition. However the first gen Pixel doesn't (fun fact: a similar device with A/B partition - Xiaomi A1 actually does place sepolicy in system root folder, just as expected). Instead, it splits the policies into several parts: platform policies (placed in system), non-platform policies (placed in vendor), mappings (placed in system) in Common Intermediate Language (CIL) format. The stock init binary will detect there is split policies available, so it will compile these cil files and load them as selinux policies. In reality though, Google have shipped a precompiled sepolicy in vendor, so init will load that instead.
    We do not want to modify system or vendor, what can we do before init loads the stock policies? We either patch the precompiled sepolicy or compile the split cil files, and then dump the complete stock policies along with new rules into a monolithic binary to /sepolicy. We then have to patch the stock init (which is possible, since it is now copied to rootfs, not in the actual system partition) to always load from /sepolicy, not anywhere else.

    The final step is to load the rc scripts to launch Magisk daemon. We inject a new line into the init.rc (same as /init, it is copied to rootfs so we are not modifying system), and things are all done!
    To summarize, in addition to the list above, before we execute /init to give control back, we still need to do these to start Magisk:
    1. Patch init binary to not load from split or precompiled policies
    2. Inject a new line in init.rc to load init.magisk.rc
    3. Parse sysfs to create node for vendor block (same as step 3 above), and mount vendor
    4. Load / compile sepolicy, and dump monolithic sepolicy to root folder
    5. Finally execute /init

    Conclusion, since magiskinit have done so much, patching a Pixel boot image with Magisk support is actually much easier than normal traditional devices! We only need to
    • Hex patch kernel to never skip_initramfs
    • For ramdisk: Replace init with magiskinit; add two files: overlay/init.magisk.rc, overlay/sbin/magisk
    • (Optional): Patch dtb to remove vendor dm-verity

    That's all! Hope people has a more clear idea to start working with Pixel 2 :)
    40
    So the point of this thread is to try to get Magisk working on the new Pixel 2 phones. This might also pertain to other new phones that use A/B slots. This thread should be used for useful discussion only, in order to try to keep each post useful and informative. Please do not post saying it's not working for you either, or that you have a phone if testers are needed.

    In this post I will summarize all that we've learned from the thread in the Pixel 2 XL forum.

    Notes
    • TWRP does not exist for this device, so any attempt at using Magisk must be done with the new option of patching a stock boot image.
    • Since we do not have root or recovery, no Magisk logs can be obtained.
    • Here is the stock boot image and here is the Magisk 14.3 patched boot image
    • This may be the first time we have had a device use Android Verified Boot version 2 (which confusingly uses the avbtool currently versioned 1 .0.0) instead of normal verity. The following links 1 and 2 contains a TON of information from google on avb.
      Note@Chainfire alluded to Android moving towards avbtool when he made the boot signing zip earlier this year.
      Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images.
    • Here is the content of
      Code:
      fastboot getvar all
      Code:
      (bootloader) keep_efs:no
      (bootloader) is_oem_unlocked:yes
      (bootloader) have_oem_lock_id:yes
      (bootloader) avb_stored_rollback_indexes:
      (bootloader) avb_user_settable_key_set:no
      (bootloader) avb_version:1.0.0
      (bootloader) hw-color:VB
      (bootloader) hw-variant:GA00137-US
      (bootloader) hw-revision:rev_10
      (bootloader) cid:00000000
      (bootloader) erase-block-size:0x1000
      (bootloader) logical-block-size:0x1000
      (bootloader) unlocked:yes
      (bootloader) off-mode-charge:1
      (bootloader) battery-soc-ok:yes
      (bootloader) battery-voltage:4379
      (bootloader) version-laf:0.0.16
      (bootloader) version-baseband:g8998-00122-1708311414
      (bootloader) version-bootloader:TMZ10n
      (bootloader) version-abl:TMZ10n
      (bootloader) version-aes:TMZ10n
      (bootloader) version-cmnlib:TMZ10n
      (bootloader) version-cmnlib64:TMZ10n
      (bootloader) version-devcfg:TMZ10n
      (bootloader) version-hyp:TMZ10n
      (bootloader) version-keymaster:TMZ10n
      (bootloader) version-pmic:TMZ10n
      (bootloader) version-rpm:TMZ10n
      (bootloader) version-xbl:TMZ10n
      (bootloader) variant:MSM UFS
      (bootloader) partition-type:laf_b:raw
      (bootloader) partition-size:laf_b: 0x3000000
      (bootloader) partition-type:laf_a:raw
      (bootloader) partition-size:laf_a: 0x3000000
      (bootloader) partition-type:dtbo_b:raw
      (bootloader) partition-size:dtbo_b: 0x800000
      (bootloader) partition-type:dtbo_a:raw
      (bootloader) partition-size:dtbo_a: 0x800000
      (bootloader) partition-type:boot_b:raw
      (bootloader) partition-size:boot_b: 0x2800000
      (bootloader) partition-type:boot_a:raw
      (bootloader) partition-size:boot_a: 0x2800000
      (bootloader) partition-type:vendor_b:ext4
      (bootloader) partition-size:vendor_b: 0x1F400000
      (bootloader) partition-type:vendor_a:ext4
      (bootloader) partition-size:vendor_a: 0x1F400000
      (bootloader) partition-type:persist:ext4
      (bootloader) partition-size:persist: 0x2000000
      (bootloader) partition-type:userdata:ext4
      (bootloader) partition-size:userdata: 0x1C26BFB000
      (bootloader) partition-type:system_b:ext4
      (bootloader) partition-size:system_b: 0xA0000000
      (bootloader) partition-type:system_a:ext4
      (bootloader) partition-size:system_a: 0xA0000000
      (bootloader) has-slot:laf:yes
      (bootloader) has-slot:bootloader:yes
      (bootloader) has-slot:vendor:yes
      (bootloader) has-slot:dtbo:yes
      (bootloader) has-slot:vbmeta:yes
      (bootloader) has-slot:cmnlib64:yes
      (bootloader) has-slot:cmnlib:yes
      (bootloader) has-slot:keymaster:yes
      (bootloader) has-slot:devcfg:yes
      (bootloader) has-slot:hyp:yes
      (bootloader) has-slot:pmic:yes
      (bootloader) has-slot:abl:yes
      (bootloader) has-slot:rpm:yes
      (bootloader) has-slot:tz:yes
      (bootloader) has-slot:xbl:yes
      (bootloader) has-slot:radio:yes
      (bootloader) has-slot:modem:yes
      (bootloader) has-slot:system:yes
      (bootloader) current-slot:a
      (bootloader) has-slot:boot:yes
      (bootloader) slot-retry-count:b:0
      (bootloader) slot-unbootable:b:no
      (bootloader) slot-successful:b:no
      (bootloader) slot-retry-count:a:6
      (bootloader) slot-unbootable:a:no
      (bootloader) slot-successful:a:yes
      (bootloader) slot-count:2
      (bootloader) slot-suffixes:a,b,
      (bootloader) secure:yes
      (bootloader) serialno:
      (bootloader) product:taimen
      (bootloader) max-download-size:0x20000000
      (bootloader) kernel:uefi
      all: 
      finished. total time: 0.004s

    Magisk 14.0 Results
    Using Magisk 14.0 results in a patched boot image that does in fact boot up, but Magisk Manager 5.3 and 5.4 both report that Magisk is not installed and that the device is not rooted. Not much else was attempted with 14.0 because I believe a lot of things for a/b devices were added after 14.0 were released.

    Magisk 14.3 Results
    Using Magisk 14.3 results in a patched boot image that bootloops the device at the initial splash screen. It should be noted that the reboot happens before the abd daemon is started, so adb logcat is not possible.

    Differences between Pixel 1 and 2
    • After Magisk is ran on a stock Pixel 1 image, the kernel (zImage) is modified in 2 ways. The first change patches "skip_initramfs" to "want_initramfs". The second is that all instances of verity are removed by searching for and removing "verify" in the dtb (fstab). With the Pixel 2, the change to initramfs still happens, but because the boot image does not contain the dtb file, no changes to verify happen (more on this below). Relevant link from google. .
    • /system in the Pixel 1 file system was squashfs. With Pixel 2, now using ext4. However, system no longer is mounted with verify, but instead with avb
      Code:
      system       /           ext4        ro,barrier=1            wait,slotselect,avb
    • /vendor no longer shows up in the fstab in pixel 2. Instead this information appears to be in dtbo.img and is also mounted with avb. Pixel 1 did not have vendor mounted with avb (it was using verify).
      I looked at dtbo.img in a hex editor and you can see references to avb around the reference to vendor.
      Relevant dtsi

      Code:
      &firmware_android {
      	compatible = "android,firmware";
      	vbmeta {
      		compatible = "android,vbmeta";
      		parts = "vbmeta,boot,system,vendor,dtbo,laf";
      		by_name_prefix = "/dev/block/platform/soc/1da4000.ufshc/by-name";
      	};
      	fstab {
      		compatible = "android,fstab";
      		vendor {
      			compatible = "android,vendor";
      			dev = "/dev/block/platform/soc/1da4000.ufshc/by-name/vendor";
      			type = "ext4";
      			mnt_flags = "ro,barrier=1";
      			fsmgr_flags = "wait,slotselect,avb";
      		};
      		persist {
      			compatible = "android,persist";
      			dev = "/dev/block/platform/soc/1da4000.ufshc/by-name/persist";
      			type = "ext4";
      			mnt_flags = "nosuid,nodev,noatime,barrier=1";
      			fsmgr_flags = "wait";
      		};
      	};
      };

    What we have tried doing
    • Running fastboot boot patched_boot.img (instead of flash). Same result - bootloop.
    • Modifying the ramdisk to change some ro variables such as ro.secure to 0 and ro.debuggable to 1. These changes to default.prop do not take effect after booting up.
    • Using Magisk 14.3 on the latest 8.1 developer preview (same results as 8.0) - bootloop
    • Modifying the patched boot image to not change "skip_initramfs" to "want_initramfs". This no longer caused a bootloop, but also resulted in an unrooted phone. Nothing of interest shows up int he logcat since we actually need the initramfs code to execute in order to root the phone/have anything happen.
    • Using a modified kernel that removed the avb/verity checks (along with a patched dtbo.img) and then using that modified kernel as an input to magisk. We were able to actually get it booted, but again, no root. Other attempts resulted in a bootloop (most likely because of initramfs). For further details on the kernel modifications made and tested please see the post by @DespairFactor
    • After (hopefully) patching out verity/avb checking, making the changes to prop.default in the ramdisk for ro.secure and ro.debuggable. Still don't show up when booted.

    Hoping we might get some input from @topjohnwu or @Didgeridoohan
    14
    Sorry for the lack of support for developers here. I'll start actively working on Pixel 2 support, developers might receive PMs from me in the upcoming days :)
    I've spent all my precious free time on optimizing Magisk. The latest upstream changes might confuse developers working on Magisk, so I think I would leave some notes here.

    As stated in my long post in this thread, you should all know that the Magisk setup for Pixel (or devices with skip_initramfs in general) and non-Pixel devices differs quite significantly. The latest commit changes this fact: all devices in the future will install Magisk in the complete same configuration - that is replacing init with a new binary called monogisk.

    Monogisk is a monolithic binary that has magisk, magiskinit, and init.magisk.rc compressed and embedded. What it only does is decompress and dump these three files into the correct places, and will give control to magiskinit ASAP. Things are done this way to make the installation more elegant, and it's a result of my "over-optimization" and "perfectionism". You shouldn't need to pay too much attention to this part, as the adjustments are done mostly in boot patch scripts and build scripts. What you should know is that after this change, installing Magisk is as simple as replacing /init in boot image with monogisk (and a ramdisk backup is required on non-Pixel devices, this has been done for nearly a year), no more overlay folder, no more sepolicy patch. Super simple.

    The most important changes are done in magiskinit (now moved to jni/init/magiskinit.c) to be adjusted to also run on non-Pixel devices. These changes result in the fact that most of the ramdisk patches will be handled on-the-fly each time a device boots up, not done directly into ramdisk in boot image.

    These updates might not affect skip_initramfs devices, but the quite drastic changes might confuse a few developers, so this post is to clarify the new situation.
    A simple documentation are done in the beginning of magiskinit and monogisk source code, you can check them out along with the code :)
    10

    So the point of this thread is to try to get Magisk working on the new Pixel 2 phones. This might also pertain to other new phones that use A/B slots. This thread should be used for useful discussion only, in order to try to keep each post useful and informative. Please do not post saying it's not working for you either, or that you have a phone if testers are needed.

    In this post I will summarize all that we've learned from the thread in the Pixel 2 XL forum.

    Notes
    • TWRP does not exist for this device, so any attempt at using Magisk must be done with the new option of patching a stock boot image.
    • Since we do not have root or recovery, no Magisk logs can be obtained.
    • Here is the stock boot image and here is the Magisk 14.3 patched boot image
    • This may be the first time we have had a device use avb version 2 (which uses the avbtool) instead of normal verity. The following link contains a TON of information from google on avb. @Chainfire alluded to Android moving towards avbtool when he made the boot signing zip earlier this year.
    • Here is the content of
      Code:
      fastboot getvar all
      Code:
      (bootloader) keep_efs:no
      (bootloader) is_oem_unlocked:yes
      (bootloader) have_oem_lock_id:yes
      (bootloader) avb_stored_rollback_indexes:
      (bootloader) avb_user_settable_key_set:no
      (bootloader) avb_version:1.0.0
      (bootloader) hw-color:VB
      (bootloader) hw-variant:GA00137-US
      (bootloader) hw-revision:rev_10
      (bootloader) cid:00000000
      (bootloader) erase-block-size:0x1000
      (bootloader) logical-block-size:0x1000
      (bootloader) unlocked:yes
      (bootloader) off-mode-charge:1
      (bootloader) battery-soc-ok:yes
      (bootloader) battery-voltage:4379
      (bootloader) version-laf:0.0.16
      (bootloader) version-baseband:g8998-00122-1708311414
      (bootloader) version-bootloader:TMZ10n
      (bootloader) version-abl:TMZ10n
      (bootloader) version-aes:TMZ10n
      (bootloader) version-cmnlib:TMZ10n
      (bootloader) version-cmnlib64:TMZ10n
      (bootloader) version-devcfg:TMZ10n
      (bootloader) version-hyp:TMZ10n
      (bootloader) version-keymaster:TMZ10n
      (bootloader) version-pmic:TMZ10n
      (bootloader) version-rpm:TMZ10n
      (bootloader) version-xbl:TMZ10n
      (bootloader) variant:MSM UFS
      (bootloader) partition-type:laf_b:raw
      (bootloader) partition-size:laf_b: 0x3000000
      (bootloader) partition-type:laf_a:raw
      (bootloader) partition-size:laf_a: 0x3000000
      (bootloader) partition-type:dtbo_b:raw
      (bootloader) partition-size:dtbo_b: 0x800000
      (bootloader) partition-type:dtbo_a:raw
      (bootloader) partition-size:dtbo_a: 0x800000
      (bootloader) partition-type:boot_b:raw
      (bootloader) partition-size:boot_b: 0x2800000
      (bootloader) partition-type:boot_a:raw
      (bootloader) partition-size:boot_a: 0x2800000
      (bootloader) partition-type:vendor_b:ext4
      (bootloader) partition-size:vendor_b: 0x1F400000
      (bootloader) partition-type:vendor_a:ext4
      (bootloader) partition-size:vendor_a: 0x1F400000
      (bootloader) partition-type:persist:ext4
      (bootloader) partition-size:persist: 0x2000000
      (bootloader) partition-type:userdata:ext4
      (bootloader) partition-size:userdata: 0x1C26BFB000
      (bootloader) partition-type:system_b:ext4
      (bootloader) partition-size:system_b: 0xA0000000
      (bootloader) partition-type:system_a:ext4
      (bootloader) partition-size:system_a: 0xA0000000
      (bootloader) has-slot:laf:yes
      (bootloader) has-slot:bootloader:yes
      (bootloader) has-slot:vendor:yes
      (bootloader) has-slot:dtbo:yes
      (bootloader) has-slot:vbmeta:yes
      (bootloader) has-slot:cmnlib64:yes
      (bootloader) has-slot:cmnlib:yes
      (bootloader) has-slot:keymaster:yes
      (bootloader) has-slot:devcfg:yes
      (bootloader) has-slot:hyp:yes
      (bootloader) has-slot:pmic:yes
      (bootloader) has-slot:abl:yes
      (bootloader) has-slot:rpm:yes
      (bootloader) has-slot:tz:yes
      (bootloader) has-slot:xbl:yes
      (bootloader) has-slot:radio:yes
      (bootloader) has-slot:modem:yes
      (bootloader) has-slot:system:yes
      (bootloader) current-slot:a
      (bootloader) has-slot:boot:yes
      (bootloader) slot-retry-count:b:0
      (bootloader) slot-unbootable:b:no
      (bootloader) slot-successful:b:no
      (bootloader) slot-retry-count:a:6
      (bootloader) slot-unbootable:a:no
      (bootloader) slot-successful:a:yes
      (bootloader) slot-count:2
      (bootloader) slot-suffixes:a,b,
      (bootloader) secure:yes
      (bootloader) serialno:
      (bootloader) product:taimen
      (bootloader) max-download-size:0x20000000
      (bootloader) kernel:uefi
      all: 
      finished. total time: 0.004s

    Magisk 14.0 Results
    Using Magisk 14.0 results in a patched boot image that does in fact boot up, but Magisk Manager 5.3 and 5.4 both report that Magisk is not installed and that the device is not rooted. Not much else was attempted with 14.0 because I believe a lot of things for a/b devices were added after 14.0 were released.

    Magisk 14.3 Results
    Using Magisk 14.3 results in a patched boot image that bootloops the device at the initial splash screen. It should be noted that the reboot happens before the abd daemon is started, so adb logcat is not possible.

    Differences between Pixel 1 and 2
    • After Magisk is ran on a stock Pixel 1 image, the kernel (zImage) is modified in 2 ways. The first change patches "skip_initramfs" to "want_initramfs". The second is that all instances of verity are removed by searching for and removing "verify" in the dtb (fstab). With the Pixel 2, the change to initramfs still happens, but because the boot image does not contain the dtb file, no changes to verify happen (more on this below). Relevant link from google. .
    • /system in the Pixel 1 file system was squashfs. With Pixel 2, now using ext4. However, system no longer is mounted with verify, but instead with avb
      Code:
      system       /           ext4        ro,barrier=1            wait,slotselect,avb
    • /vendor no longer shows up in the fstab in pixel 2. Instead this information appears to be in dtbo.img and is also mounted with avb. Pixel 1 did not have vendor mounted with avb (it was using verify).
      I looked at dtbo.img in a hex editor and you can see references to avb around the reference to vendor.
      Relevant dtsi

      Code:
      &firmware_android {
      	compatible = "android,firmware";
      	vbmeta {
      		compatible = "android,vbmeta";
      		parts = "vbmeta,boot,system,vendor,dtbo,laf";
      		by_name_prefix = "/dev/block/platform/soc/1da4000.ufshc/by-name";
      	};
      	fstab {
      		compatible = "android,fstab";
      		vendor {
      			compatible = "android,vendor";
      			dev = "/dev/block/platform/soc/1da4000.ufshc/by-name/vendor";
      			type = "ext4";
      			mnt_flags = "ro,barrier=1";
      			fsmgr_flags = "wait,slotselect,avb";
      		};
      		persist {
      			compatible = "android,persist";
      			dev = "/dev/block/platform/soc/1da4000.ufshc/by-name/persist";
      			type = "ext4";
      			mnt_flags = "nosuid,nodev,noatime,barrier=1";
      			fsmgr_flags = "wait";
      		};
      	};
      };

    What we have tried doing
    • Running fastboot boot patched_boot.img (instead of flash). Same result - bootloop.
    • Modifying the ramdisk to change some ro variables such as ro.secure to 0 and ro.debuggable to 1. These changes to default.prop do not take effect after booting up.
    • Using Magisk 14.3 on the latest 8.1 developer preview (same results as 8.0) - bootloop
    • Modifying the patched boot image to not change "skip_initramfs" to "want_initramfs". This no longer caused a bootloop, but also resulted in an unrooted phone. Nothing of interest shows up int he logcat since we actually need the initramfs code to execute in order to root the phone/have anything happen.
    • Using a modified kernel that removed the avb/verity checks (along with a patched dtbo.img) and then using that modified kernel as an input to magisk. We were able to actually get it booted, but again, no root. Other attempts resulted in a bootloop (most likely because of initramfs). For further details on the kernel modifications made and tested please see the post <placeholder> by @DespairFactor
    • After (hopefully) patching out verity/avb checking, making the changes to prop.default in the ramdisk for ro.secure and ro.debuggable. Still don't show up when booted.

    Hoping we might get some input from @topjohnwu or @Didgeridoohan



    On kernel side to remove verity from vendor, I removed the vbmeta struct code from both the LGE/HTC dtsi files and removed the avb flag from vendor, this will compile a dtbo.img without verity flags on it. Furthermore, I have tried to force initramfs not to be skipped at the source level, this causes it to boot into recovery only.

    Next steps were hex patching the kernel image without verity at source level, this causes bootloops still as the hex patch applies something to the image causing the bootloops. I haven't done a full diff on what occurs when we completely repack the image, but if we swap the kernel image after a repack from magisk, it boots fine. The problem is only encountered with the hex patch. When the device boots without the hex patch, root is nowhere to be found, which leaves us wondering why the patch is needed if this code is all manipulated at the source level.

    There could be potential issues or missing things that could deliver the payload, but currently we are able to bypass verity, it seems. If anyone has any information or suggestions how to deliver the payload at this state, it could help advance the status of getting root onto this device.