I have a general idea of how the boot process works, but now that I'm customizing the initrd process, I can't wrap my mind around this.
If there's a systemd service that can connect to a remote filesystem or disk (think NFS or iSCSI), but under a set of circumstances the actions done by the systemd service has to be handled in the initrd process, how is that handled?
Do you build in a non-systemd version that does the same thing into the initrd? Then, does the systemd service need to detect that things it would do are already done, outside of it? Are things like kernel modules loaded in initrd left behind after the pivot-root process, for them to be done again by the systemd service?
Basically, my question is along the lines of if you were running a local hard drive install that was using a systemd service to mount NFS or iSCSI volumes as extra folders or devices, and you were changing your setup to a diskless boot, the things that systemd service would do (at least for anything required for booting) would have to be done in initrd. But, if you had other volumes you also wanted to mount and were still going to run the systemd service, how do you handle the configuration of the volumes alread mounted by the initrd?
I'm using systemd-networkd on my local disk install, but the initrd is going to have to bring up the network device and statically configure it or use DHCP, so what happens to using systemd-networkd? Does it no longer have a config file for the network brought up by initrd, or does it still need it? (Does the initrd config get tossed out during the pivot-root or anything like that?)
(As background for why I'm customizing, it's well documented how to do a diskless boot using iSCSI, but I want to do a diskless boot using a remote DMA protocol, SRP, so the initrd has to load the SRP kernel modules (ib_srp and more) and connect to the remote volume.)