Utilities that expected /dev/pts will now be satisfied,
as a new /dev/pts is mounted.
Further, systemd added a check in various utilities that
was fouled by the previous method of appearing to have a
root filesystem.
Before, after chroot, we would bind mount / to itself, and this
made things using /proc/mounts, /proc/self/mountinfo, df, mount,
etc happy that there is a real looking root filesystem.
However, by doing it after the chroot, systemd could statx on '..' and
get a different mnt id than /. So it had to be done prior to the
chroot. However it also had to be done before other mounts as
bind mounting over it would block the submounts.
This more closely imitates the initramfs behavior, where '/' starts life
as a 'real' filesystem before being mounted up and switched into.
This behavior was made to imitate the 'start_root.c' behavior as that
seems to be more broadly successful.
If an asynchronous handler is slow to
enroll a target while another target causes an iteration
of the snoop loop, the various modified structures
had been discarded in the interim.
Now persist the data structures iteration to iteration,
using 'clear()' to empty them rather than getting
brand new data structures each loop.
For XCC3, change to generic redfish onboarding mechanism.
Extend the generic mechanism to be more specific in some
ways that the XCC3 is pickier about. However, it's just reiteration
of what should have already have been the case.
V4 Lenovo servers will have XCC3, and will have differences
and mark an unambiguously redfish capable onboarding process.
For now identify XCC3 variants and mark them, stubbing them
to the xcc handler.
An XCC3 handler will be made basing on the generic redfishbmc handler
with accomodations for XCC specific data (e.g. DeviceDescription
attributes and the Lenovo default user/password choice).
While stock OpenBmc does not care about subprotocols,
some implementations use it as a carrier for the XSRF-TOKEN.
Since base OpenBmc ignores it, we just offer it to any implementation
just in case.
Provide mechanism for administrator to place a custom
key for potential interactive recovery into
/var/lib/confluent/private/os/<profile>/pending/luks.key
If not provided, generate a unique one for each install.
Either way, persist the key in /etc/confluent/luks.key, to
facilitate later resealing if the user wants (clevis nor systemd
prior to 256 supports unlock via TPM2, so keyfile is required
for now).
Migrating to otherwise escrowed passphrases and/or sealing to
specific TPMs will be left to operators and/or third parties.
The comment based hook is destroyed during early install process.
Use python to manipulate the autoinstall file in a more sophisticated way.
Also refactor the initramfs hook material to be standalone files.
Particularly if traversing a lot of linked configuration, the same key/cert
path may come up multiple times, check for equality
and if equal, just keep going.
Particularly if traversing a lot of linked configuration, the same key/cert
path may come up multiple times, check for equality
and if equal, just keep going.
Previously, items were randomly arranged in lists in the json dump. This meant that the JSON files were different after each export.
Now they are naturally sorted and identical.
This should make it easier to save and compare the JSON dumps in version control systems.
Start implementing a tpm2-initramfs-tool based approach.
This requires a bit of an odd transition as the PCR 7 is likely
to change between the install phase and the boot phase, so
we have to select different PCRs, but that requires
an argument to pass that crypttab does not support.
