Tried with no kernel commandline options. No difference.
Looked around in the bios for possible settings but I don’t see anything. This is a meaningless statement but there are 100 settings and I’m not going to list them all.
Trusted execution is disabled.
The last message you see on a hang is probably not the thing that caused the hang but the last thing that actually worked normally.
So just for the sake of no particular reason since I don’t think any of us can do anything but whatever, here are the next few kernel messages on a normal boot.
I included a little more just to show where it is in the grand scheme, that this is before /init is even looked at.
[ 2.425779] ima: Allocated hash algorithm: sha1 <== last line you see on the hang
[ 2.455504] ima: No architecture policies found
[ 2.457087] evm: Initialising EVM extended attributes:
[ 2.458449] evm: security.selinux
[ 2.459448] evm: security.SMACK64
[ 2.460408] evm: security.SMACK64EXEC
[ 2.461364] evm: security.SMACK64TRANSMUTE
[ 2.462279] evm: security.SMACK64MMAP
[ 2.463164] evm: security.apparmor
[ 2.464063] evm: security.ima
[ 2.464927] evm: security.capability
[ 2.465806] evm: HMAC attrs: 0x1
[ 2.467095] PM: Magic number: 11:551:48
[ 2.471618] RAS: Correctable Errors collector initialized.
[ 2.480496] Freeing unused decrypted memory: 2036K
[ 2.482183] Freeing unused kernel image (initmem) memory: 4688K
[ 2.488937] Write protecting the kernel read-only data: 34816k
[ 2.490788] Freeing unused kernel image (rodata/data gap) memory: 1588K
[ 2.497508] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[ 2.498507] Run /init as init process
[ 2.499473] with arguments:
[ 2.499474] /init
[ 2.499475] with environment:
[ 2.499475] HOME=/
[ 2.499475] TERM=linux
[ 2.499476] BOOT_IMAGE=/boot/vmlinuz-6.3.9-060309-generic
Running 6.4.0-1 on Manjaro testing with no issues. Happy to supply additional information if it may be helpful, just let me know what. Best of luck.
That’s already useful enough. I can try a manjaro thumb drive and see what happens. Thanks.
You could try to use a kernel with disabled CONFIG_IMA option. I think this is why my custom config does not stall at this line. According to the gentoo wiki IMA should be enabled “for development purposes only.”
Seeing the same TPM problems for linux-core 6.4.1 on ArchLinux. However, since I assume my TPM problems are not related to your IMA freeze, I will probably search for a better location to add any details about this one and not spam this thread 
1 Like
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