Proxmox AIS Question/Request

[proxdrop]

I began looking at the new AIS tool for Proxmox installs, and it looks useful to me! Specifically, my environment would prefer to use the partition option for mounting the answer.toml file. However, the tool appears to be hardcoded to look for a partition named "proxmox-ais" or "PROXMOX-AIS" that would host it. I don't think that would work for my use case.

Currently I'm provisioning proxmox servers via Dell iDRAC and the Server Configuration Profile options Dell provides. The final steps of the configuration profiles mount the imaging (Proxmox) iso, and have the capability of mounting an answer file share. The issue is that Dell does not provide the option to change the label of this share, and it defaults to some variant of "USB".

My question is: is there a way for me/someone to change the proxmox-ais packages to support either passing the share label via command line? OR - can someone point me to the line in the file where I could potentially just swap the "proxmox-ais" string for the Dell equivalent, and then recompile? I did try looking, but was unable to locate it on github.

EDIT: Looks like its line 12 of partition.rs under proxmox-fetch-answer. Not sure how I didn't spot it before honestly.

 

[aaron]

Instead of going through the pains of modifying the automated installer, wouldn't it be easier to set up a small server that hosts the answer files and use just one ISO that fetches them?

With access to the iDrac you might even be able to further automate it as you may be able to fetch certain identifiers from the machine, such as MAC addresses or chassis serial numbers to match the answer file to the machine easily.

 

[proxdrop]

I considered redoing my build with a DHCP and webserver to host all of this. I thought just doing a simple string swap and recompiling would be easier. After an hour or two of dependency hell trying to just compile the *)(*^*(%(*&^ thing, your idea may be simpler. I was trying to avoid playing the game of "match the MAC address" but that still may be the way forward. I do like the idea of simply having 1 answer.toml per 1 SCP configuration file - it does mean iDRAC automates from out of the box (after setting the IP) straight through OS deployment. Keeps things "simple" and organized, at least in my mind, without having to maintain and update multiple other build servers.

 

[alexskysilk]

Just as a curiosity, what is the use case for this? will the dynamically spun hosts also be added to a cluster?

 

[proxdrop]

Just as a curiosity, what is the use case for this? will the dynamically spun hosts also be added to a cluster?

Eventually yes. I already have functioning Dell SCP files. The workflow would be, generate the configs (SCP, answer.toml, other networking configs), upload the SCP to iDRAC, initialize and install the server, and then have a partially built out Proxmox install I can then finish off updating and add to a cluster, configure storage, networking, ect.

Frankly the work saved by AIS isn't all *that* much, but considering I can just list the answer.toml file in the Dell scp config, and then it auto provisions and mounts a FAT32 drive to the Proxmox installer live session is pretty enticing. Its just that proxmox-ais is hard-coded to look for only one specific partition label, and not a custom partition label such as OEMDRV/oemdrv.

 

[alexskysilk]

hrm. Will you be continously spinning up hosts? Because from my vantage point the calculus isn't saving work, its PERFORMING a lot of work for very little effect.

I had thought about doing AIS deployments in the past, but in the final analysis it simply wasnt worth the effort given how infrequently I needed to (re)deploy. Within my workflow, I install PVE generically on a new node. customization is performed with a postinstall script via curl | bash. This allows me to deploy to different hardware/network stack combinations without much central maintenance, and the script is very easy to maintain.

 

[proxdrop]

Honestly my work has been a bit varied, but I tend to deploy or redeploy multiple servers every few weeks or so. You may be very right in that the juice isn't really worth the squeeze. In theory adding the answer.toml would easily slot into my current workflow perfectly, but the last 10% of the job is taking 90% of the work. This was a question I've spent a few days working on, which is already more time than its really worth. I'd love to have a workflow where I spend 15 minutes generating config files and then just firing off the script sequences, but oh well.

Fun to dig into trying to learn compiling programs and how Proxmox works, but resolving the librust dependencies has been an utter nightmare. Replacing a string definition *shouldn't* in theory be this difficult, but ah well.

 

[proxdrop]

So, update time.

It IS largely possible - I have successfully compiled the package and loaded it into a custom proxmox install ISO. The level of effort required is almost certainly not worth it for individual folks to do, though it would still be nice if it were a supported flag "out of the box". Haven't finished a full test of the workflow yet. I'm not listing it out step by step entirely, but much of the Rust compilation was tricky to execute without any clear guide.

Ultimately the "mk-build-deps --install" script failed me entirely. The problem is I couldn't replicate the Debian repository setup that others seemed to have when originally compiling the packages. My "solution" was to install Rust environment as a separate installation, disregard "mk-build-deps" entirely, then attempt running "make install" while modifying the various Cargo.toml files until I could resolve all dependency conflicts. This meant I had to modify the original pve-installer/.cargo/config.toml and comment out "[source.crates-io]" and "replace-with = "debian-packages"". This appeared to let crate handle the dependencies instead of apt. Additionally, there were quite a number of issues in the pve-installer/proxmox-fetch-answer/Cargo.toml file related to rustls, rustls-native-certs, and ureq. I had to hard-set older version levels than current release to successfully compile.

The line to change in pve-installer/proxmox-fetch-answer/src/fetch_plugins/partition.rs WAS in fact the initial definition "static PARTLABEL: &str = "proxmox-ais";". This was an easy enough change itself. I could get the package to finally compile, and running "proxmox-fetch-answer partition" showed it correctly looking for the new partition label, oemdrv/OEMDRV. This wasn't enough - the new package needs to be loaded into the actual Proxmox Install media itself. The proxmox-auto-install-assistant tool DOES NOT function how I originally thought, and does not modify the ISO with the new label.

To modify the iso, first I did run the "proxmox-auto-install-assistant tool --prepare-iso <path> --fetch-from partition" to prepare the AIS ISO in question. Then, I relied on the steps in https://forum.proxmox.com/threads/create-custom-pve-iso-from-original-pve-iso.123606/post-670528 to unpack and modify the ISO image. In the part where they unsquashed the pve-base.squashfs file, I chose the pve-installer.squashfs file. Then I copied the compiled pve-installer files from /usr/bin/proxmox* to squashfs-root/usr/bin and overwrote those there. I did pull all the files binaries starting with proxmox, hopefully to just keep things consistent, but I may have gotten away with just replacing the proxmox-fetch-answer binary instead. I then re-squashed everything, wrote a new iso, and test booted to it to verify that it now uses the updated label in proxmox-fetch-answer.

So tl;dr, aaron was right and it was really not worth the time, but I am both dumb and stubborn and got it to work. Now, to craft the actual answer.toml file...

 

[aaron]

So, I was thinking about this a bit more.
As far as I understand, you would have been happy if you could have specified the partition label on which the answer.toml file should be searched?
Because it would be one possibility to make that configurable when preparing the ISO for the auto installer. You already need to set it to look for the answer file in a partition. We could potentially add another optional parameter for the label.

The iDrac disk shows up in the /dev/disk/by-label directory?

 

[proxdrop]

I think so. Running "lsblk -o name,label" and it shows up. Here's the device info report for it:

    "sdh": {
      "CURRENT_TAGS": ":systemd:",
      "DEVLINKS": "/dev/disk/by-diskseq/19 /dev/disk/by-path/pci-0000:00:14.0-usb-0:14.4.1:1.0-scsi-0:0:0:1 /dev/disk/by-id/usb-Linux_Virtual_Floppy_1028_123456-0:1",
      "DEVNAME": "/dev/sdh",
      "DEVPATH": "/devices/pci0000:00/0000:00:14.0/usb1/1-14/1-14.4/1-14.4.1/1-14.4.1:1.0/host11/target11:0:0/11:0:0:1/block/sdh",
      "DEVTYPE": "disk",
      "DISKSEQ": "19",
      "ID_BUS": "usb",
      "ID_INSTANCE": "0:1",
      "ID_MODEL": "Virtual_Floppy",
      "ID_MODEL_ENC": "Virtual\\x20Floppy\\x20\\x20",
      "ID_MODEL_ID": "0001",
      "ID_PATH": "pci-0000:00:14.0-usb-0:14.4.1:1.0-scsi-0:0:0:1",
      "ID_PATH_TAG": "pci-0000_00_14_0-usb-0_14_4_1_1_0-scsi-0_0_0_1",
      "ID_REVISION": "0001",
      "ID_SERIAL": "Linux_Virtual_Floppy_1028_123456-0:1",
      "ID_SERIAL_SHORT": "1028_123456",
      "ID_TYPE": "disk",
      "ID_USB_DRIVER": "usb-storage",
      "ID_USB_INSTANCE": "0:1",
      "ID_USB_INTERFACES": ":080650:",
      "ID_USB_INTERFACE_NUM": "00",
      "ID_USB_MODEL": "Virtual_Floppy",
      "ID_USB_MODEL_ENC": "Virtual\\x20Floppy\\x20\\x20",
      "ID_USB_MODEL_ID": "0001",
      "ID_USB_REVISION": "0001",
      "ID_USB_SERIAL": "Linux_Virtual_Floppy_1028_123456-0:1",
      "ID_USB_SERIAL_SHORT": "1028_123456",
      "ID_USB_TYPE": "disk",
      "ID_USB_VENDOR": "Linux",
      "ID_USB_VENDOR_ENC": "Linux\\x20\\x20\\x20",
      "ID_USB_VENDOR_ID": "413c",
      "ID_VENDOR": "Linux",
      "ID_VENDOR_ENC": "Linux\\x20\\x20\\x20",
      "ID_VENDOR_ID": "413c",
      "MAJOR": "8",
      "MINOR": "112",
      "SUBSYSTEM": "block",
      "TAGS": ":systemd:",
      "USEC_INITIALIZED": "55025224"
    },

I'd be happy with something like: "proxmox-auto-install-assistant prepare-iso /path/to/source.iso --fetch-from partition --partition-label oemdrv". It would then register that somewhere on the new ISO, where proxmox-fetch-answer would parse, validate, and on failure, default to proxmox-ais. Otherwise it then looks for the listed label instead of being hardcoded to proxmox-ais.

 

[proxdrop]

Well, I did recompile with the BUILD_MODE set to release, which helped in the end. Unfortunately, I've gotten it to the stage where iDRAC SCP boots into the install ISO, sees and reads the answer.toml file, but then tries to unmount the ISO and reboot. Its not playing nice at that stage (just bootlooping) so it may take me some time to figure that aspect out. Thanks for the help anyways.

EDIT: Figured out my issue after much troubleshooting. While I was copying over the compiled binaries, I wasn't copying over the various Perl scripts. I eventually tracked down the missing/updated stuff in ../perl5/Proxmox and copied it to the bootable ISO. That allowed me to successfully install and boot.

 

[BobhWasatch]

Ultimately the "mk-build-deps --install" script failed me entirely.

Did you install "build-essential" or "dpkg-dev"?

 

[proxdrop]

Did you install "build-essential" or "dpkg-dev"?

Both are installed. I suspect I misunderstood something on Debian repositories since it seemed like several of the librust packages either weren't available at the version specified, or otherwise incompatible. I had added the pvetest repo but it didn't seem to help at all. I imagine my main sources.list probably needed more than just "main contrib" but I didn't see any proxmox documentation on which others needed to be added, and swapping to crate/rust repos ended up solving things faster for me.