Anyone successfully running kernel 6.4?
I’ve been daily driving the ubuntu mainline kernels for years, including on framework 11th and 12th gen for the last couple years. 6.3.9 runs fine. 6.4 hangs at boot at “ima: Allocated hash algorithm: sha1”.
update, all the 6.4-rc versions also hang the same way. So it’s not just some change that happened at a point in time, it’s something about 6.3-any vs 6.4-any, ie, 6.4-rc1 was out long before the last few 6.3.x
It’s a hard lock too. The only way I’ve been able to proceed is to hold the power button for several seconds.
Same here with xanmod 6.4.0 on ArchLinux.
Got some progress with my custom kconfig, however this is failing when trying to access the TPM and starting systemd-pcrphase. Similar to the issue decribed here. I ensured to include all TPM drivers directly in the kernel and do not have tpm2-abrmd installed.
Appreciate you all testing this. Do keep us posted in this thread.
I don’t use the tpm at all. I do have a few things on the kernel command line.
GRUB_CMDLINE_LINUX_DEFAULT=“module_blacklist=hid_sensor_hub nvme.noacpi=1 mitigations=off intel_pstate=passive”
I don’t think any of that is suspect, even the pstate setting, but I’ll try without it just to see.
Similarly I guess I’ll try without being connected to the tb4 dock and external monitors, though this looks far too early in the process to care about any of that yet. More likely only effected by kernel commandline options, bios settings, and cpu model at that stage where it’s still just figuring out what kind of cpu it’s running on and what capabilities are available.
My motherboard is the i7-1280P with the 3.06 bios.
It’s reassuring that it’s neither just me nor just ubuntu. It’s possible it’s something just with the Framework hardware, but more likely it’s something in the upstream kernel and will affect enough other people that the kernel devs see it.
I happen to maintain the “mainline” app for installing the ubuntu mainline kernel packages, and a little while ago I added a couple features, one to lock kernel versions, which serves as both whitelist and blacklist, so you can tag a perticular kernel never to be installed, or never to be un-installed, and another to add user notes to each kernel, so you can write some free-form text like “broken wifi” etc and see it in the list of available kernels.
Until now I never actually had any use for them. The kernels all ran ok and I had no reason to blacklist any and had no notes to say about them.
So I’m in the weird position of 80% not liking that the kernel doesn’t run, but at least 20% liking that now I can actually use the features for a real instance of their intended purpose instead of just dummy examples for the docs.
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
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
Edit: Nevermind, I was stupid, I ran out of space on ‘/ boot’.
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.
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)
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
uname -sr and make sure it returns
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
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):