No Summary or explanations
I marked this article for expansion. There is no summary what is actually done in detail. There is especially some explanation missing in where the bootloader is installed now ((hd0,0) is what? iSCSI?). I personally think (hd0) is still some local device. (This should be specified) Maybe /boot is local, too. Even if not, this should be explicitly told. --JonnyJD
No, the bootloader is installed to the iSCSI disk. No local disk is needed. For simplicity it is advised to setup the iscsi disk with a single root partition. --lrusak
Effects of doing this on the systemd open-iscsi.service
I'm trying to develop an equivalent to this for SRP booting. It's a remote DMA over InfiniBand (very high speed network) protocol. It's faster than iSCSI, even running across InfiniBand. iPXE supports it. I've gotten as far as loading the kernel and initramfs, but then it doesn't go much further. SRP is done with a LIO Target, using targetcli-fb. It will be a very similar process to this.
Trying to wrap my head around iSCSI booting, first.
Obviously the iSCSI target has to be connected to in the initramfs. But, it's not making any sense to me if it happens there and open-iscsi is installed on the system, what happens with the systemd open-iscsi.service? If you only have the one iSCSI target that you're having the initramfs load, do you leave the open-iscsi systemd service disabled? If you have multiples, do you enable the systemd service, and just not configure it to connect to any targets the initramfs loaded? Or, does the initramfs iSCSI connection get undone somehow, and does the systemd service need to do it again? (Yes, this is my first time working with the internals of the initramfs/mkinitcpio.) Jamespharvey20 (talk) 06:33, 8 January 2016 (UTC)
If installed this way will a regular bootloader not be needed? Does a capable nic or iPXE take the place of a bootloader?
The grammar in this article is pretty terrible, making the text difficult to follow. I'm improving it section-by-section, but what I'm more worried about is the technical section(s). I'm working with iSCSI myself, so I'm willing to rewrite and rework the sections to be clearer and correct, if I find any inaccuraries.
The shutdown issue is not addressed
There is only a brief mention of needing to make sure your network manager doesn't shut down too early. This is actually a quite complex problem as things like networkd stop very early in the shutdown process which can lead to data loss. Even if you remove the shutdown dependencies for networkd there is still journald running at the very end of shutdown which causes a hang and data loss due to the filesystem not being available.
Other distributions usually handle this automatically but with Arch needing manual configuration this seems like it needs more than a short offhand mention of the problem.