"TSC_DEADLINE disabled due to errata..." looking to prevent in future

Lemanr · 2020-12-22 23:03:44

Hello all!,

(Background info)
So I got the TSC_DEADLINE disabled due to errata....drops into emergency shell....then can't type issue.

I actually managed to solve this using advice from https://www.reddit.com/r/archlinux/comm … ncy_shell/
What seemed to have worked was going into live boot (USB), making sure UUIDs matched then

pacman -S linux linux-headers filesystem.
mkinitcpio -p linux

(The actual question)
So now I'm looking to 1) better understand the issue. 2) figure out a way to have better preventative measures. For example whatever I was supposed to be able to do in the emergency shell seemed to have totally failed so I'll be fixing that asap. But I am 99.9% sure I caused the original issue by getting sloppy with Arch maintenance. so I'll be re-reading that wiki.

If anyone has advice I'd ask you to keep it very general "I did [blank]" then let me research the suggestion then implement the suggestion. I've made so much progress from when I first started because I made myself be as independent as possible. Also any good linux/arch/computer science resources that might help me understand the issue and remember the information is always appreciated.

Anyway my first thoughts are to fix the issue with the emergency shell if possible & make a second boot option that is simply "bare bones" Arch. Something I will get running but then not update for longer periods of time.

Second thought, would this be a good reason to perhaps think about duel-booting with a second OS? I'm not sure if I could use a second OS to help resolve Arch booting issues should this happen again. Thanks all for the read

Last edited by Lemanr (2020-12-22 23:05:17)

Scimmia · 2020-12-23 00:02:49

If you fixed it by changing UUIDs, the message about TSC_DEADLINE had nothing to do with your problems.

What did you change, exactly?

loqs · 2020-12-23 00:10:21

The issue of being unable to type in the emergency shell is probably lack of drivers in the initd, so the solution depends on what you use to generate the initrd for mkinitcpio see Common Hooks.

A second OS would need to be able to access whatever file-system the kernel and initrd are stored on in order to be able to modify them.
If the issue required reinstalling the kernel or regenerating the initrd then the OS would need to support chrooting into the installed system or come with the required tools installed.
Commonly live / installtion media are used in such cases avoiding the need for a second OS install.

Last edited by loqs (2020-12-23 00:10:40)

Lemanr · 2020-12-23 00:30:53

@Scimmia I think I might have corrupted an important file by not updating my computer properly. I Unfortunately didn't save any pictures of the original messages. I forgot to add that I also generated a new fstab file and I saw some micro code issue so I used pacman to uninstall then reinstalled intell-ucode. I can add these details in OP later.

Lemanr · 2020-12-23 23:14:13

@loqs thanks for the direction. Honestly I know very little about the initd or how drivers actually work in a computer (I'm a psych major with some coding experience after all ). I'll probably get the most out of this by looking at drivers on a very general computer science level then work my way into how linux systems specifically recognize then utilize drivers.

btw for the second OS I'm leaning towards trying to make them share a filing system. While potential issues probably exist (like Arch trying to read files meant for the other OS) I think this can probably be worked around. For my uses I think the rewards would outweigh the potential problems (probably). The only other thing I wonder about is if one OS has a boot problem, wouldn't that automatically affect the other OS system (assuming they share a filing system) thus this wouldn't work as a preventative to the original issue? For the second OS I will probably do this regardless of the boot issue question because I'm "eyeing" the NeuroDebian OS atm and as a psych student this OS looks amazing but I need to see if this is a waste of a second OS (that depends on if Debian different enough from Arch to make my computer more versatile by adding Debian as a second OS). I seen that Arch can utilize .rpm & .deb extensions so it might be a waste to add Debian as a second OS.

I can see why just doing the live boot to resolve the issue is the most common solution. I just worry about the situation where I don't have anything to do a live boot with, like if I didn't have my USB with me which is why getting the emergency shell working correctly will be very important it seems.

loqs · 2020-12-23 23:47:51

Lemanr wrote:

btw for the second OS I'm leaning towards trying to make them share a filing system. While potential issues probably exist (like Arch trying to read files meant for the other OS) I think this can probably be worked around.

Arch will not mount / access another filesystem unless you configure it do so.

Lemanr wrote:

The only other thing I wonder about is if one OS has a boot problem, wouldn't that automatically affect the other OS system (assuming they share a filing system) thus this wouldn't work as a preventative to the original issue?

If the boot issue was with the bootloader or the ESP then it could impact both installations.

Lemanr wrote:

I seen that Arch can utilize .rpm & .deb extensions so it might be a waste to add Debian as a second OS.

pacman natively only supports .pkg files. If a package is not in the official repositories check AUR to see if a PKGBUILD is available. debtap can convert .deb to .pkg with varying success. You could install apt or yum then use them to install packages on Arch but this would almost certainly end in disaster.

Arch Linux

#1 2020-12-22 23:03:44

"TSC_DEADLINE disabled due to errata..." looking to prevent in future

#2 2020-12-23 00:02:49

Re: "TSC_DEADLINE disabled due to errata..." looking to prevent in future

#3 2020-12-23 00:10:21

Re: "TSC_DEADLINE disabled due to errata..." looking to prevent in future

#4 2020-12-23 00:30:53

Re: "TSC_DEADLINE disabled due to errata..." looking to prevent in future

#5 2020-12-23 23:14:13

Re: "TSC_DEADLINE disabled due to errata..." looking to prevent in future

#6 2020-12-23 23:47:51

Re: "TSC_DEADLINE disabled due to errata..." looking to prevent in future

Board footer