Qubes 4.0, T430, coreboot, nitrokey
xen_version: 4.8.5-35.fc25
Linux 5.4.136-1.fc25.qubes.x86_64
works
but with the latest dom0 update
xen_version: 4.8.5-35.fc25
Linux 5.4.143-1.fc25.qubes.x86_64
does not work. It freezes at:
[ xx.xxxxx] kexec_core: Starting new kernel
Edit: With the latest QOS dom0 update I had to update my NK (verify new /boot) I went into a crash which forced me to make a power off to reboot.
I have no efi/systab
cmdline="$cmdline acpi_rsdp=$(grep -m1 ^ACPI /sys/firmware/efi/systab | cut -f2- -d=)"
In firmware I have only:
acpi/
dmi/
memmap/
what is the content of acpi/
T430, coreboot, nitrokey
Is this a nitrokey laptop or have you made your own?
NitroPad T430 (pre-installed QOS, coreboot with NK Pro)
hotplug/
interrupts/
pm_profile
tables/
It does appear that someone else (unless this is you) has reported something very similar to Nitrokey. If this is not you, I recommend you post in that thread to identify that you too are unable to k’exec.
https://support.nitrokey.com/t/coreboot-nitrokey-pro-2-kernel-update-no-boot-possible/3427
If that post is you, then this left out some important information for this thread (namely that the system crashed during an update and there was a hard reset of the machine).
I have a self made T430 + Nitrokey on Q4.0 which I can try to update later and see if there is the same issue, however it wont be until this evening as I have things on today. You may have faster support from Nitrokey as the retailer.
It is me. (I fixed the HTOP issue; but still cannot boot into the latest QOS)
Sure, I will add this info.
Very much appreciated.
Depending at which stage of install the crash happened and what actions were taken, its very difficult to remotely diagnose this. In heads, HOTP is used to attest that the contents of the firmware/BIOS CBFS (including GPG cert) have not changed. The fact that HOTP. has got out of sync is concerning, as why would that happen when simply changing the contents of the OS? The only time Heads is concerned with the OS is that it validates the contents of /boot using GPG signing. The GPG key is in the BIOS firmware CBFS, and the HOTP attests the Heads firmware (and thus GPG key for /boot signing) has not changed
What I can factually tell from your posts (both here and at nitrokey) is: During an upgrade, your system behaved unexpectedly for an unknown reason. You did a hard reset. Your HOTP code then showed as not matching and your system wont boot any more. To try to get running again, you clicked on the buttons in Heads to re-sign /boot and also made a new HOTP by re-certifying the firmware as known good.
If i was in that situation I would be considering a full machine reset, refreshing heads using a SOIC and reinstalling the OS. I probably wouldn’t be re-certifying the firmware with a new HOTP code without understanding first why the existing HOTP became invalid. Thats kinda a big alarm bell in Heads.
I have the same: T430, i7-3840QM, Nitrokey Storage Pro, Coreboot/Heads … like NitroPad T430
I had almost daily and in certain contexts reproducible freezes with all 5.4 kernels from the start. No issues whatsoever with 4.19 kernel.
That shouldn’t invalidate HOTP though. Thats something in the firmware/TPM and worrying.
For sure. I am with you that the OP should take note and consider a potential compromise.
I just wanted to through in a general remark about the T430 and kernel 5.4 and was hoping to hear from you if you have similar issues.
Ive not had the t430 open in a while ive kinda got sidetracked with another security project … but i need to get the t430 done so will try to get some time with it tonight
My heads version is t430-maximised, version string is v0.2.0-1058-gb9468f5 with kernel 4.14.62-heads. CPU is 3740QM with DDR3L. I have tried with both 8Gb and 16G installed.
With a fresh from USB install of 4.0.4 using Xen 4.8.5 - it booted OK, worked fine and that was using kernel 5.4.98-1. I saw no usability issues
I then used the upgrade tool to update Dom0 which completed with no crashes. I rebooted.
Heads kexec’d into Kernel 5.4.143-1 (after me signing) with no issue whatsoever and its been up and stable for the last 6 minutes without anything weird happening.
@Sven - any pointers to reproducing? Is what you see something that happens under certain load and/or use conditions
I could make it happen reliably when verifying backups but at random times. A verify of my nightly backup takes 2-3 hours, the freeze could happen at any time during that period. It also happened once or twice while I was just working (maybe starting new qubes). I had the impression it was correlated to CPU load. It’s the first thing I do every morning while working on emails and being in meetings.
I’ll switch to 5.4 and see when it happens again.
For the last hour ive had two dispVM running the stress command in each
stress --cpu 3 --io 3 --vm 2 --vm-bytes 256M
Its worked without any issue. Ill leave it running overnight. maybe try stress in dom0 also
@whoami: my system was already up-to-date and I switched now to 5.4.143-1.fc25.qubes.x86_64 – could boot without issue.
@Plexus: a bit later today I have to run some errands, during that time I will let the verify from this morning run again. It already passed successfully this morning, so if it fails or freezes that’s pretty direct proof that it’s the kernel version that made the difference.
a bit later today I have to run some errands, during that time I will let the verify from this morning run again. It already passed successfully this morning, so if it fails or freezes that’s pretty direct proof that it’s the kernel version that made the difference.
I did NOT fail. It’s been a few months since I last tried a 5.4 kernel and the issue seems to be fixed. I will continue running 5.4 and report back if another freeze happens – for now it looks promising.
