首先我们知道init进程在运行时会调用自身，所以init进程分为stage1和stage2两个阶段，而分区挂载操作也分为两个阶段：
stage1挂载操作是利用device tree中的配置项来读取配置挂载的；stage2挂载操作则是我们常见的利用fstab配置文件来挂载的。
在Android O之后的版本中，我们知道很多ko被从kernel中提取出来，移动到system分区和vendor分区中保存。那么系统启动在服务加载之前首先需要把内核驱动模块全部加载起来才可以，所以我们的system分区和vendor分区必须要先挂载起来。
A/B system
我们知道使能了A/B system的系统，它的rootfs是集成到system.img中的，而kernel的运行必须要依赖rootfs，所以我们需要在很早就要把rootfs挂载起来，实际上UEFI在启动kernel的时候会通过cmdline传入参数告知rootfs所在分区，这样kernel就能够在一启动就可以挂载rootfs，也就是我们的system分区。熟悉嵌入式的应该知道cmdline中有root参数，比如CONFIG_CMDLINE=”root=/dev/mtdblock2…”
而对于vendor分区，由于其中包含很多厂商自己的ko，所以需要在init的stage1进行挂载，那么就需要在devicetree中进行挂载配置，init进程会去解析dtb中的相关信息并挂载对应的分区。
rootfs在system.img中，实际上system会被挂载到/目录上
system分区挂载信息有uefi通过cmdline传递给kernel，由kernel挂载
vendor分区挂载信息在dts中配置，并且有init stage1解析并挂载
Non A/B system
对于非A/B system的系统来说，rootfs是在boot.img中的，而决定rootfs在哪个分区，在android编译系统中有如下宏来决定的
BOARD_BUILD_SYSTEM_ROOT_IMAGE=false如上所示，这样配置的系统，将会吧ramdisk编译到boot.img中。这样uefi启动时只需要传入boot.img中的ramdisk作为rootfs即可启动kernel。而对于其他非root分区的挂载则有init进程来完成。既然是init来完成，那么就涉及到stage1和stage2两个阶段了。
对于system/vendor这两个分区来说，由于其中包含有很多ko以及selinux配置，所以必须要在stage1完成挂载，然后才能进行后续的服务启动。所以system/vendor的挂载配置需要在devicetree中进行配置。
rootfs在boot.img中
system分区挂载信息在dts中配置，并且有init stage1解析并挂载
vendor分区挂载信息在dts中配置，并且有init stage1解析并挂载
devicetree分区配置
一般来说，我们理解的devicetree中的配置都是给kernel使用的，但是这里需要我们特别注意的是，devicetree中的分区配置并不是给kernel使用的，而是后续由init进程读取挂载分区的。
fstab中的问题
device/qcom/sdm660/fstab_AB_variant.qcom：
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/bootdevice/by-name/system / ext4 ro,barrier=1,discard wait,slotselect,avb由前文我们知道，在A/B system中，system挂载到根分区，是由UEFI传入分区配置来挂载的，在non A/B system中，system挂载在/system是由devicetree来配置完成的，无论是否采用A/B system，都不可能在fstab中挂载system分区。那么如上的配置项目为什么还存在与fstab中呢？实际上，在init/fs_mgr的实现中，它会检测并且过滤/目录的挂载，所以上述配置中的第一行实际上是没有起作用的。
备注：使能了A/B system的系统，rootfs都必须要放到system.img中，不管是哪个android版本。