8

I frequently install Ubuntu on VMs running under Proxmox or VMware. Every time the installer gets to curtin command in-target and stays there for at least half an hour, sometimes much longer. The Ubuntu installer at this point gives an option to "Cancel update and reboot", but if that is chosen it then sits unchanging for about the same time that just leaving it to complete does.

I'm in a major network data center with ten gigabit connectivity, so the problem isn't slow local networking. I can shortcut the issue by resetting the VM, and if I do so then once it boots I can then install all the updates in a fraction of the time using apt update and apt upgrade, however I'm wary of using tricks like that on what will be production systems.

I've tried Googling and searching here for anything explaining why this stage of the Ubuntu installer takes so long, but I haven't found anything specific, although I have found a recommendation to not have any NICs on the system while installing and only add them post-install as a way to speed things up.

What is this curtin command in-target stage of the Ubuntu installer, why does it take so long, and are there any drawbacks to just pressing the reset button and then using apt update and apt upgrade post-boot instead?

karel
  • 122,695
  • 134
  • 305
  • 337

2 Answers2

9

The "curtin command in-target" stage of the Ubuntu installer is responsible for configuring the system after the base packages have been installed. This includes setting up the network, configuring user accounts, and installing any additional packages that have been selected by the user in the Ubuntu installer options.

Your computer has 10 gigabyte network connectivity which rules out a long delay due downloading and installing additional packages. The long delay after the Ubuntu installer gets to curtin command in-target may be caused by two other factors:

  • The Ubuntu installer configuring the entire operating system, not just a few individual settings.
  • The Ubuntu installer is running on an Ubuntu live USB which is not as fast as a fully installed OS.

In addition to the aforementioned try using VirtIO network adapters instead of E1000 if you are using Proxmox, and try using the VMware Paravirtual SCSI Controller instead of the LSI Logic SCSI Controller if you are using VMware.

If none of the above suggestions work it is best to let the curtin command in-target stage complete normally unless you are having serious problems.

karel
  • 122,695
  • 134
  • 305
  • 337
  • 3
    Thanks for the comprehensive answer, much appreciated. In this case the Ubuntu installer is the ISO of the live CD mounted by NFS from a server in a remote datacentre, which does have more restricted bandwidth, I'd assumed the whole thing would be loaded into memory so after the initial delay as it fires up, would entirely run locally, but perhaps not? We are running Proxmox, on hosts with 120 cpus and 300+ gig of memory, and using the VirtIO adapters.

    Now that I know what it's actually doing, will just let it run, and get on with other work while it completes.

    Thanks again!

    – Pyromancer Nov 14 '23 at 10:56
  • What kind of word is "curtin" ? It puzzles me because all other stages seem to be gerunds ("installing", "executing", "configuring"), and I can't find the word "curtin" in any of my usual dictionaries (merriam-webster, google translate). Is that a typo or is it some kind of slang? – Alexander Amelkin Nov 26 '24 at 18:42
  • 1
    @AlexanderAmelkin Curtin is a lightweight installation framework designed to perform automated installations. It is primarily used in cloud and server environments but also supports local installations with preconfigured settings. Curtin is a core component of Subiquity, the server installer for Ubuntu. Subiquity acts as a front-end interface for the installation process, while curtin executes the underlying installation tasks like partitioning disks, copying files and configuring the system. – karel Nov 27 '24 at 00:58
1

As far as I can tell, this slow behaviour during "curtin comman in-target" also happens on bare metal and on a non-network install. I'm installing Ubuntu Server 24.04 from an 128 GB USB 3.1 pen drive on a 2013 Mac Pro. If I switch to the detailed log view during installation, all the "unpacking ... over ..." log messages seem to appear exceptionally slowly. It seems that in this stage of the installation updates are installed, which for some reason unknown to me takes a long time. Everything before this point went smoothly, it just took the whole installation process about 5-10 minutes to get to this stage.