edit2: Over the 2 weeks with subiquity and cloud-init, I pieced together a new shell script with example user-data file and an altered grub.cfg as the one by covertsh did not work for me any longer due to removal of isolinux as part of 21.10. The script is automated to repack the ISO to boot on EFI and MBR systems alike and can be acquired here.
Some of the scripts content comes from this thread: Remaster Installation Image for Ubuntu 20.10
edit: Sorry if this sounds overly angry, but that is lit. what I feel the last days fighting against subiquity.
following the order in which I did stuff:
1. download daily live server ISO (jammy 22.04 ~1,4Gb)
2. unpack iso to a folder
3. remove the [BOOT] directory
4. some dd magic to get efi and legacy partitions from the ISO file (boot_hybrid)
5. write a user-data file, check that file against the schema using cloud-init
6. place user-data and empty meta-data file into a new directory in ISO-root named server
7. place new grub.cfg with new menuentry in /cdrom/boot/grub/
8. use xorriso to repack the iso into a new file 9. Make VM and boot the whole stuff
Now the following thing confuses me:
The installer seems to recognise the new entries in GRUB and acts accordingly, also accepting my entry to open only the network section as interactive and the initial identity section as well.
BUT after the installation the installer seems to have used LVM instead direct method for storage and non of the late commands and also the one user-data runcmd command are executed. All the packages configured under apt are missing as well.
What would be the necessary steps to debug this situation?
My first guess was /var/log/subiquity.log, but I had no chance to understand or chronologically follow any of that gibberish output in there.
Update 1:
So far, shockingly, none of the related logs were able to offer ANY computable information for why the installer acted the way it did. The only thing supplied are some deeply confusing information about actions within the cloud-init itself neither connected to any input or output that could establish a foundation for actual debugging. Frankly put, the output design is unacceptable.
Update 2:
the only thing I was able to find (in an unrelated log to that) is:
Which leads me to believe, that there has been made a change to probably grub, the autoinstall key or subiquity that has not been documented very well or, which is probably the most likely, I must have made documentation errors somewhere inbetween 20.04 or 21.x and now, on the other hand I documented my trials pretty well and it did work like that before. and I just figured stacks markdown does not support strike through.
Update 3:
so far I have managed to get past grub errors and into the actual autoinstall, which still starts to fail at installing the package ubuntu-desktop-minimal
Hints for others I can give so far:
- Forget the logs, those are close to (but not entirely) garbage
- Make sure to follow the yaml schema EXACTLY a single space can result in a green light from cloud-init schema check but result in a faulty autoinstall as the OS will omit the file as incorrectly formatted going (without any hint to you) for a default user-data file somewhere in the ISO. I just had enough of going to search for where that is.
- Make sure to duplicate grub.cfg in your iso over loopback.cfg no idea whose idea that was but it's there even if nearly no one needs it.
- some of
grub.cfgneeds to look like this
menuentry "Autoinstall Ubuntu Server + Desktop + Ordersprinter" {
set gfxpayload=keep
linux /casper/vmlinuz quiet autoinstall "ds=nocloud;s=/cdrom/nocloud/" ---
initrd /casper/initrd
}
- casper/vmlinuz(tab)quiet < make sure to get that right or the autoinstall starts throwing errors.
- grub did not throw an error, which apparently is not an error but a redirection of the autoinstall keys to the userspace. But hey. Let's format that message as an error, who cares.
Update 4:
The installation log of ubuntu itself seems to sometimes actually contain a wee bit of good information!
After 200 lines of confusing stuff you might hit a section called traceback if you are lucky enough it tells you what part of the cloud-config actually caused a failure. But sometimes even that section only contains rubbish. But its a start. Honestly traceback should be the first thing in that log, not hidden somewhere deep inside.
Update 5: Can confirm now that the ubuntu-desktop-minimal package is the point where the install halts the entire installation and even if not very reliable the CPU usage by the VM is near zero, same for vdisk IO. Later I will try to install the package via the late commands.
Update 6:
why can this user use sudo for tee, but I can not use sudo via curtin to run apt in -q -y?
