Chatted with David about this. CI on Packet for 4.4+TPM is red due to this. That said, no customer is currently hitting it (that we know of), and it would require a bootimage bump.
One concern is that although no customer may be hitting it, the fact that CI is failing on this means that we're potentially blind to any other regressions that may show up in 4.4 on TPM which customers *could* hit.
Reducing priority to low for this based on conversations.
Verified it is working on 4.4.0-0.nightly-2020-07-25-091418 with 44.81.202004250133-0 as boot image and 44.82.202007211530-0 as working image [root@master-00 ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 447.1G 0 disk |-sda1 8:1 0 384M 0 part /boot |-sda2 8:2 0 127M 0 part /boot/efi |-sda3 8:3 0 1M 0 part `-sda4 8:4 0 446.6G 0 part `-luks-00000000-0000-4000-a000-000000000002 253:0 0 446.6G 0 crypt /sysroot sdb 8:16 0 447.1G 0 disk sdc 8:32 0 223.6G 0 disk sdd 8:48 0 223.6G 0 disk Michael Nguyen, you can mark this bug as verified
Moving to MODIFIED, so the errata bot can pick this up.
Verified via comment #8.
I'm actually not sure why this now works. We haven't backported `random.trust_cpu=on` to 4.4. I suspect there's something in 8.2 which made this better (but not `CONFIG_RANDOM_TRUST_CPU` since that's still unset there). Anyway, if this works, then great!
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (OpenShift Container Platform 4.4.16 bug fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:3237