Please test autoinstalls for 20.04!

Hi Matthew,

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.

Also I have posted a number of screenshots so if you could point to the one that you are referring to that would help diagnose your issue.

I was using the method suggested on cloud-inits example documentation

mkpasswd --method=SHA-512

Hm then I’ve no real idea. Can you look at what is ending up in /etc/shadow somehow?

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 have fixed this problem in my repository (I use the 20.04 official iso):

Then, when we use the refresh-installer, and use the network configuration, then, inserting duplicate configuration works (with the two syntax):

networt:
  ...
network:
  network:
   ...

I think, because: Start the 20.4 installer, then needs network to get installer 20.5, then the 20.5 needs network.

Regards,

Now I trying:

Find howto set in cloud-init the storage xfs for root (/), untouching other storage parameters.

And I have a question:

Using cloud-init, howto instruct to cloud-init to not install documentation (man, etc) for specific packages (example is cloud-init and requirements)?

In other systems exists “nodoc” option for this.

Any help is welcome!

Regards

Hello,

I have a few questions:

  1. In last-commands option: What is the difference between for example:
  • sed -ie ‘s/GRUB_TIMEOUT=.*/GRUB_TIMEOUT=30/’ /target/etc/default/grub
    and
  • curtin in-target --target=/target – sed -ie ‘s/GRUB_TIMEOUT=.*/GRUB_TIMEOUT=30/’ /target/etc/default/grub

What is better to use? Just a basic shell command alone or shell command with curtin in-target --target=/target –

  1. BTRFS is still not supported?
  2. How can I set timezone in autoinstall config? I tried both of these and none of them worked.
  • curtin in-target --target=/target – timedatectl set-timezone Europe/Prague
    and
    timedatectl set-timezone

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?

Thanks for the feedback. :wink:

user-data:
 timezone: Europe/Prague

Worked like charm. :wink: The user-data option seems to not be in any documentation.
FoundationsTeam/AutomatedServerInstalls - Ubuntu Wiki
FoundationsTeam/AutomatedServerInstalls/ConfigReference - Ubuntu Wiki

Is there any documentation where I can find all supported config options that can be used in autoinstall config?

Thanks.

It’s not extensively documented but it is there: FoundationsTeam/AutomatedServerInstalls/ConfigReference - Ubuntu Wiki ?

FoundationsTeam/AutomatedServerInstalls/ConfigReference - Ubuntu Wiki has everything there is.

unfortunately adding:

refresh-installer:
update: yes

ends with the following error:


I need to use a proxy, which is defined as well in the autoinstall config:
proxy: http://proxy.meteoswiss.ch:8080

any ideas?

You’re right. I missed that. Thanks :slight_smile:

One more thing. mdadm layout is not supported yet right? Only LVM.

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:

- curtin in-target --target=/target -- curl <html> >>/root/.ssh/authorized_keys

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.

FWIW, this is done now: Daily live server ISOs for LTS releases now more usable

1 Like

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?

Oh I just meant a bug at https://bugs.launchpad.net/subiquity/+filebug, sorry.

No problem and thanks - it’s done: https://bugs.launchpad.net/subiquity/+bug/1879678