Comment 6 for bug 2031253

Today I managed to test my hunch. I booted the ISO in autoinstall mode with my custom subiquity.snap which has those three lines of code removed, and it was able to complete just fine. I expected that the installation would take much longer as a result, but it seemed to complete pretty quickly on my rural 12Mbps Internet connection. I'm not sure why, but I assume that means I messed something up. However, the server seems perfectly fine from a usability standpoint since my regular Salt States are able to complete without issue. If anyone is attempting to replicate my success, here are some instructions:

1. Make a new directory for the project, you will need it
2. git clone https://github.com/canonical/subiquity.git
3. sudo snap install --classic snapcraft # I had to do this step on a 20.04 system since it didn't work on my 23.04 system
4. lxc init --auto
5. Turn off your firewall if it is on
6. cd subiquity
7. make install_deps
8. Edit the file subiquity/server/apt.py and remove the section mentioned in my previous comment
9. wget https://cdimage.ubuntu.com/ubuntu-server/jammy/daily-live/current/jammy-live-server-amd64.iso # If you do not already have it
EDIT I forgot step 9.5 which is: snapcraft snap --output subiquity_test.snap
10. sudo ./scripts/inject-subiquity-snap.sh jammy-live-server-amd64.iso subiquity_test.snap ../custom.iso
You are almost there, now you just need to replace the GRUB
11. mkdir ../jammy
12. cd ../jammy
13. 7z -y x ../custom.iso -osource-files
14. cd source-files
15. mv '[BOOT]' ../BOOT
16. Replace the file boot/grub/grub.cfg with your regularly PXE-booted grub.cfg. Make sure to remove the portion of the "linux" line that reads "url=...", otherwise the kernel will attempt to get the ISO from that URL and completely ignore the ISO that you are booting from, making your subiquity changes moot.
17. xorriso -as mkisofs -r -V "Custom 22.04" -o ../../custom_subiquity_and_grub.iso --grub2-mbr ../BOOT/1-Boot-NoEmul.img -partition_offset 16 --mbr-force-bootable -append_partition 2 28732ac11ff8d211ba4b00a0c93ec93b ../BOOT/2-Boot-NoEmul.img -appended_part_as_gpt -iso_mbr_part_type a2a0d0ebe5b9334487c068b6b72699c7 -c '/boot.catalog' -b '/boot/grub/i386-pc/eltorito.img' -no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info -eltorito-alt-boot -e '--interval:appended_partition_2:::' -no-emul-boot .

This is not a final solution, but it does prove the point that the issue comes from attempting to access the cdrom when it is not available in the chroot. I am unsure why this happens only when a luks partition is configured. This new ISO will not boot over the network, which is sad. I think a better patchwork solution would be to just run commands in late-commands to add the repo, add the key, and run an apt update and apt install.