{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":150454473,"defaultBranch":"testing-devel","name":"fedora-coreos-config","ownerLogin":"jlebon","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2018-09-26T16:10:37.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/11934099?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1724329034.0","currentOid":""},"activityList":{"items":[{"before":"8faac0ec3828e813c4419ab05a1ce1393e6d9b18","after":null,"ref":"refs/heads/pr/systemd-drop-branched","pushedAt":"2024-08-22T12:17:14.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"}},{"before":"d809b73a6ff165043ae199b5fdaff4d0f5cdc7d0","after":"8faac0ec3828e813c4419ab05a1ce1393e6d9b18","ref":"refs/heads/pr/systemd-drop-branched","pushedAt":"2024-08-22T00:09:15.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"overrides: fast-track systemd-256.5-1.fc41\n\nsystemd v256 added a new userdb functionality where SSH authorized\nkeys can be part of a User Record. To make this transparently\nwork with sshd authentication, an sshd config dropin that sets an\n`AuthorizedKeysCommand` directive was added.\n\nUnfortunately, it was added with a higher priority than intended,\nwhich meant that it overrode the `AuthorizedKeysCommand` directive from\n`ssh-key-dir`, which is how our `~/.ssh/authorized_keys.d/` magic works\ntoday with Ignition and Afterburn. So the end result is that this broke\nSSH which of course broke kola too.\n\nThis is tracked in upstream systemd at:\n\nhttps://github.com/systemd/systemd/issues/33648\n\nThe dropin was recently reverted in Fedora:\n\nhttps://src.fedoraproject.org/rpms/systemd/c/38291e13c1dec15618b7d09e4217d10076897cdf?branch=f41\n\nFast-track the latest f41 systemd build with that change.\n\nWe'll need to keep an eye on the conversation there to make sure that\nthe final solution doesn't re-break FCOS, but we would notice it pretty\nquickly too.\n\nCloses: https://github.com/coreos/fedora-coreos-tracker/issues/1775","shortMessageHtmlLink":"overrides: fast-track systemd-256.5-1.fc41"}},{"before":"612627891d054e1436ea1fb92d8ed9e24e9bf578","after":"db9a880ebb5da867e874dd46ff49fbdd7db6dcb0","ref":"refs/heads/pr/fast-track-systemd","pushedAt":"2024-08-22T00:07:27.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"overrides: fast-track systemd-256.5-1.fc42\n\nsystemd v256 added a new userdb functionality where SSH authorized\nkeys can be part of a User Record. To make this transparently\nwork with sshd authentication, an sshd config dropin that sets an\n`AuthorizedKeysCommand` directive was added.\n\nUnfortunately, it was added with a higher priority than intended,\nwhich meant that it overrode the `AuthorizedKeysCommand` directive from\n`ssh-key-dir`, which is how our `~/.ssh/authorized_keys.d/` magic works\ntoday with Ignition and Afterburn. So the end result is that this broke\nSSH which of course broke kola too.\n\nThis is tracked in upstream systemd at:\n\nhttps://github.com/systemd/systemd/issues/33648\n\nThe dropin was recently reverted in Fedora:\n\nhttps://src.fedoraproject.org/rpms/systemd/c/38291e13c1dec15618b7d09e4217d10076897cdf?branch=rawhide\n\nFast-track the latest rawhide systemd build with that change.\n\nWe'll need to keep an eye on the conversation there to make sure that\nthe final solution doesn't re-break FCOS, but we would notice it pretty\nquickly too.\n\nCloses: https://github.com/coreos/fedora-coreos-tracker/issues/1775","shortMessageHtmlLink":"overrides: fast-track systemd-256.5-1.fc42"}},{"before":null,"after":"d809b73a6ff165043ae199b5fdaff4d0f5cdc7d0","ref":"refs/heads/pr/systemd-drop-branched","pushedAt":"2024-08-21T21:14:01.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"overrides: drop systemd pins\n\nsystemd v256 added a new userdb functionality where SSH authorized\nkeys can be part of a User Record. To make this transparently\nwork with sshd authentication, an sshd config dropin that sets an\n`AuthorizedKeysCommand` directive was added.\n\nUnfortunately, it was added with a higher priority than intended,\nwhich meant that it overrode the `AuthorizedKeysCommand` directive from\n`ssh-key-dir`, which is how our `~/.ssh/authorized_keys.d/` magic works\ntoday with Ignition and Afterburn. So the end result is that this broke\nSSH which of course broke kola too.\n\nThis is tracked in upstream systemd at:\n\nhttps://github.com/systemd/systemd/issues/33648\n\nThe dropin was recently reverted in Fedora:\n\nhttps://src.fedoraproject.org/rpms/systemd/c/38291e13c1dec15618b7d09e4217d10076897cdf?branch=f41\n\nThe latest f41 systemd build with that change is already in the\nrepos:\n\nhttps://bodhi.fedoraproject.org/updates/FEDORA-2024-8d144cc8af\n\nSo we can just drop all the overrides to pull in the latest systemd.\n\nWe'll need to keep an eye on the conversation there to make sure that\nthe final solution doesn't re-break FCOS, but we would notice it pretty\nquickly too.\n\nCloses: https://github.com/coreos/fedora-coreos-tracker/issues/1775","shortMessageHtmlLink":"overrides: drop systemd pins"}},{"before":null,"after":"612627891d054e1436ea1fb92d8ed9e24e9bf578","ref":"refs/heads/pr/fast-track-systemd","pushedAt":"2024-08-21T21:11:39.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"overrides: drop systemd pins\n\nsystemd v256 added a new userdb functionality where SSH authorized\nkeys can be part of a User Record. To make this transparently\nwork with sshd authentication, an sshd config dropin that sets an\n`AuthorizedKeysCommand` directive was added.\n\nUnfortunately, it was added with a higher priority than intended,\nwhich meant that it overrode the `AuthorizedKeysCommand` directive from\n`ssh-key-dir`, which is how our `~/.ssh/authorized_keys.d/` magic works\ntoday with Ignition and Afterburn. So the end result is that this broke\nSSH which of course broke kola too.\n\nThis is tracked in upstream systemd at:\n\nhttps://github.com/systemd/systemd/issues/33648\n\nThe dropin was recently reverted in Fedora:\n\nhttps://src.fedoraproject.org/rpms/systemd/c/38291e13c1dec15618b7d09e4217d10076897cdf?branch=rawhide\n\nThe latest rawhide systemd build with that change is already in the\nrepos:\n\nhttps://bodhi.fedoraproject.org/updates/FEDORA-2024-ff872f0544\n\nSo we can just drop all the overrides to pull in the latest systemd.\n\nWe'll need to keep an eye on the conversation there to make sure that\nthe final solution doesn't re-break FCOS, but we would notice it pretty\nquickly too.\n\nCloses: https://github.com/coreos/fedora-coreos-tracker/issues/1775","shortMessageHtmlLink":"overrides: drop systemd pins"}},{"before":null,"after":"853c58efe2e7c5861cff715ba58dfedb5b803bbd","ref":"refs/heads/pr/bootc-symlink","pushedAt":"2024-08-21T13:52:07.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"tests/files/validate-symlinks: add bootc/storage symlink to allowlist\n\nThis symlink isn't broken on a system deployed via bootc, but it\nit is broken otherwise. Add the symlink to the allowlist for the test\nso it will pass.\n\nfixes: https://github.com/coreos/fedora-coreos-tracker/issues/1782\n(cherry picked from commit 88a473fc7230b064cc38e6632aa7155a00e6961e)","shortMessageHtmlLink":"tests/files/validate-symlinks: add bootc/storage symlink to allowlist"}},{"before":"cd3b942a72cfc35c775f4dbafa3eee41fb8a5304","after":null,"ref":"refs/heads/pr/rhcos-4.17-kernel-replace","pushedAt":"2024-08-20T19:09:29.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"}},{"before":null,"after":"cd3b942a72cfc35c775f4dbafa3eee41fb8a5304","ref":"refs/heads/pr/rhcos-4.17-kernel-replace","pushedAt":"2024-08-20T18:55:03.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"tests/kernel-replace: use `dnf repoquery` to get kernel version\n\nWhen testing from the c9s repos, don't hardcode a kernel version since\nit'll eventually cycle out of the mirrors. Instead, just query the repo\nto get the latest kernel.\n\nSince we need the info we queried across reboots and we don't want to\nquery it each time (and possibly get different answers), persist it in\n`/var` instead.\n\nIdeally we'd do this for FCOS too, but we need to wait until the f41\nrebase, which will bring dnf. (Or... could do it in a toolbox, but that\nseems overkill.) But anyway for now, the kernel from the stable Fedora\nrepo shouldn't ever be GC'ed.\n\n(cherry picked from commit 64c3a1cc3b38f6776d4ff45874572a284cc9f8f8)","shortMessageHtmlLink":"tests/kernel-replace: use <code>dnf repoquery</code> to get kernel version"}},{"before":"844b66a6a257ed2dfad4d36cb3c638f1ae31bee5","after":"fbc024c69c24c5341b5637d3dd297de192fb3e98","ref":"refs/heads/pr/kernel-replace-repoquery","pushedAt":"2024-08-20T16:27:00.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"tests/kernel-replace: use `dnf repoquery` to get kernel version\n\nWhen testing from the c9s repos, don't hardcode a kernel version since\nit'll eventually cycle out of the mirrors. Instead, just query the repo\nto get the latest kernel.\n\nSince we need the info we queried across reboots and we don't want to\nquery it each time (and possibly get different answers), persist it in\n`/var` instead.\n\nIdeally we'd do this for FCOS too, but we need to wait until the f41\nrebase, which will bring dnf. (Or... could do it in a toolbox, but that\nseems overkill.) But anyway for now, the kernel from the stable Fedora\nrepo shouldn't ever be GC'ed.","shortMessageHtmlLink":"tests/kernel-replace: use <code>dnf repoquery</code> to get kernel version"}},{"before":"3f156015e5af00a943b545c2daa0ba46053c3f0b","after":"844b66a6a257ed2dfad4d36cb3c638f1ae31bee5","ref":"refs/heads/pr/kernel-replace-repoquery","pushedAt":"2024-08-20T16:24:51.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"tests/kernel-replace: use `dnf repoquery` to get kernel version\n\nWhen testing from the c9s repos, don't hardcode a kernel version since\nit'll eventually cycle out of the mirrors. Instead, just query the repo\nto get the latest kernel.\n\nSince what we queried needs to survive a reboot and we don't want to\nquery it each time (and get different answers), persist it in `/var`\ninstead.\n\nIdeally we'd do this for FCOS too, but we need to wait until the f41\nrebase, which will bring dnf. (Or... could do it in a toolbox, but that\nseems overkill.) But anyway for now, the kernel from the stable repo\nshouldn't ever be GC'ed.","shortMessageHtmlLink":"tests/kernel-replace: use <code>dnf repoquery</code> to get kernel version"}},{"before":"c5aafbeb072a5c0c8f0f69c04f0631e5c791ce98","after":"3f156015e5af00a943b545c2daa0ba46053c3f0b","ref":"refs/heads/pr/kernel-replace-repoquery","pushedAt":"2024-08-20T16:20:55.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"tests/kernel-replace: use `dnf repoquery` to get kernel version\n\nWhen testing from the c9s repos, don't hardcode a kernel version since\nit'll eventually cycle out of the mirrors. Instead, just query the repo\nto get the latest kernel.\n\nIdeally we'd do this for FCOS too, but we need to wait until the f41\nrebase, which will bring dnf. (Or... could do it in a toolbox, but that\nseems overkill.) But anyway for now, the kernel from the stable repo\nshouldn't ever be GC'ed.","shortMessageHtmlLink":"tests/kernel-replace: use <code>dnf repoquery</code> to get kernel version"}},{"before":null,"after":"c5aafbeb072a5c0c8f0f69c04f0631e5c791ce98","ref":"refs/heads/pr/kernel-replace-repoquery","pushedAt":"2024-08-20T16:11:38.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"tests/kernel-replace: use `dnf repoquery` to get kernel version\n\nWhen testing from the c9s repos, don't hardcode a kernel version since\nit'll eventually cycle out of the mirrors. Instead, just query the repo\nto get the latest kernel.\n\nIdeally we'd do this for FCOS too, but we need to wait until the f41\nrebase, which will bring dnf. (Or... could do it in a toolbox, but that\nseems overkill.) But anyway for now, the kernel from the stable repo\nshouldn't ever be GC'ed.","shortMessageHtmlLink":"tests/kernel-replace: use <code>dnf repoquery</code> to get kernel version"}},{"before":null,"after":"e70db9773df07d4c754f9004404343a5b3cf5db9","ref":"refs/heads/pr/rawhide-test-selinux","pushedAt":"2024-07-18T20:01:47.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"overrides: fast-track selinux-policy-41.9-1.fc41\n\nThe SELinux-related issues should be fixed now.","shortMessageHtmlLink":"overrides: fast-track selinux-policy-41.9-1.fc41"}},{"before":"02484b77f21c362fc1bfb4c3ddeaf805851abc6d","after":null,"ref":"refs/heads/pr/pin-more","pushedAt":"2024-07-10T19:46:05.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"}},{"before":null,"after":"02484b77f21c362fc1bfb4c3ddeaf805851abc6d","ref":"refs/heads/pr/pin-more","pushedAt":"2024-07-10T13:34:46.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"overrides: pin json-glib and selinux-policy\n\nA lot of things are pinned right now because of a bunch of SELinux\nissues.\n\nAs a result, we haven't had a new rawhide build in almost a month, and\nthis is starting to affect the reliability of Bodhi testing. Let's pin\nthe problematic packages for now to get a build out.","shortMessageHtmlLink":"overrides: pin json-glib and selinux-policy"}},{"before":null,"after":"e38e0abbd5322f92fc48e5e903515f49e552851a","ref":"refs/heads/pr/unpin-kernel-6.18","pushedAt":"2024-07-05T14:16:11.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"Revert \"overrides: pin kernel-6.8.11-300.fc40\"\n\nThis reverts commit 8d4e788b5eedd284a91ba13144e78e47c1576f07.\n\nNow that we shipped bootloader updates for Secure Boot systems, we no\nlonger need to pin to v6.8.\n\nSee also: https://github.com/coreos/fedora-coreos-tracker/issues/1752","shortMessageHtmlLink":"Revert \"overrides: pin kernel-6.8.11-300.fc40\""}},{"before":"7b536a21cad7b0e277f10796c565b1642a2cacf4","after":"5df6904fa3e41dc6b4619324f8cd8bee583c12f0","ref":"refs/heads/pr/qed-firmware","pushedAt":"2024-06-26T21:11:27.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"manifests/fedora-coreos-base: re-add qed-firmware\n\nWe lost this during a recent linux-firmware update which broke it out\ninto a separate subpackage. Re-add it.\n\nCloses: https://github.com/coreos/fedora-coreos-tracker/issues/1746","shortMessageHtmlLink":"manifests/fedora-coreos-base: re-add qed-firmware"}},{"before":null,"after":"7b536a21cad7b0e277f10796c565b1642a2cacf4","ref":"refs/heads/pr/qed-firmware","pushedAt":"2024-06-26T20:44:46.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"manifests/fedora-coreos-base: re-add qed-firmware\n\nWe lost this during a recent linux-firmware update which broke it out\ninto a separate subpackage. Re-add it.\n\nCloses: https://github.com/coreos/fedora-coreos-tracker/issues/1746","shortMessageHtmlLink":"manifests/fedora-coreos-base: re-add qed-firmware"}},{"before":null,"after":"b8480ca30808e033a7343d7d30d9e57d190b7411","ref":"refs/heads/pr/4.16-512e-fix","pushedAt":"2024-06-21T19:00:55.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"growfs: workaround sfdisk + LUKS incompatibility on 512e disks\n\nOn 512e disks, `sfdisk` (which is used by `growpart`) will end up\ngrowing the rootfs to a size not aligned to a 4K boundary. This is\nmostly fine because, well, the drive claims to be 512b-compatible.\n\nIssues arise however if one wants to also put LUKS on top: cryptsetup,\ntrying to optimize performance, wants to set the sector size of the LUKS\ndevice to that of the physical value, which is 4K. But if the partition\nrange itself isn't 4K-aligned, it will choke.\n\nIdeally, this should be fixed in sfdisk:\nhttps://github.com/util-linux/util-linux/issues/2140\n\n(Though cryptsetup could also learn to align the mapped area itself).\n\nAnyway, for now work aorund this by manually checking if the size of\nthe partition is a multiple of 4k. If not, and the physical sector size\nis 4k, then trim off the edge of the partition to make it so. Note the\npartition start is always going to be aligned (they're 1M-aligned).\n\nCloses: https://github.com/coreos/fedora-coreos-tracker/issues/1384\nCloses: https://issues.redhat.com/browse/OCPBUGS-35410\n\nSee also: https://gitlab.com/cryptsetup/cryptsetup/-/issues/585\n\n(cherry picked from commit 067e1f767de6f308d08b5ed0b3560f2c185e6c91)","shortMessageHtmlLink":"growfs: workaround sfdisk + LUKS incompatibility on 512e disks"}},{"before":"01a99da89cf1da480aae6a99f771e1cdadd8425e","after":null,"ref":"refs/heads/pr/growfs-512e-fix","pushedAt":"2024-06-21T18:59:46.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"}},{"before":"378f8685ff2bea24888168c670f79cf770996417","after":"01a99da89cf1da480aae6a99f771e1cdadd8425e","ref":"refs/heads/pr/growfs-512e-fix","pushedAt":"2024-06-20T18:41:18.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"growfs: workaround sfdisk + LUKS incompatibility on 512e disks\n\nOn 512e disks, `sfdisk` (which is used by `growpart`) will end up\ngrowing the rootfs to a size not aligned to a 4K boundary. This is\nmostly fine because, well, the drive claims to be 512b-compatible.\n\nIssues arise however if one wants to also put LUKS on top: cryptsetup,\ntrying to optimize performance, wants to set the sector size of the LUKS\ndevice to that of the physical value, which is 4K. But if the partition\nrange itself isn't 4K-aligned, it will choke.\n\nIdeally, this should be fixed in sfdisk:\nhttps://github.com/util-linux/util-linux/issues/2140\n\n(Though cryptsetup could also learn to align the mapped area itself).\n\nAnyway, for now work aorund this by manually checking if the size of\nthe partition is a multiple of 4k. If not, and the physical sector size\nis 4k, then trim off the edge of the partition to make it so. Note the\npartition start is always going to be aligned (they're 1M-aligned).\n\nCloses: https://github.com/coreos/fedora-coreos-tracker/issues/1384\nCloses: https://issues.redhat.com/browse/OCPBUGS-35410\n\nSee also: https://gitlab.com/cryptsetup/cryptsetup/-/issues/585","shortMessageHtmlLink":"growfs: workaround sfdisk + LUKS incompatibility on 512e disks"}},{"before":null,"after":"378f8685ff2bea24888168c670f79cf770996417","ref":"refs/heads/pr/growfs-512e-fix","pushedAt":"2024-06-20T16:35:20.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"growfs: workaround sfdisk + LUKS incompatibility on 512e disks\n\nOn 512e disks, `sfdisk` (which is used by `growpart`) will end up\ngrowing the rootfs to a size not aligned to a 4K boundary. This is\nmostly fine because, well, the drive claims to be 512b-compatible.\n\nIssues arise however if one wants to also put LUKS on top: cryptsetup,\ntrying to optimize performance, wants to set the sector size of the LUKS\ndevice to that of the physical value, which is 4K. But if the partition\nrange itself isn't 4K-aligned, it will choke.\n\nIdeally, this should be fixed in sfdisk:\nhttps://github.com/util-linux/util-linux/issues/2140\n\n(Though cryptsetup could also learn to align the mapped area itself).\n\nAnyway, for now work aorund this by manually checking if the size of\nthe partition is a multiple of 4k. If not, and the physical sector size\nis 4k, then trim off the edge of the partition to make it so. Note the\npartition start is always going to be aligned (they're 1M-aligned).\n\nCloses: https://github.com/coreos/fedora-coreos-tracker/issues/1384\nCloses: https://issues.redhat.com/browse/OCPBUGS-35410\n\nSee also: https://gitlab.com/cryptsetup/cryptsetup/-/issues/585","shortMessageHtmlLink":"growfs: workaround sfdisk + LUKS incompatibility on 512e disks"}},{"before":"96f72d71802decfe080edd9abd3ea2141abeeac7","after":null,"ref":"refs/heads/pr/rhcos-tweaks","pushedAt":"2024-06-19T01:17:35.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"}},{"before":null,"after":"96f72d71802decfe080edd9abd3ea2141abeeac7","ref":"refs/heads/pr/rhcos-tweaks","pushedAt":"2024-06-18T21:01:05.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"tests/kola: adapt for new pure-RHEL variants\n\nA big part of the new variants added in\nhttps://github.com/openshift/os/pull/1445 is that we only minimally\nmodify `/etc/os-release`. This means that e.g. `ID` is still `rhel` and\n`VERSION_ID` is e.g. `9.4` for the `rhel-9.4` variant. We do still\ninject `VARIANT` and `VARIANT_ID` though.\n\nAdapt these library functions here to handle this.","shortMessageHtmlLink":"tests/kola: adapt for new pure-RHEL variants"}},{"before":null,"after":"a31af91592fdcc3d96abc951fac4770468760033","ref":"refs/heads/pr/ignition-setup-user-copy","pushedAt":"2024-06-18T20:04:01.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"coreos-ignition-setup-user: remount /usr rw if needed\n\nsystemd v256 now runs the initrd with `ProtectSystem=yes`, which makes\n`/usr` read-only:\n\nhttps://github.com/systemd/systemd/blob/07748c53df5a72111d8b3eef49d275210d6018cd/NEWS#L168-L175\n\nThis breaks coreos-ignition-setup-user which wants to copy the Ignition\nconfig to `/usr/lib/ignition`.\n\nI think the right fix for this is to have Ignition learn to also source\nfrom `/etc` and `/run`, which is the standard nowadays:\n\nhttps://github.com/coreos/ignition/issues/1891\n\nBut for now at least, we can safely remount `/usr` read-write ourselves\nwithout affecting the rest of the system since we're already running\nwith `MountFlags=slave`.","shortMessageHtmlLink":"coreos-ignition-setup-user: remount /usr rw if needed"}},{"before":"7136789e17b1f3f3c8d12019ae2c3c08e01600c4","after":null,"ref":"refs/heads/pr/openshift-os-backport-4.16","pushedAt":"2024-06-18T14:58:26.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"}},{"before":null,"after":"7136789e17b1f3f3c8d12019ae2c3c08e01600c4","ref":"refs/heads/pr/openshift-os-backport-4.16","pushedAt":"2024-06-18T14:48:12.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"workflows/openshift-os: add rhcos-4.16\n\nThis should probably be in the branching steps for RHCOS.","shortMessageHtmlLink":"workflows/openshift-os: add rhcos-4.16"}},{"before":"d82ac00d53c8d348c9f257c81c6c08eae8521086","after":null,"ref":"refs/heads/pr/4.15-mpath-fix","pushedAt":"2024-06-18T14:32:44.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"}},{"before":"9ded597f793dd03eec8689cbdc4abc6e2233e880","after":null,"ref":"refs/heads/pr/4.16-mpath-fix","pushedAt":"2024-06-18T14:32:43.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"}},{"before":"3666fc4278e6be043710c5ee71adf9451d6b2e17","after":null,"ref":"refs/heads/pr/4.14-mpath-fix","pushedAt":"2024-06-18T14:32:41.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEoUDCxAA","startCursor":null,"endCursor":null}},"title":"Activity · jlebon/fedora-coreos-config"}