You can still boot from any patched FPOS boot.img you have lying around and install Magisk the same way as before.
But if you really need it, here is a vanilla boot_A.099.img and a patched boot_A.099_magisk.img.
Don’t flash them (if you don’t have a good reason to), just boot from the patched one and follow the regular tutorial.
Thank you very much.
I assumed that booting the patched boot would cause Magisk to patch this version. I thus later have an older boot version with Magisk running.
Am I wrong?
When you fastboot boot the patched boot.img all you are doing is temporarily booting from that image. That means, the boot.img gets sent over to your device, loaded into RAM and the phone starts from there, instead of the regular boot partition.
That way we can start the FP safely from a modified boot.img without actually modifying the underlying OS. If something doesn’t work, everything should be back to normal after a reboot.
While booted from that image we have root privileges available to us and we use those to install Magisk through the app. Magisk patches the real boot partition directly and after a reboot we have a working Magisk installation.
You can of course flash a matching patched boot.img directly, but this route is safer. It doesn’t matter if you picked the right image or accidentally flashed some wrong version to your device and end up in a bootloop. You don’t have to think about the slot you are in, did you actually pull the right boot.img from your device to patch etc.
And don’t get me started on the minefield that is “Android Verified Boot”… 
Is it possible to stay in temporary root or you have to let magisk patch te boot that installed. It would be nice to try with the option to go back to the original if needed?
Depends on what you want to use root for 
Temporary root is great for getting stuff off of a phone you otherwise don’t want to change. I use it to dump unmodified versions of system files from the FP4 of a family member. So I always have a clean reference device around to check against my modified one.
If you want to do anything related to Magisk modules, microG, changing system parameters or in general modify the system without actually installing Magisk, temporary root is not for you. That can get bootloopy pretty fast 
A reboot will bring you back to the original boot partition, but you absolutely can get your system to a state that’s not compatible with that partition anymore. And a reboot can happen anytime by accident…
This is only a safe space to play in if you don’t mess with the underlying system.
I dont know why, but I am not able to root my iodé FP4. I am in the step to boot my patched-magisk-boot-image. I wait more than 20 minutes. It does not boot.
And the strange thing is that I can not boot the normal boot-img either…
You didn’t mention you are running iodé, those are boot images for vanilla FPOS, there is a difference 
I’ll have to extract a iodé boot.img, give me a minute.
Edit: OK, here’s a patched boot.img for iodé. I patched the latest one available (20220126), but I have no way of testing it (not running iodé myself). So whatever you do, I strongly suggest you only boot from it and don’t flash it.
Oke thanks for the answer, I normally rooted my devices to make better use of macrodroid for example. Or use widgets to switch data and location options. To do that directly root is the easiest. I think it’s better to wait to get back to the original ROM I don’t want to make my mobile unusable and wait till there is an option to flash the original ROM back.
Thank’s a lot @hirnsushi for sharing all this. Would you describe how you got hold of the A.099 image? It doesn’t seem to be available for download from storage.googleapis.com, guess you extracted it from your phone after the OTA update - but how?
Sure 
First of all, you need root for this, so I fastboot booted a vanilla FP4 with the newest update already applied using a patched Magisk boot.img I already had (the version of the boot.img mostly doesn’t matter for this).
Then it’s only a matter of getting the image from the device:
foo@bar:~$ adb shell
FP4:/ $ getprop ro.boot.slot_suffix
_a
FP4:/ $ su
FP4:/ # dd if=/dev/block/by-name/boot_a of=/sdcard/Download/boot_a.img
196608+0 records in
196608+0 records out
100663296 bytes (96 M) copied, 0.759143 s, 126 M/s
FP4:/ # exit
FP4:/ $ exit
foo@bar:~$ adb pull /sdcard/Download/boot_a.img
/sdcard/Download/boot_a.img: 1 file pulled, 0 skipped. 34.6 MB/s (100663296 bytes in 2.771s)
Normally I would use shorter commands, this is quite verbose, but I hope it’s easier to understand this way. If you don’t understand some of the commands, just ask 
There’s also the possibility to extract the image directly to a PC using adb exec-out, but there are some major caveats involved.
Nice, thanks! And quite straight 
Sorry for getting a bit OT: Just deactivated my self written magisk module (which overlays /vendor/etc/mixer_paths_lagoon_fp4.xml), then booted your boot_A.099_magisk.img and checked content of mixer_paths_lagoon_fp4.xml. The file is obviously broken, and now I wonder if that’s something caused by myself, or if it’s actually broken right in the stock image.
For me, the file “starts over” at line 706, breaking XML syntax. Snippet of lines 700-710:
<path name="low-latency-playback display-port1">
<ctl name="DISPLAY_PORT1 Mixer MultiMedia5" value="1" />
</path>
<path name="low-latency-playback bt-sco">
<ctl name="SLIMBUS_7_RX Audio Mix<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- Copyright (c) 2015-2020, The Linux Foundation. All rights reserved. -->
<!-- -->
<!-- Redistribution and use in source and binary forms, with or without -->
<!-- modification, are permitted provided that the following conditions are -->
<!-- met:
Can anybody confirm this observation?
(I’m interested in that file because of Microphone quality of the FP4 when using Signal (low volume))
I just checked mixer_paths_lagoon_fp4.xml on A.094 & A.099 builds.
Both are identical and don’t show that behaviour
Here’s a unmodified version if you need it
Thanks, and sorry for the noise. Seems to be an issue related to KDE Connect (that’s how I usually access files on the phone). When viewing the identical file with an XML app installed on the phone, or cat in adb shell, it looks correct.
Huh, good to know, I’m a KDE Connect user as well. Might be related to the file beeing that long. Maybe the connection get’s reset somewhere in between. Let’s keep an eye on it and raise a bug report if it happens again.
I usually adb pull important files from my devices or work directly in the terminal on device, other ways have always been a bit error prone.
I do not have a FP4 yet, but I consider to buy one with preinstalled /e/OS and I want to root it.
(Currently I have a FP2 with LineageOS 17.1, rooted by Magisk.)
But there is a point I don’t understand for rooting the FP4 with /e/OS by Magisk.
The FP4 is an A/B device, right? The manual of Magisk at https://www.xda-developers.com/how-to-install-magisk/ says, that for an A/B device I need to extract a file just named “boot” from a file named “payload.bin” which I first have to extract from the recovery-flashable ZIP file.
But the ZIP file of /e/OS for the FP4 only contains files with .img suffixes. (With “boot.img” also, of course, but that should be for A-only devices, says the manual.)
Where can I get the file “boot” from?
The /e/ .zip contains disk images you have to manually flash to your device, rather than a OTA style install where you flash a ota.zip containing payload.bin through recovery (iode are using that method for example)
If you follow the /e/ install instructions carefully, you will see, that they actually flash that one boot.img to both slots.
So, you can just use the boot.img that comes with the /e/ .zip
That’s wonderful. Thank you for the clarification, hirnsushi!
Just wanted to leave a big thank you in here for all of you.
I flashed /e/ os yesterday on my new FP4, stupidly thinking it would be rooted automatically.
After reading all the posts in here I could easily patch the /e/ os boot image on my phone, boot this image and then install magisk.
I will now try out the phone, but so far everything seems to just work!
Since there is a way to revert back to the original ROM rooting would be more safe I guess?
Pretty much as safe as before (if you backed up the original partitions).
This might still eat your data, so make sure you have a reliable system in place to automatically safe your data off device (something like syncthing). With that in place, go ahead and have fun