[14:29] <realtime-neil> What's the `autoinstall` way of embedding a `seedfrom=...` into the `*.iso`? I'm used to putting my `preseed.cfg` at the top of the iso9660 archive and pointing the kernel at `file=/cdrom/preseed.cfg`.
[15:11] <realtime-neil> looks like what I want is `ds=nocloud;seedfrom=file:///cdrom/`, according to https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
[15:11] <realtime-neil> Anyone here doing something like that?
[15:11] <xnox> well the image itself does that by default anyway.
[15:12] <realtime-neil> xnox: Where does that default live, exactly?
[15:12] <xnox> if you are modying installer.squashfs you will find that it already has empty files you can modify the
[15:12] <xnox> 0	./var/lib/cloud/seed/nocloud/meta-data
[15:12] <xnox> 0	./var/lib/cloud/seed/nocloud/user-data
[15:12] <xnox> inside casper/installer.squashfs
[15:13] <xnox> maybe we should have put them straight on the iso with a comment "change me if you want to modify the baked in nodata cloud datasource"
[15:20] <realtime-neil> xnox: okay, understood ... fwiw, I understood the baked-in `/boot/grub/grub.cfg` params better, but I can work with this, too.
[15:22] <xnox> realtime-neil:  it should work to drop your own seed onto toplevel cdrom, and make your own custom grub.cfg with ds=nocloud;....
[15:22] <xnox> realtime-neil:  unless bugs =)
[15:23] <xnox> realtime-neil:  depends if you are already modifying installer.squashfs or not, and if calling mksquashfs to append two files to it is easy or not.
[15:24] <realtime-neil> xnox: good to know, thanks. Is there a facility to tell `user-data` to wrap a "legacy" preseed.cfg, or does the new `autoinstall` schema (https://ubuntu.com/server/docs/install/autoinstall-reference) only allow The New Way?
[15:29] <realtime-neil> I'm looking for a way to slide into this brave new autoinstall world with my old preseeds intact and then iteratively migrate them into modernity
[15:44] <xnox> realtime-neil:  impossible.....
[15:44] <realtime-neil> shucks.
[15:44] <xnox> realtime-neil:  1) is turning complete programming language 2) is declarative yaml syntax => the two are incompatible.
[15:45] <xnox> realtime-neil:  for example, it is impossible to know which questions preseed will ask, in which order, how many times, and which answers it expects.
[15:45] <xnox> realtime-neil:  a lot of preseeds fail on unclean disks and questions like "do you want to disable swap?" "i wound LVM with the same group name, what do you want me to do?" etc.
[15:46] <xnox> realtime-neil: preseeds are extremely fragile, especially if one reinstalls the same build over the top of the old one =/
[15:46] <xnox> realtime-neil:  and partman way to specify disk layouts is really akward, hence we ditched that.
[15:46] <xnox> autoinstall yaml is a hope to get things right.
[15:47] <realtime-neil> I don't doubt that's true, but certainly the case is easier for those installations that nuke whatever is on disk every time?
[15:55] <xnox> realtime-neil:  the old d-i, doesn't know how to nuke things. And there ware ghost things that reappear that it doesn't know how to deal with. I.e. partial volume groups, partial left-over raids, etc.
[15:56] <xnox> realtime-neil:  and it asks more questions when things like that appear. Or like demands one specifies UUID of the lvm group to purge, which one cannot preseed. Thus resulting in hanging the preseed installation at an interactive prompt.
[15:56] <xnox> it really freaks out if it creates a partition table, and somehow lvm group reappears in the place where the fresh partition is created.
[15:57] <xnox> (because well, it was still there, at the same offset)
[16:05] <realtime-neil> xnox: is it by design or just dumb luck that I've been able to avoid the problems you've mentioned with the `d-i partman*` preseed directives shown here: https://paste.ubuntu.com/p/G4wFNDr4nr/
[16:07] <realtime-neil> Note that the referenced `d-i partman/early_command` is effectively a no-op I use to `chvt 4` sometimes.