)]}'
{
  "log": [
    {
      "commit": "35fcf0397be02883ace364e650b3e8d9a2281e24",
      "tree": "cb1297a2e4a34eeebb9faf09b44c3b95cf603f7f",
      "parents": [
        "ad131883747f73e51526dd6f163df23b913f69ed"
      ],
      "author": {
        "name": "Lorenz Brun",
        "email": "lorenz@monogon.tech",
        "time": "Thu Jun 29 04:15:58 2023 +0200"
      },
      "committer": {
        "name": "Lorenz Brun",
        "email": "lorenz@monogon.tech",
        "time": "Thu Jul 27 13:58:35 2023 +0000"
      },
      "message": "metropolis: implement A/B updates\n\nThis implements an A/B update mechanism using two slots, A and B.\nThis is realized with two system partitions as well as two EFI\nloaders/kernels.\n\nThe A/B system relies on two EFI loader entries. This has the advantage\nthat there is no preloader required, which makes the system more\nreliable as well as avoiding the complexity of having an un-updatable\npreloader (CoreOS has this issue where their GRUB2 crashed booting newer\nkernels, sadly the issue seems lost with the migration to Fedora\nCoreOS). It also means that the operator can easily override the slot\nbeing booted via the boot loader entries. Primary disadvantage is that\nit relies on EFI working somewhat to spec.\n\nNew versions are booted into only once by setting NextBoot, if the\nbootup doesn\u0027t succeed, i.e. if the boot doesn\u0027t get to a cluster rejoin\nthe next boot will be the old slot. Once it gets to this stage the\npermanent BootOrder is changed.\n\nThe EFI loaders don\u0027t know if they are slot A or B because they are\nidentical and relying on OptionalData in the boot entry to indicate the\nslot means that if the EFI boot entries go away, recovering is very hard.\nThus the loaders look at their own file name to determine what slot they\nare in. If no slot could be determined, they default to booting slot A.\nIt is planned to eventually use Authenticode Stamping (passing data in\nfake certificates) to stamp the slot into the loader without affecting\nthe TPM hash logged.\n\nChange-Id: I40de2df8ff7ff660c17d2c97f3d9eb1bd4ddf5bc\nReviewed-on: https://review.monogon.dev/c/monogon/+/1874\nTested-by: Jenkins CI\nReviewed-by: Serge Bazanski \u003cserge@monogon.tech\u003e\n"
    },
    {
      "commit": "aadeb798a1f92b3d69ec7d6cde1b4567c2140452",
      "tree": "6278ec3b6a732f2d27e7948bcba8e7a579d0e5b1",
      "parents": [
        "4bbd8b34a5e81a28219ae95bedf7915568557800"
      ],
      "author": {
        "name": "Lorenz Brun",
        "email": "lorenz@monogon.tech",
        "time": "Mon Mar 27 15:53:56 2023 +0200"
      },
      "committer": {
        "name": "Lorenz Brun",
        "email": "lorenz@monogon.tech",
        "time": "Thu Apr 06 14:26:33 2023 +0000"
      },
      "message": "c/agent: implement\n\nImplement the currently-required agent functionality, i.e. running with\nboth autoconfigured as well as static network configuration, interacting\nwith the BMaaS API and installing Monogon OS.\n\nThe early-stage setup is similar to Monogon OS itself, but after setting\nup the root supervisor this instead calls into the agent runnable which\nthen performs the rest of the work.\nIn the process I made both logtree as well as supervisor public as they\nare very generic and I see no reason to keep them scoped so tightly.\nMaybe we should move them to go/ at some point.\n\nThis currently calls into osimage without the optimization the\nregular installer performs, this is intentional as I have code which\nwill replace osimage with a high-performance version, obviating the\nneed to manually make this fast here.\n\nThis also comes with an end-to-end test\nwhich exercises the whole flow, installing TestOS and checking if it\nlaunches.\n\nChange-Id: Iab3f89598a30072ea565ec2db3b198c8df7999ef\nReviewed-on: https://review.monogon.dev/c/monogon/+/1405\nReviewed-by: Serge Bazanski \u003cserge@monogon.tech\u003e\nTested-by: Jenkins CI\n"
    }
  ]
}