Can MaaS deploy Ubuntu on an iSCSI vol as its root?


I have a bunch of Supermicro Blades that supports booting over iSCSI, or PXE as well.

If I add storage to the blades (like SATA-SSDs), I can use MaaS to PXE boot it and deploy Ubuntu.

However, I don’t want to buy SSDs for all blades! Since there is support for iSCSI boot and we have the iSCSI targets already.

So, can MaaS somehow, find the iSCSI vol while commissioning a Machine?

The only tricky part here is that, at the BIOS, I have to choose between “iSCSI Boot vs PXE Boot” (both supports UEFI), which means that I have to first, PXE boot via MaaS and deploy Ubuntu on that “drive / iSCSI” and later on, change the BIOS to “iSCSI Boot”, soon as MaaS finishes the deployment (before server’s first boot, or something like that).


BTW, the SuperMicro servers have the “Intel ISCSI Remote Boot” BIOS on it.

I can see it getting IPs from MaaS but, it can’t boot boot because it can’t find a “root”…

I guess that if MaaS Rack controller had a iSCSI Target on it, this thing would work!

MaaS Rack could then, for example, export a squashfs via iSCSI to have “live enlisting and live commissioning” phases! Then, later on, it would deploy real Ubuntu (not squashfs) on top of another iSCSI Target (not the ones from MaaS Rack (those would be used only for enlist / commision / rescue"

Is something like this on MaaS roadmap?

Hi Thiago,

MAAS doesn’t currently support using iSCSI as a root device. That would only work today if the firmware somehow would make that completely transparent to the operating system.

This has worked in the past (at least on MAAS 2.2) if the BIOS is using ‘iBFT’ (which is almost certainly is). In order to make it work, you need to add ‘iscsi_auto’ to the global kernel parameters in MAAS which instructs the initramfs to look for the iBFT information and make use of it.

In iBFT mode, the network card runs a boot service that provides BIOS level and very slow access to the disk via the NIC in order to allow the boot loader to get it’s necessary files. Once the OS boots it takes over with it’s own network connection which works at full speed. To make this work, the iBFT table is populated with the IP address and iSCSI target/IP/credentials which is used by the OS.

I had to make a patch to open-iscsi to make this work for another MAAS user in the past, the patch was that cloud-init bugged out in the presence of an iBFT booted environment due to an unexpected value in the file that describes how the network was configured by the kernel during early boot when it takes over the IP that was previously used by the boot loader. That bug was That bug also has details on how to simulate an iBFT environment using qemu in case anyone wants to test without a real such server.

However, iBFT support is not a tested or officially supported. Part of the reason it works is that until MAAS 2.3, MAAS used iSCSI to boot the ephemeral images for commissioning/deployment - thus open-iscsi was installed in those environments and supported the iscsi_auto flag (if the open-iscsi package isn’t installed when the initramfs used to boot these environments is generated, the relevant scripts will not exist to handle iBFT boot). MAAS 2.3 moved away from using iSCSI for that and it’s possible support for this might ‘accidentally’ break by having open-iscsi removed from the ephemeral images. As of right now, the images still have open-iscsi installed and I have no idea if this will change, I just generally note the disclaimer that it MAY change in the future. However, any installed machines would continue to work, the risk is that you would no longer be able to deploy new machines.

I would also note that iBFT is explicitly NOT supported by the normal Ubuntu Installer (any of the 3 versions of it) right now, however I know that this issue is also being actively worked though cannot make any promises that support will land. Though it’s mostly irrelevant for MAAS, but I thought I would mention it.



Just wanted to say thanks for this post! I’ve got some HP BL460c blades with Emulex OneConnect in a Virtual Connect Flex-10. The ‘iscsi_auto’ was the last missing piece for me to get the blades to connect and boot from some ceph iscsi gateways. Comission and Deploy worked out of the box with MAAS 2.6.2.

1 Like