Cockpit Storage in Anaconda Mode================================Anaconda (the OS Installer) can open the Cockpit "storaged" page foradvanced setup of the target storage devices. When this is done,storaged is in a special "Anaconda mode" and behaves significantlydifferent.In essence, the storaged page restricts itself to working with thetarget environment. It will hide the real root filesystem (on the USBstick that the Live environment was booted from, say), but let theuser create a "fake" root filesystem on some block device.Entering Anaconda mode----------------------The "storaged" page is put into Anaconda mode by storing a"cockpit_anaconda" item in its `window.sessionStorage`. The valueshould be a JSON encoded object, the details of which are explainedbelow.Ignoring storage devices------------------------Anaconda needs to tell Cockpit which devices can be used to installthe OS on. This is done with the "available_devices" entry, which isan array of strings.```json{"available_devices": [ "/dev/sda" ]}```This list should only contain entries for top-level block devices. Itshould not contain things like partitions, device mapper devices, ormdraid devices.Mount point prefix------------------Cockpit can be put into a kind of "chroot" environment by giving it amount point prefix like so:```json{"mount_point_prefix": "/sysroot"}```This works at the UI level: filesystems that have mount points outsideof "/sysroot" are hidden from the user, and when letting the user workwith mount points below "/sysroot", the "/sysroot" prefix is omittedin the UI. So when the user says to create a filesystem on "/var",they are actually creating one on "/sysroot/var".However, Cockpit (via UDisks2) will still write the new mount pointconfiguration into the real /etc/fstab (_not_/sysroot/etc/fstab). This is done for the convenience of Cockpit, andAnaconda is not expected to read it.BIOS or EFI-----------Anaconda needs to tell Cockpit whether a BIOS or a EFI system is beinginstalled. This controls which kind of special partitions can becreated easily.This is done by setting the "efi" flag to true or false:```json{"efi": true}```Default filesystem type-----------------------Cockpit tries to be smart about which filesystem type to select bydefault when formatting something. In normal operation, it will fallback to the type of the filesystem mounted as "/". When in Anacondamode, there might not be anything assigned to "/" yet, and in thiscase, Cockpit will use the type from "default_fsys_type".```json{"default_fsys_type": "xfs"}```Exported information--------------------Cockpit maintains some information in the session storage that can beused by Anaconda to learn things that it doesn't get from blivet. Thisis mostly information from fstab.The "cockpit_mount_points" entry in local storage will have a JSONencoded object, for example:```json{"/dev/sda": {"type": "filesystem","dir": "/"},"/dev/sdb": {"type": "swap"},"/dev/sdc": {"type": "crypto","content": {"type": "filesystem","subvolumes": {"home": { "dir": "/home" }}}}}```The keys are pathnames of device nodes in /dev.Each value is an object with a "type" field. The type determines whichother fields might be present, and what they mean. The followingtypes might appear:- "filesystem"A filesystem with an entry in fstab. A filesystem without subvolumeshas a "dir" field that is its mount point. A filesystem withsubvolumes has a "subvolumes" field that is a map from subvolumenames to mount points.There might also be both a "dir" and a "subvolumes" field. The "dir"field then has the mount point for the default subvolume of thefilesystem. This is hopefully rare.- "swap"A swap device. No other fields are present.- "crypto"An encrypted device. It has a "content" field with a value that isstructured like a value for "cockpit_mount_points", i.e., a objectwith a "type" field and maybe a "dir" field if "type" is"filesystem". This might also be present when the crypto device isclosed.It might also have a "cleartext_device" field if the encrypted deviceis currently open.Cockpit does some magic (via the "x-parent" options in fstab andcrypttab) to produce information also for locked LUKS devices, andinactive logical volumes.Cockpit also remembers and exports encryption passphrases in sessionstorage, in the "cockpit_passphrases" entry. This is a map from devicenames to cleartext passphrases. This is only done when Cockpit runs ina "secure context", seehttps://developer.mozilla.org/en-US/docs/Web/Security/Secure_ContextsCockpit Networking in Anaconda Mode===================================The Cockpit networking page behaves differently when it isused in Anaconda mode. Instead of the full networking page it shows asimplified layout that is adjusted for the requirements of the Anacondainstaller.Entering Anaconda mode----------------------Anaconda mode is activated the same way as on the storage page, bystoring a "cockpit_anaconda" item in `window.sessionStorage`. The valueshould be a JSON encoded object. Unlike on the storage page, none of thecontents are actually used by the networking page, so setting any validJSON encoded object is enough to activate the Anaconda layout.The code for this alternative layout lives in`pkg/networkmanager/anaconda` and is a simplified version of the regularnetworking page.