Clarification on metal installation using the ISO

[johanneskastl]

Hi all,

I have a general question on the installation process on bare metal.

https://www.talos.dev/v1.7/talos-guides/install/bare-metal-platforms/iso/

I have a x86_64 UEFI machine that I would like to install Talos on. I tried booting the machine from a USB stick on which I dd'ed the ISO. I also tried dd'ing the RAW image to the machine's disk (and manually created a EFI boot entry for this).

I found tutorials doing both, booting from USB and putting the raw image to disk.

From the documentation I would have thought that after applying the configuration the machine would "install" Talos to disk and reboot into the installed system.

Talos doesn’t install itself to disk when booted from an ISO until the machine configuration is applied.

Is my general assumption of "boot from USB stick and then it installs to disk" correct?

If so, is there any indication on how long it should take to install? Does it reboot automatically?

In my experiments, I could apply the configuration but it almost instantly told me that it was waiting for me to bootstrap the cluster (according to the talosctl dashboard output). I did not notice any reboot.

After issuing a reboot using talosctl the machine boots up pristine, e.g. without any of the network settings I have in my controlplane.yaml. So somehow it did not "install" to disk.

Maybe I am missing something or overlooking a detail, so any hints are highly appreciated.

Thanks in advance,
Johannes

[smira]

If you're using a disk image, Talos is already installed, so applying machine configuration turns it immediately into a running system.

If you're booting off an ISO (or PXE booting, or the equivalent of it), Talos is not installed, and applying machine config will trigger reading machine.install instructions, install, reboot and after that it will be a running system.

Note: if you boot from an ISO, but Talos is already installed to the disk, Talos uses that disk as a system disk immediately, so it assumes it's already installed, even if booted from an ISO. It's a mis-feature, and it might be fixed in future versions of Talos.

[johanneskastl]

Thanks for the quick reply, @smira !

If you're using a disk image, Talos is already installed, so applying machine configuration turns it immediately into a running system.

That was what I was hoping, but after a reboot it came up with the defaults, in my case no manual network configuration (that is specified in my controlplane.yaml).

If you're booting off an ISO (or PXE booting, or the equivalent of it), Talos is not installed, and applying machine config will trigger reading machine.install instructions, install, reboot and after that it will be a running system.

OK, then my interpretation of the docs was correct.

How long does it normally take for the reboot to take place?

Note: if you boot from an ISO, but Talos is already installed to the disk, Talos uses that disk as a system disk immediately, so it assumes it's already installed, even if booted from an ISO. It's a mis-feature, and it might be fixed in future versions of Talos.

I removed both MBR and GPT partition tables before all experiments, so the disk was "empty".

[smira]

Probably it makes sense to ask a specific question about a specific sequence of actions, as it's very confusing at the moment.

That was what I was hoping, but after a reboot it came up with the defaults, in my case no manual network configuration (that is specified in my controlplane.yaml).

It's not clear, why Talos rebooted? If it's running with the machine config in the normal mode, it would apply everything, including network configuration.

How long does it normally take for the reboot to take place?

It's quite fast with kexec, depends on hardware, might be a minute for example.

[johanneskastl]

Probably it makes sense to ask a specific question about a specific sequence of actions, as it's very confusing at the moment.

Sorry, but I am really confused at the moment. :-)

OK, so just to clarify:

• I dd the raw image to disk
• I create a EFI boot entry for this
• I boot it (in my case with static network configuration via ip=
• I can reach the machine e.g. talosctl disks or talosctl get addresses are working
• I apply the configuration (in my case the controlplane.yaml
• I bootstrap the cluster, download the kubeconfig etc.

Should the configuration be persisted to disk at this point? During one of my tries I waited for the Kubernetes cluster to be up and running, all pods fine, etc. Then I issued a talosctl reboot ... and the machine rebooted. But it never came back up with the network configuration I specified, so to me it looked like it did not write anything to disk.

Do I still need the machine.install section when running off of a raw image (and not a PXE boot or USB stick)?

[smira]

Talos is using GRUB bootloader for the boot process (unless you're using SecureBoot).

When you do talosctl reboot, the default is to kexec, so Talos will read configuration from GRUB.

If you skip GRUB on boot via EFI bootloader, and specify cmdline there, Talos will not be able to use that. You have an option to skip kexec on reboots, or just use Talos disk image and your EFI bootloader should boot into GRUB from it without any extra entries to set up.

Image Factory allows you to specify extra kernel args for the disk image if you need to.

Usually ip= args are used temporarily (for the initial PXE boot), and specifying network configuration in the machine configuration is used afterwards.

So not sure what is the flow you want to stick with, but I guess on kexec in your case ip= arg is lost. If you hard reboot, it will be back.

[johanneskastl]

Thanks for the insights. So with talosctl reboot I should never see GRUB, as it only does a kexec and not a full power cycle. That is consistent with my findings.

The EFI entry I created was to boot the default bootx64.efi that starts GRUB. So I am not skipping GRUB.

So not sure what is the flow you want to stick with, but I guess on kexec in your case ip= arg is lost. If you hard reboot, it will be back.

Basically I am trying to successfully install Talos on this machine :-)

I'll try to do some more tests, I think that there must be an error or typo somewhere in my configuration, so the connection drops when talosctl reboot triggers the kexec.

[johanneskastl]

OK, I had a typo in the network interface name. After fixing that the machine also went "offline" after applying the configuration.

I waited for 20 minutes, then hard-reset the machine.

I checked the disk, there were partitions on it, but no EFI boot entry was created.
I created the EFI boot entry (pointing to bootx64.efi) and rebooted. And it started up fine, with the network settings I gave and ready for cluster bootstrapping.

So, hooray, it worked finally!

Not sure why no EFI boot entry was created, might be a "problem" with this hardware (Fujtsu Futro 920 thin client). But it looks like I have a cluster up and running!

[kastl-ars]

OK, one thing I noticed which could explain parts of my confusion:

The machine is connected to a monitor, which shows the boot log (with some network-related errors when e.g. NTP was tried before the network was ready).

This screen never changes!

I just triggered a powercycle reboot (not just a kexec) using talosctl reboot --mode powercycle ... and although the machine was already beginning the reboot, the screen was not showing anything. Suddenly it went blank, when the machine reached the actual end of the reboot phase and switched to BIOS and Grub etc.

Having "something" happen there on actions would be a nice help for Talos newbies like me. Is there a setting to show the logs also on this console? Or at least show things like shutting down services during reboot? Or is that impossible due to the way the dashboard works?

(I found https://www.talos.dev/v1.7/reference/kernel/#talosdashboarddisabled which looks like it is either dashboard or console...)

[smira]

The dashboard shows the machine phase, including rebooting phase, plus it still shows the logs.

If you want pure Linux console, use Alt+F1 to switch to VTY1 or disable the dashboard