You are not logged in.

#1 2016-01-08 05:02:44

jamespharvey20
Member
Registered: 2015-06-09
Posts: 129

mkinitcpio runtime hooks & systemd services - related to iSCSI booting

(Mods, feel free to move, maybe this belongs in "System Administration" or "Creating & Modifying Packages".)

I'm writing a new AUR package, mkinitcpio-srp.  It's for using SRP (remote hard drive DMA over InfiniBand which is a very high speed network) and diskless booting.

I'm sort of modeling after https://wiki.archlinux.org/index.php/ISCSI_Boot because that's also for a diskless boot, although it uses a non-DMA method using TCP, and often has nothing to do with InfiniBand (it can, but SRP is much more efficient than iSCSI when you have InfiniBand.)

So, my mkinitcpio runtime hook is going to do a few things:
* modprobe several InfiniBand-related kernel modules
* Configure and bring up the InfiniBand network
* Run a program to mount the remote hard drive as a new /dev/sdX device

These are all things I've been doing for an install on a local hard drive, to then use SRP to remotely mount as extra drives.  I maintain the AUR packages "rdma", "srptools", "ipoibmodemtu", and a few others that I've been using to do these things for the local hard drive install.

Now that this is all getting moved into a mkinitcpio runtime hook, I'm confused.  If I do these things in the hook, and I also install the packages that have systemd services that do these things, they'd be done twice.

How is that handled?  Does a systemd service need to detect that things it would do were already done?  Are things like loaded kernel modules somehow left behind, and do they need to be done again by the time you get to the systemd service?


Basically, my question is very similar to asking if I were following the directions at https://wiki.archlinux.org/index.php/ISCSI_Boot to boot off iSCSI, would I still use a systemd service to load the iSCSI kernel modules and connect to the targets?

Last edited by jamespharvey20 (2016-01-08 06:12:20)

Offline

Board footer

Powered by FluxBB