CLI warns about --wait and --insecure being used together while only --insecure is being used

[lwbt]

Bug Report

CLI warns about --wait and --insecure being used together while only --insecure is being used.

Description

According to https://www.talos.dev/v1.8/reference/cli/#talosctl-reset the CLI can be used to reset a node.

$  talosctl reset --insecure -n 192.168.8.11
cannot use --wait and --insecure together

This should have been executed, even if this node has problems with the cluster or configuration. Instead it warns me about a parameter I'm not using.

$  talosctl reset -n 192.168.8.11
error constructing client: failed to determine endpoints

This does not work in my situation, which means I have to remove the storage device from the SBC board and reset it manually.

Logs

Environment

• Talos version: v1.8.0
• Kubernetes version: n/a
• Platform: SBC

[smira]

Just use --wait=false,but you won't be able to reset in maintenance mode unless you're connected over SideroLink (which doesn't seem to be the case), so this command is not useful.

If your machine is not in maintenance mode, you don't need --insecure.

I'm not quite sure what is the usecase you're looking for.

[barneydesmond]

I've just started playing with Talos today and ran into the same problem. I have a few mini PCs that I want to install Talos on, and wanted to reinstall Talos from scratch after applying some machine configs. I boot everything from PXE, but found that my node wasn't going into Maintenance mode even though I'd used a generic kernel cmdline with no config options.

I assume that the Talos image boots, it finds existing state on the local disk, and uses that to continue normal operation instead of waiting for me to push the machine config to it (maybe there's a kexec in there, it's too fast for me to see). In my particular case I had previously pushed config to the (first and only) controlplane node, but hadn't bootstrapped the cluster yet. I wanted to wipe the node and start clean because I had set the hostname to be a bare name rather than the FQDN that I intended.

• I tried reset without --insecure and it didn't work, I thought maybe the PKI isn't setup yet (but I probably just had the hostname wrong).
• So I tried it with --insecure and I got the confusing error - I'm not using --wait so why is it complaining about that??

After more experimentation I eventually find that I don't need --insecure, I just needed the correct hostname for -e and -n (but the buggy error message is still there).

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity.