Fedora 45 Remote Install over HTTPS with inst.webui.remote

Fedora’s own change page tells you to boot with inst.webui.remote.password=, but the installer that ships in Fedora 45 ignores that option and quits. The pair that works is inst.webui.remote plus inst.webui.remote.pin=. With both on the kernel line, Anaconda serves its WebUI over HTTPS on port 443, and you can run a Fedora remote install from a browser on any other machine on the network.

Original content from computingforgeeks.com - post 179769

This guide follows one install through that path on Fedora 45 Silverblue: the GRUB edit, the PIN login, the four installer screens and the first boot, which still wants a local screen. Then it bakes the same options and a kickstart into the ISO with mkksiso, so the next machine installs unattended while you only watch. Everything below was run in October 2026 on the Fedora 45 Silverblue installer ISO, booted as a nested KVM guest in a Proxmox lab with the browser on a separate machine, so every screen and error here is a real capture.

Only the pin option starts the remote installer

Remote access is opt-in, and Anaconda refuses to open it without authentication. The option parser in the Fedora 45 installer image knows three remote switches (webui.remote, webui.remote.noauth and webui.remote.pin), and nothing called password. An unknown inst.* option is silently dropped, so the misspelled PIN never reaches the check that needs it.

We booted the ISO four ways and read tty1 each time. In order of what you are likely to type:

1. inst.webui.remote alone: Anaconda exits.
2. inst.webui.remote inst.webui.remote.password=4729: Anaconda exits the same way.
3. inst.webui.remote inst.webui.remote.pin=482917: the WebUI starts on port 443.
4. No remote option: the local installer runs as before.

The change page says a missing password makes the local console prompt for one. The Fedora 45 installer doesn’t do that, and both failures happen out of sight. The local display goes to a flat grey screen and stays there, and the reason only shows up after you switch to tty1 with Ctrl+Alt+F1, where the Anaconda tmux pane is marked dead:

Notice the order of the messages. The installer prints “Web UI remote access enabled” and an address first, then dies with inst.webui.remote requires inst.webui.remote.pin=<PIN> to be set. and Pane is dead (status 1). If you only glance at the top of the screen, it looks like it worked. A remote machine you can’t see would simply never answer on 443, so test the exact option line on a box with a monitor before you rely on it headless.

Remote install needs an Atomic Desktop ISO

The feature lives in anaconda and anaconda-webui, but Fedora only enabled it for the Atomic Desktop installer images in this release, and labels it a tech preview. The Fedora 45 change proposal scopes it to Silverblue, Kinoite and the other Atomic spins, says remote access on Live images is not supported, and notes that Fedora Server still uses the GTK installer. So the Workstation Live ISO is out. If you’re still choosing between the two desktops, our Silverblue vs Workstation comparison covers what you give up.

Before you start, line up:

• The Fedora 45 Silverblue (or Kinoite) installer ISO on a USB stick or virtual CD
• A target with enough RAM for the installer (the lab guest had 6 GB and 2 vCPUs; we didn’t try less)
• A second machine with a browser that can reach the target on TCP 443
• A keyboard and screen on the target once, for the GRUB edit
• A PIN you’ll type into the browser

You can drop the keyboard and screen in the kickstart variant further down, because the options live in the ISO’s own GRUB config there. Only Silverblue was tested here; the change page lists Kinoite as covered too.

Download and verify the Silverblue ISO

Pull the ISO and its checksum file on any Linux machine. The second curl in each line only runs if the release tree does not carry the file yet, and falls back to Fedora’s staging tree for the same build:

# https://fedoraproject.org/atomic-desktops/silverblue/download
ISO=Fedora-Silverblue-Installer-45-1.4.x86_64.iso
SUM=Fedora-Silverblue-45-1.4-x86_64-CHECKSUM
curl -fLO https://dl.fedoraproject.org/pub/fedora/linux/releases/45/Silverblue/x86_64/iso/$ISO || curl -fLO https://dl.fedoraproject.org/pub/alt/stage/45_RC-1.4/Silverblue/x86_64/iso/$ISO
curl -fLO https://dl.fedoraproject.org/pub/fedora/linux/releases/45/Silverblue/x86_64/iso/$SUM || curl -fLO https://dl.fedoraproject.org/pub/alt/stage/45_RC-1.4/Silverblue/x86_64/iso/$SUM

Check the image against the checksum file before you write it anywhere:

sha256sum -c --ignore-missing $SUM 2>/dev/null

--ignore-missing skips any other images listed in the file, and 2>/dev/null hides the format warnings that the PGP signature lines in clearsigned release-tree CHECKSUM files trigger. One line comes back, and it has to end in OK. No output at all means the ISO name in the CHECKSUM file doesn’t match the file you downloaded:

Fedora-Silverblue-Installer-45-1.4.x86_64.iso: OK

Under its 2.9 GB, the ISO carries the OS tree and a Flatpak repo inside its installer image. The installer’s default kickstart is a single line, ostreesetup ... --url=file:///ostree/repo, pointing at the copy on the ISO instead of a network source. You’ll reuse that line in the kickstart later. If the release tree names the file differently from the staging build, take the exact name from the Silverblue download page, and check the CHECKSUM file’s signature with Fedora’s key as the Fedora boot media docs describe.

Add inst.webui.remote at the GRUB menu

Why not just press Enter? On this ISO, GRUB defaults to “Test this media & install Fedora 45” with a 60 second countdown, and the media check adds minutes to every boot. Pick the plain entry and edit it:

1. Press the up arrow to highlight Install Fedora 45.
2. Press e to open the entry.
3. Move down to the linux line and press End.
4. Type a space and the two options.
5. Press Ctrl+x to boot.

After step 4 the linux line reads like this, with your own PIN in place of 482917:

linux /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-45-Silverblue-x86_64 quiet inst.webui.remote inst.webui.remote.pin=482917

On the lab machine, the GRUB editor looked like this just before Ctrl+x:

The PIN sits in plain text on the kernel command line, so anyone at the console can read it off the GRUB screen. Treat it as a one-install password: pick a fresh one per machine, and don’t reuse anything you use elsewhere.

The console prints the address, not a URL

With a valid PIN, Anaconda switches the console back to tty1 so you can read where to connect. It took 61 seconds from Ctrl+x until the installer answered on HTTPS in the lab, and the screen looked like this:

Expect bare addresses, one IPv4 and one IPv6, with no scheme and no port. You have to type https:// in front yourself, since the WebUI is served over TLS on the default HTTPS port. The 10.0.2.15 you see is QEMU’s user-mode NAT address, which is what a nested guest gets; the browser reached it through a port 443 forward on the lab VM at 10.0.1.50. On bare metal or a bridged VM, the printed address is the one you open directly.

Cockpit serves the installer on port 443

The WebUI is a Cockpit application, and remote mode is what turns on TLS. The installer’s base Cockpit config sets AllowUnencrypted = true for the local session, and the remote switch layers the HTTPS listener on top. Before you open a browser, you can check from your workstation that the listener is up:

curl -skI https://10.0.1.50/

A 200 OK with Cockpit’s security headers means the installer is waiting for you:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Security-Policy: connect-src 'self' https://10.0.1.50 wss://10.0.1.50; form-action 'self' https://10.0.1.50; base-uri 'self' https://10.0.1.50; object-src 'none'; font-src 'self' https://10.0.1.50 data:; img-src 'self' https://10.0.1.50 data:; block-all-mixed-content; default-src 'self' https://10.0.1.50 'unsafe-inline'
Set-Cookie: cockpit=deleted; PATH=/; SameSite=strict; Secure; HttpOnly
Transfer-Encoding: chunked
Cache-Control: no-cache, no-store
X-DNS-Prefetch-Control: off
Referrer-Policy: no-referrer
X-Content-Type-Options: nosniff
Cross-Origin-Resource-Policy: same-origin
X-Frame-Options: sameorigin

Your browser will warn about the certificate, and it is worth knowing why before you click through. Pull the certificate’s subject, lifetime and names:

echo | openssl s_client -connect 10.0.1.50:443 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Subject and issuer match, so you are looking at a self-signed certificate minted at boot:

subject=O=ca6acc8735044000a73339609b7265c6, CN=sb01
issuer=O=ca6acc8735044000a73339609b7265c6, CN=sb01
notBefore=Oct 29 11:44:31 2026 GMT
notAfter=Nov 28 11:44:31 2027 GMT
X509v3 Subject Alternative Name:
    IP Address:127.0.0.1, DNS:localhost

The common name is the hostname DHCP handed the installer (sb01 here), and the only subject alternative names are 127.0.0.1 and localhost. No browser can match that against the address you typed, so the warning shows up on every install. The notBefore time is the moment the installer booted, which means you have nothing to pin in advance either. The PIN is the only thing standing between the network and your disk layout, so run remote installs on a segment you trust.

The PIN gates every new browser session

Accept the warning and the first page is a single PIN field, served before any installer code loads:

1. 1Enter PIN
2. 2Log in

1. Type the PIN into Enter PIN.
2. Click Log in.

A wrong PIN returns Invalid PIN. Please try again. and leaves the form in place; we saw no lockout after a bad attempt. The login is a session cookie. A brand new browser profile hit the PIN page again, which is what you want, but a second tab in the same browser went straight in. That second tab is also how we broke an install, covered in the errors section.

Four screens stand between you and the install

You answer far fewer questions here than in the old GTK installer. There is no user screen, no time zone and no software selection, because the image is fixed and you create the account on first boot. The sidebar lists everything you’ll see:

1. Welcome: language, plus a keyboard layout link
2. Installation method: disk and layout
3. Storage configuration: an Encrypt my data checkbox
4. Review and install

Welcome lists every locale the installer knows, with a short “Suggested languages” group on top, and the choice sets the installed system’s language too. Installation method is the screen that decides what gets erased:

1. 1Change destination
2. 2Use entire disk
3. 3Next

1. Change destination if the box has more than one disk.
2. Leave Use entire disk selected for a clean install.
3. Click Next.

The storage screen only offers encryption. Tick it if you expect the machine to leave the building; you can bind the LUKS volume to the TPM afterwards with our LUKS and TPM2 guide for Fedora. The review screen then shows the layout Anaconda will write:

1. 1Hostname
2. 2Storage
3. 3Erase data and install

1. Hostname stays transient unless you edit it here.
2. Storage shows an EFI partition, an ext4 /boot and one btrfs partition with /, /home and /var subvolumes.
3. Erase data and install starts the install.

Read the review carefully, because there’s no confirmation dialog after it. The click on Erase data and install went straight to “Creating disklabel on /dev/vda”. The progress page then walks through storage, software, system configuration and finalization, and the software stage is the one you wait on:

Anaconda writes the OSTree objects first and then installs the bundled Flatpaks one by one; GNOME Calendar and the Fedora Platform runtime were two we caught on screen. The whole run took about 12.5 minutes on the nested 2 vCPU guest, from the click until this screen:

The Reboot button works remotely. After the click, the page switches to “Installation completed. You can close this browser window now.” and the target restarts into the installed system.

First boot still wants a local screen

The feature does not cover one step. Because the WebUI never asked for a user, the first boot lands in GNOME Initial Setup on the target’s own display, and that’s where the account gets created:

For a desk machine that is fine: you installed from the couch and someone sits down at it later. For a headless box or a VM nobody opens a console on, the interactive path stops one screen short. The fix is to hand Anaconda the account in a kickstart, which also removes the GRUB edit. The things to do after installing Fedora 45 list picks up from either end state.

Bake the options and a kickstart into the ISO

mkksiso from the lorax package adds a kickstart to the ISO and rewrites the kernel line in every GRUB entry. It ran on a Fedora 45 machine in the lab; pykickstart brings the validator. Install both:

sudo dnf install -y lorax pykickstart

The account needs a SHA-512 crypt hash, never the plain password. openssl passwd -6 prompts for the password twice and prints a line starting with $6$; that line goes after --password=. Create the kickstart:

vim client01.ks

Below is the exact file that installed the lab machine; replace the hash with your own:

lang en_US.UTF-8
keyboard us
timezone Africa/Nairobi --utc
network --bootproto=dhcp --hostname=client01

zerombr
clearpart --all --initlabel --disklabel=gpt
autopart --type=btrfs --noswap

ostreesetup --osname=fedora --url=file:///ostree/repo --ref=fedora/45/x86_64/silverblue --remote=fedora --nogpg

rootpw --lock
user --name=kenneth --groups=wheel --iscrypted --password=$6$Kf3wq9Lr2pXz$/mMRHg.GTwawCtPWsoKGXuXG5B3H7NDSEsLpmDfMhGnmHfyddXQsOp99E3OtwO47.u3zhmnBixIDD.JNvOFay1

reboot

Three lines carry the weight. ostreesetup is the installer’s own default, copied from the ISO, so the OS tree still comes from the repo on the ISO. user ... --groups=wheel is the account GNOME Initial Setup would otherwise ask for, with sudo rights since root stays locked. And reboot lets the machine restart itself instead of waiting on the final screen. Validate the file against the Fedora 45 syntax:

ksvalidator -v F45 client01.ks; echo rc=$?

No warnings and exit code 0 is a pass:

Checking kickstart file client01.ks

rc=0

Now build the ISO. Each flag fixes one thing the stock ISO would get in the way of:

• --ks embeds the file and appends inst.ks=
• -c adds the remote options to the GRUB entries
• -r "rd.live.check" drops the media check from the default entry
• -R cuts the 60 second GRUB timeout to 5

We ran it with sudo on the lab VM, input and output ISO in the same directory:

sudo mkksiso --ks client01.ks -c "inst.webui.remote inst.webui.remote.pin=482917" -r "rd.live.check" -R "set timeout=60" "set timeout=5" Fedora-Silverblue-Installer-45-1.4.x86_64.iso client01-remote.iso

On the lab VM the build took 2 minutes 44 seconds and ended with xorriso’s write report:

ISO image produced: 1440450 sectors
Written to medium : 1440624 sectors at LBA 48
Writing to '/home/kenneth/lab/client01-remote.iso' completed successfully.

Don’t trust the flags blindly; read back the GRUB config inside the new ISO:

xorriso -osirrox on -indev client01-remote.iso -extract /EFI/BOOT/grub.cfg grub-ks.cfg
grep -E "timeout|linux " grub-ks.cfg | head -4

You should see a timeout of 5, and the first entry carries the stage2 label, both remote options and the kickstart path:

set timeout=5
menuentry 'Install Fedora 45' --class fedora --class gnu-linux --class gnu --class os {
	linux /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-45-Silverblue-x86_64 quiet inst.webui.remote inst.webui.remote.pin=482917 inst.ks=hd:LABEL=Fedora-45-Silverblue-x86_64:/client01.ks
menuentry 'Test this media & install Fedora 45' --class fedora --class gnu-linux --class gnu --class os {

The “Test this media” entry, still the default, got the same line without rd.live.check, so either entry installs. Two cautions follow from that. The PIN and the password hash now sit in plain text on the ISO, so whoever holds the USB stick holds both. And the ISO wipes the first disk of anything it boots on within 5 seconds, so label it and keep it away from machines you care about.

The unattended install only needs watching

Boot the target from client01-remote.iso and leave it. GRUB counts down from 5 and picks its default entry on its own:

On the console you get the same “Web UI remote access enabled” block as before, and the PIN still guards the browser. What changes is the page behind it. With a kickstart loaded, the WebUI skips every screen and opens straight on the progress view, already partitioning when we logged in, with nothing to click:

Why keep the remote options when nobody needs to click anything? Without them, a kickstart install on a headless box is a black box until it either answers on the network or doesn’t. With them, you get the same progress messages Anaconda shows locally, from any browser. The two runs compared like this on identical nested hardware:

Measure	Interactive WebUI	Kickstart ISO
GRUB edit needed	Yes	No
Boot to HTTPS answering	61 s	63 s
Clicks in the browser	PIN, 4 screens, Reboot	PIN only (optional)
Boot to install finished	about 15.5 min	about 11.5 min
Reboots by itself	No	Yes
First boot lands in	GNOME Initial Setup	GDM login

Part of the gap is human: the interactive time includes a few minutes of us reading screens, and the kickstart run was the only workload on the lab VM. The last row is the one that matters for headless machines. Within two minutes of “Successfully installed”, the kickstart machine rebooted on its own and came up at the login screen with the account from the kickstart, no Initial Setup in between:

Does the installed system keep pointing at file:///ostree/repo with signature checks off, since the kickstart said --nogpg? It does not. We mounted the installed disk read-only afterwards and read the deployment’s origin file and its /etc/ostree/remotes.d/fedora.conf:

[origin]
refspec=fedora:fedora/45/x86_64/silverblue
[remote "fedora"]
url=https://ostree.fedoraproject.org
gpg-verify=true
gpgkeypath=/usr/share/pki/rpm-gpg/
contenturl=mirrorlist=https://ostree.fedoraproject.org/mirrorlist

Updates come from Fedora’s OSTree mirrors with GPG verification on, exactly as after a stock install, and the hostname file read client01 with kenneth in wheel. From here you have an ordinary Silverblue machine; our Silverblue package management guide covers rpm-ostree and Flatpak on it. If you need the same unattended result for a server rather than a desktop, a custom bootc image is the image-based route.

Errors we hit and what fixed them

Both errors below came from the lab runs, with the exact text the installer printed.

“inst.webui.remote requires inst.webui.remote.pin=<PIN> to be set.”

The PIN option is missing or misspelled, and .password= from the change page counts as missing. Anaconda raises SystemExit before the UI starts, which is why the local screen stays grey. Reboot and spell it inst.webui.remote.pin=. The installer’s option help also lists inst.webui.remote.noauth for testing only, and its code refuses noauth and pin together with “inst.webui.remote.noauth and inst.webui.remote.pin are mutually exclusive”; we didn’t boot either of those.

“Installation failed: Server has closed the connection”

Our first interactive run died the moment we clicked Erase data and install, with “The installer cannot continue due to a critical error: Installation of the system failed” and “Server has closed the connection” as the detail. Shortly before, we had opened the installer address in a second tab of the same browser. With the session cookie already set, that tab landed in a Cockpit shell as root@sb01 whose Overview and Terminal pages only showed “Disconnected”, and 30 seconds before the failed click the journal on tty2 logged the bridge crashing:

The last line, cockpit.protocol.CockpitProtocolError: channel is already open, comes from the bridge that cockpit-coproc-wrapper.sh runs for the installer session. The timing points at the second tab sharing that bridge, though we can’t prove the exact trigger. Nothing in the page brought the session back, so reboot the target and start over. Then keep exactly one tab on the installer; the clean rerun with a single tab finished without an error.

Boot option reference

Everything above comes down to which options are on the kernel line. This is what each did on the Fedora 45 Silverblue installer, and which rows were seen in the lab:

Kernel options	Result	Source
inst.webui.remote	Anaconda exits, local screen grey	Lab
inst.webui.remote inst.webui.remote.password=X	Same exit, option ignored	Lab
inst.webui.remote inst.webui.remote.pin=X	HTTPS on 443, PIN login	Lab
Above plus inst.ks= (mkksiso)	Progress-only WebUI, auto reboot	Lab
inst.webui.remote inst.webui.remote.noauth	No login, testing only	Installer option help
noauth and pin together	Anaconda exits	Installer code

For a local install from Server or Workstation media instead, the Fedora 45 Server and Workstation install guide walks through it, and what’s new in Fedora 45 lists the other installer changes in this release.