If there is Steam problem :), there in Help->Steam Diagnostic Runtime dialog there is a list of issues what installed libs is missing or some issues with them, but there are sometimes some Steam itself bugs occurring.
So what exactly is the reason for you to install the insecure mainline builds instead of one of the supported kernels from the official archive ?
There are two kernels you can install from the archivem, one is the linux-generic package, the other is linux-generic-hwe-${YOUR_RELEASE_VERSION} which gives you the latest supported Ubuntu kernel, you should definitely not use mainline for anything unless you do not care about security and compatibility with the OS at all …
Note that we can not support systems with mainline installed here on this forum … the system will behave unpredictable (beyond having all the security and integration issues mainline brings along)
2 Likes
Do no get confused about UEFI/BIOS system motherboard firmware and linux-firmware.
UEFI/BIOS firmware is updated with fwupdate for most laptops with linux software. UEFI firmware must be manually done for most motherboards. See your motherboard manual. Some directly download from within UEFI settings, most have an update file you download into a FAT32 partition and from UEFI install it.
You may need to do similar manual updates for NVMe or SSD firmware, also.
The linux-firmware package provides firmware used by Linux kernel drivers and is updated with normal apt updates.
2 Likes
Very well. I tried installing the current version with “sudo apt install linux-generic” only for this to happen.
Hifron mentioned earlier to include a Diagnostic Runtime report on what Libs are missing. I tried copying and pasting the entire Diagnostic Report here, but there’s so much it caused my browser to freeze.
I’ll post what is required, but till I know further details I can only provide a few sample screen shots.
Really sorry bump this. I’ll understand if folks are busy, but I still seem to be stuck with using the 6.14.0-29-generic kernel. Given that I can’t stick with it forever due to security issues I respectfully would like some more input down the road at least.
For some system there is some Intel boot Setup required, but for fw gpu load(like for IPU6 webcam) there is also need INTEL_MEI_GSC to be enabled in kernel, which means also Intel Management Engine to be enabled if available or approved.
Configuring Secureboot is also possible, but weird but maybe there is need debug in GPU if some virtualization setup or long running task(for science compute) also present and hw supported.
But next LTS could make drivers more in fresh air without such driver harrassment…
gaming intel community
graphics intel community
software tools intel community
oneapi community
Well, what would you recommend the most easiest option would be?
purpose of the computer and time invested, work requirements be somehow affected…
Don’t seem to understand what you mean by that? Is there some information you need to clear things up. I’m willing to provide what I can. Seems I used the link for Installing Client GPUs.
https://dgpu-docs.intel.com/driver/client/overview.html
The end result was an error “Failed to read file: /tmp/dep-a36591.d”
In the " Supported Hardware" page which was located in the link you provided I seem to have gotten the message
“01:00.0 VGA compatible controller [0300]: NVIDIA Corporation AD104 [GeForce RTX 4070] [10de:2786] (rev a1)”
I assume that the 2786 is supposed to be the PCI Device ID based on what the terminal says, but it doesn’t seem to be on the list oddly enough.
ls /var/crash/*
journalctl -b -r
/var/log/* to see whats happening, install nvidia drivers or something else…
ls /var/crash/* will list the contents of directories in that directory, meaning you only need ls /var/crash without the *. So, try again without the *.
Thanks. It gives me a massive list of lines. Is there anything in particular I need to look out for?
Hate to bump again. The threads only good for about a week more and I don’t seem to be getting a reply. I updated the Kernel again. Seems the update was minor, but as always it still won’t boot. I can’t only currently boot with 6.14.0-29-generic. I tried ls /var/crash as eeickmeyer requested. I don’t know if or not he said “ls /var/crash/” alone, but it says “kdump_lock” when I do. When I ran the shell script before updating the kernel I got a message “Failed to execute child process “dbus-launch” (No such file or directory)” Once again sorry for bumping. I only have a finite amount of time with this topic.
On a functioning Linux system, running ls /var/crash will likely not output anything. I see nothing on my working Linux OS in that directory. The link below discusses briefly what the ‘kdump_lock’ output means. I can’t really help any more as I’m not familiar with it.
https://en.wikipedia.org/wiki/Kdump_(Linux)
The link below discusses kdump in more detail.
https://wiki.archlinux.org/title/Kdump
I don’t know that looking at the various files in /var/crash would be helpful to you.
With regards to /var/crash/ it seems to be what hifron and eeickmeyer recommended in a rather vague manner. I’m taking what I can get here. I looked into this kdump thing. I took a look at some instructions and got this.
I’ll see if rebooting now yields any results. Wish me luck
Update:
No luck, but I did indeed type in the terminal journalctl -p err -b -1 to filter the boot logs. This was the result.
The log “Failed to start localsearch-3.service - Tracker file system data miner” seems to be the most suspect a the moment however I tried a couple commands recommended via search as followed:
systemctl --user restart tracker-miner-fs-3.service
tracker3 reset -s
killall tracker-miner-fs-3
rm -rf ~/.cache/tracker3
systemctl --user mask tracker-extract-3.service tracker-miner-fs-3.service tracker-miner-rss-3.service tracker-writeback-3.service tracker-xdg-portal-3.service tracker-miner-fs-control-3.service
tracker3 reset --filesystem --rss
reboot
Unquote
No luck. I get messages like “Failed to restart tracker-miner-fs-3.service: Unit tracker-miner-fs-3.service not found.” and “tracker3: command not found”
I was intrigued by the title of this discussion, so I reviewed the various responses. I honestly couldn’t make sense of pretty much all of it.
So I went back to your original posting to try to understand your issue, and if I am not mistaken, your stated problem centers on the following,
and your response to seeing that being
First off, that has nothing to do with Linux, and even less with Ubuntu. It is a hardware capability which, by rights, should have been locked out, before shipment. If it wasn’t, my opinion (because I am not sure on how this board ended up in the “wild”) is that it was a reject that should have been scrapped, if the factory couldn’t “lock” post-configuration in-factory.
The “ME-BIOS” should be accessible at boot by pressing Ctl-P, which would allow you to change the settings.
You might want to give that a try before anything else.
Since the Management Engine is intended as a “BIOS pre-cursor” (my interpretation, not seen anywhere), you may wish to review the additional information that is out there on that specifically, with the following as a start point:
If you do a Google search with the following strings
"Intel Management Engine" "user guide"
the search AI will offer some extensive options on where to find the docs specific to that on-board chip function.
Hope that helps!
Glad to see a newcomer to this conversation, but your answers respectfully speaking are quite dated. If you’ve seen the previous comment I mentioned typing “journalctl -p err -b -1” to filter out the error logs to focus on the boot process. One log that comes to mind as mentioned in my last comment was "“Failed to start localsearch-3.service - Tracker file system data miner” which I think is rather important the way I see it.
I am intrigued and puzzled by your response. You again repeated your problem, referring back to the issue that I was trying to address!
So … are you saying that you are no longer concerned that the Motherboard ME-BIOS parameters are not protected from outside tampering? Does that mean that you have intervened to overcome that condition, but have not shared the actions taken in that regard with the Community that is attempting to assist?
The reason I ask that is because it seemed to me that the discussion went completely off the rails from your original issue … and OS boot would only “poke” at the motherboard for a “config/status” probe, never a “writing” or “tampering” to update of the BIOS contents!
The only Hardware-writing activity would take place using a tool like “fwupdmgr”, and that is a command-line action which is very much a conscious act … and definitely not an action performed during boot … unless someone was extremely misguided to the point of including that as part of the boot process managed by systemd.
Having ASRock point to the OS as a culprit, for that original concern, is them trying to avoid their responsibility for a production defect, fearing the need to replace that defect at their cost!
I respectfully suggest that you may wish to reconsider your stance regarding accepting their “deflection” of blame, which is allowing them off the hook!
Sorry. It’s just that there’s been alot of twist and turns over this. Currently i’m having issues with getting the latest Kernel to work. The only one I have that does work is 6.14.0-29-generic.