Boot services tend to fail in the middle when the kernel loads a sepolicy live.
It seems that moving full patch (allow magisk * * *) to late_start is still not enough to fix service startup failures.
So screw it, apply all patched in magiskinit, which makes sure that all rules are only loaded in a single step.
The only down side is that some OEM with a HUGE set of secontexts (e.g. Samsung) might suffer a slightly longer boot time, which IS the reason why the rules are split to 2 parts in the first place.
In previous versions, magiskinit will not early mount if /sepolicy is detected. However on OP5/5T latest betas, the devices are fully trebelized,
but for some reason the file /sepolicy still exists, making magiskinit think it is NOT a treble device and doesn't work properly.
So to properly fix this issue, I will have to use the "official" way - check fstab in device trees. Any block mentioned in the fstab in device trees
are supposed to be early mounted. Currently magiskinit will only mount system and vendor even if other partitions exists in the dtb fstab, since other
partitions are not used to construct sepolicy (currently).
These changes can also fix#373, since we dynamically detect PARTNAME from device trees.
1. Introduce new applet: imgtool for better separation from the main program
2. Actually mount the image and check statvfs for free space in the image
This shall eliminate any possible module installation failure from image resizing issues.
The &cmd will return a pointer which point to a pointer of cmdline.
It is a memory address which is usually 8 bytes in 64 bits machine.
However, the struct cmdline is 4 bytes. This will cause setting zero
beyond the bound.
Below is a simple example to show the differentiation:
struct cmdline {
char skip_initramfs;
char slot[3];
};
static void parse_cmdline(struct cmdline *cmd)
{
printf("%lu\n", sizeof(*cmd)); /* 4 */
printf("%lu\n", sizeof(&cmd)); /* 8 */
}
int main()
{
struct cmdline cmd;
parse_cmdline(&cmd);
return 0;
}
This patch prevents this.
Signed-off-by: npes87184 <npes87184@gmail.com>
It's not important to check the return value of unlink(2) or even verify
that the file exists. If this code is running, it means the system has
rebooted, and thus the update file, if any, should be removed so that
MagiskManager doesn't keep displaying the same message. We also handle
this before we handle "disable" so that disabled modules don't keep
requesting a reboot to update.