I’m experiencing the same problem as in your screenshot. In fact, ever since Subiquity has been updated to 20.05.1, the same (untouched) seedfile I’ve been using for the past week isn’t being processed correctly anymore.
And if I disable the the “refresh-installer”-section, the installer becomes stuck in a loop where it starts over from the beginning while it never reboots the machine or whatsoever.
And the “funniest” thing about this all, is that it only happens on UEFI-machines and not on machines with the traditional BIOS.
If I would to start debugging and finding out why the autoinstaller is looping and not rebooting, where should one find those logs?
You will first need to change to another terminal on the machine. Even while its looping it looks like its writing logs, but some like UI only seem to drop them off on a crash. So, there are two real places to look for logs due to this:
press or send a ctrl + F2 or ctrl +F3 to your console. While the installer is running it will move you to another terminal as ubuntu-server, which the installer uses to run the installation stuff.
From here you can look at /var/crash for anything that actually outputs a crash or halts and stops the installation process. The UI, networking, etc crashes are found here in .crash files and .meta files. The installer logs, or the log the installer writes while installing is located at /var/log/installer and this is what gets written while the installer is running.
Your issue likely would be logger in the installer log, as it doesnt actually crash so it might not generate a crash file.
Unfortunately, work schedules and such have prevented me from working on this further this week, but come Monday I plan on devoting time to it and I should be able to check with the /etc/shadow stuff. I’ll need to live boot and chroot/mount primarily due to not being able to login at all.
You can also use a partition editor to shrink the Ubuntu partition on a USB disk by a couple of MB and put a small FAT32 partition there labeled CIDATA, too. Or, wait, would that mess up the install? There was something special about how ISO boot worked that had to do with cylinder alignment on the partition, but I can’t find it right now.
I don’t think there is any built-in support for this. You can do things with dpkg excludes but that won’t affect packages that have already been installed (the installer mostly just rsyncs already installed packages into place, vs installing packages with dpkg).
Well the difference it that with in-target the commands run chrooted into the installed system and without it they don’t. In the case of this sed, it seemed easier to write it without the in-target but there’s no really strong reason. Some things are easier one way, some easier the other.
Well you can format a partition as btrfs. There is no support for any btrfs specific things like subvolumes.
you can put:
user-data:
timezone: Europe/Prague
in your autoinstall config. I’m not sure why timedatectl wouldn’t work but if it talks to services like dbus they won’t be running in the chroot so maybe it’s that?
Anyway. Is there any way how to use variables so I could use something like this:
ssh:
authorized-keys:
- <variable>
My goal is to get ssh keys from gitlab by using curl command.
I know YAML doesn’t support variables directly, but maybe there is some other way (a better way )how to do it with mentioned ssh option. The only other option I can think of would be to use curl in late-commands option like this:
Hm that definitely shouldn’t crash like that. As to why it doesn’t work, this reminds me of something I knew but forgot to address: the code that sets the proxy sets it for snapd to but this is done asynchronously and doesn’t wait for it to complete. Can you file a bug about this?
No, raid is supported. Only “by hand” though, no guided option yet.
Not directly. This seems a mildly strange thing to do, would it not be just as easy to generate the autoinstall config with the right key using a CGI script or something?
Probably the easiest way to do what you ask would be to have an early-command fetch the ssh key and inject it into the config, I posted some code for doing this kind of manipulation further up in the thread.
I’ve tried to make a bug-report about that crash. But since ‘abort’ is no useable and the system crashes in a “pre” finished state, I didn’t find any solution to create such a report, since I couldn’t find any web-form to write a report “freehand” in launchpad. Any hints?