Found a thread about the TPM issues. Just cross referencing: Boot and shutdown hangs with Arch Linux, Kernel 6.4.1 Mainline and Arch - #4 by ethanmlee
It turned out I did not have TPM disabled in the BIOS. I had Trusted Execution disabled.
I set Security → TPM Availability → Hidden and now I can boot 6.4.0
Also I can say that adding the kernel command line option ima_policy=off does not help. It seems to really need to be disabled at compile-time.
Sucks if you still want to use TPM for windows but oh well.
I can only assume this won’t last long once more people hit it, even though it’s already been a couple months since 6.4.0-rc1
So I think the summary of available work-arounds as of now is:
-
Don’t use kernel 6.4.0. 6.3.x after 6.3.9 will probably be fine if they make any. 6.4.x after 6.4.0 will need to be tested when they come out.
-
Compile your own kernel or otherwise find one without CONFIG_IMA
-
BIOS → Security → TPM Availability → Hidden
2 Likes
Edit: Nevermind, I was stupid, I ran out of space on ‘/ boot’. 
2 Likes
That would do it.
Update, 6.4.1 and 6.4.2 are out by now, and nothing changed. I have to disable TPM in the bios in order to boot.
I’m not saying this is a Framework problem btw or expecting them to do anything. It may or may not be something peculiar to the Framework, but at this point I’m just relaying data for whatever unknowable use it may eventually have.
When I boot, I have to wait for three or four minutes for a timeout to get passed TPM2 PCR Barrier stage. When I shutdown the laptop the same issue happens.
There was a change that happened in the 6.4 kernel that introduced the bug, I noticed it around RC3.
Would appreciate any suggestions in forcing an earlier time out or whatever other suggestions people might have.
5 Likes
I have a similar issue with kernel 6.4.1, for me anytime I try and run systemctl reboot, hibernate, suspend, or shutdown the screen goes black, idles and never really does anything.
Unfortunately I think we will probably just have to wait and see if the next kernel update fixes the bug but you can either install the lts kernel and boot from that instead of 6.4.1, or roll back to 6.3.9. Would be more than happy to help you with that if you need it! When it comes down to it, the bleeding edge always comes with some bugs, and that’s ok.
edit: found this which seems to be similar [TRACKING] Kernel 6.4 hangs at "ima: Allocated hash algorithm: sha1"
I have the same thing as you, after unlocking the LUKS, it gets stuck at the TPM PCR2 phase (yes I use a full secure boot chain)
2 Likes
Just for anyone runs arch and doesn’t know how, this is how you roll back the kernel
Latest one that does not have issues for me is 6.3.9
sudo pacman -U linux-6.3.9.arch1-1-x86_64.pkg.tar.zst
sudo pacman -U linux-headers-6.3.9.arch1-1-x86_64.pkg.tar.zst
Then edit /etc/pacman.conf so we can keep the kernel from being updated anytime we want to update our system again.
Should be a line already with #IgnorePkg = so we just need to replace that with this:
IgnorePkg = linux linux-headers
I am not sure if when you roll back a kernel it is updated in grub so I went ahead and ran this as well:
sudo grub-mkconfig -o /boot/grub/grub.cfg
Then just hold the power button to reboot
lastly run uname -sr and make sure it returns Linux 6.3.9-arch1-1
You now can safely update your system without having to worry about dealing with the issues in 6.4.1.
This can also safely be done with the arch ISO if you can’t boot at all. Just mount your partitions, arch-chroot in, and then go through the steps above
3 Likes
Same issue here. When waiting for long enough my kernel prints more details about the stuck services.
Here is the stack for systemd-pcrphase:
This is the stack for systemd-cryptsetup (I use the TPM to unlock my LUKS drive. When disabling the TPM unlock, cryptsetup will successfully start and allow me to unlock by passphrase. However, it is still blocked on pcrphase):
A friend of mine does not face this issue with his Framework running Intel 11th Generation. Could you please confirm, that it only affects Framework Laptop with 12th Generation CPUs?
EDIT: Sorry, it is working on 11th gen, but fails on 12th gen.
Same situation over here, also ArchLinux Kernel 6.4.1 on Framework Laptop 13 13th Gen.
Thx that you already figured out that the kernel update seems to be to causing the problem, I was questioning my sanity for a short while xD
1 Like
I bisected the issue and it is caused by commit e644b2f498d297a928efcb7ff6f900c27f8b788e
Building the kernel after git checkout v6.4 && git revert e644b2f498d297a928efcb7ff6f900c27f8b788e results in a kernel which is booting fine for me.
I am going to file a bug in the Arch Tracker.
6 Likes
FS#78961 - Kernel 6.4 failing to access TPM on Framework Laptop 12th
Would be interesting to know whether there are any differences between the TPM chip of 11th gen and 12/13th gen.
2 Likes
@eumpf Sorry, for my mistake. 12th generation seems to face the issue while 11th gen works fine. Could you please confirm again that for you face the issue with gen 13?
Could you please also send the output of this?
# dmidecode -s system-manufacturer
# dmidecode -s system-version
Of course @TrailingEdge ! I can confirm that the same issue exists on the Framework Laptop 13 13th Gen with Archlinux default kernel 6.4.1.
I can also confirm that the Archlinux default 6.3.9 kernel does not suffer from this problem on this machine.
Here are the outputs you asked for:
# dmidecode -s system-manufacturer
Framework
# dmidecode -s system-version
A6
and some more:
# lshw -C bus -sanatize | head -n 7
*-core
description: Motherboard
product: FRANMCCP06
vendor: Framework
physical id: 0
version: A6
serial: [REMOVED]
# sudo lshw -C cpu -sanitize | head -n 6
*-cpu
description: CPU
product: 13th Gen Intel(R) Core(TM) i7-1360P
vendor: Intel Corp.
physical id: 4
bus info: cpu@0
If there’s any way I can help (e.g. test kernel with the offending commit reverted on 13th gen) I’ll gladly do so.
BTW: during boot specifically pcrphase etc. my system did not hang completely it just took ages to before it continued (not sure if the systemd services timed out or were just reaaallly slow)
EDIT: The commit testing for TPM IRQs reminds me of these warnings I have noticed in dmesg (but I have always had them) :
tpm tpm0: [Firmware Bug]: TPM interrupt not working, polling instead
Should anyone want to test this against Ubuntu Mainline RC of 6.4.* as a comparable, this would be extremely helpful. Would be interesting to see if this affected as well.
Same here! Tried adding LUKS + TPM2 but the enrollment was taking ages.
Switched on linux-lts kernel and enrolled in less than 5 seconds.
Can’t you just roll to an earlier kernel, 6.3#? A newer kernel is usually expected to have issues, so I don’t find this surprising.
If we just roll to an earlier kernel then we will find we have issues as soon as the kernel updates. It does not fix the problem when TPM is broken for newer kernels, it just means we need to raise attention with the kernel maintainers so they address the issue in the kernel.
3 Likes