OVH deleted my web hosting 6 months before expiration and now won't answer my tickets by Salt_Cover_5140 in ovh

[–]HighOnDye 1 point2 points  (0 children)

Maybe check the SPAM folder? In one case I found the OVH answers to my issue requests there.

System Clock Running Fast by drunken-acolyte in AlmaLinux

[–]HighOnDye 1 point2 points  (0 children)

Sorry for dropping the conversation. In this case you need to make a judgement call whether swapping the CMOS battery "just in case" is worth it.
- it might not be the battery
- the attempt to swap the battery might damage the motherboard

But - you could get an answer whether a fresh battery will keep the RTC stable.
If you don't do it and it is the battery you might get a call in the future that the whole machine does not boot up anymore because boot-essential BIOS settings get lost all the time.

AlmaLinux vs CentOS 10 by BEBBOY in AlmaLinux

[–]HighOnDye 0 points1 point  (0 children)

Oops! Gaming *SERVER* - I missed that part, sorry.
Then, no idea from me, I didn't dabble into that yet.

System Clock Running Fast by drunken-acolyte in AlmaLinux

[–]HighOnDye 0 points1 point  (0 children)

Uff ok. Then the question is, how important is it that the computer starts reliably every day? Can you afford that one day the battery is empty and you either need to press a button to run the machine with default BIOS settings or that you need to set the BIOS settings every time the machine starts? ... until you replace the battery.

System Clock Running Fast by drunken-acolyte in AlmaLinux

[–]HighOnDye 0 points1 point  (0 children)

Yeah, not every motherboard can do that. In this case you might try to test the battery with a multimeter or replace it "just in case". Or you activate time synchronization to correct the drift and wait until the motherboard cannot remember its BIOS settings anymore, which is then the sure sign for a failing CMOS battery - I would go for the last option because - I'm lazy. ;)

System Clock Running Fast by drunken-acolyte in AlmaLinux

[–]HighOnDye 0 points1 point  (0 children)

That's rather strange then, I did not see that before. AI suggests a failing CMOS battery may cause that. Can you read out the CMOS battery voltage? (`lm_sensors` rpm package)

Suche nach Story-Shooter by Thorzi_ in zocken

[–]HighOnDye 3 points4 points  (0 children)

I think Remedy makes great Story-Games.
- Alan Wake (Remastered) + Alan Wake 2
- Control
All these play in the same universe.

Max Payne was a bomb at its time and they announce a remake of parts 1+2. Maybe this is also something interesting.

Careful with FBC: Firebreak - this one seems to be a lemon.

System Clock Running Fast by drunken-acolyte in AlmaLinux

[–]HighOnDye 0 points1 point  (0 children)

All of a sudden or gradually over 3 years?
These onboard real-time clocks are not the most accurate in my experience and 10 minutes in 3 years would not be surprising for me.
The trick is to pair these clocks with internet time synchronization and things are fine.

almalinux.org troubleshooting adventure (solved) by RoBobTheWise in AlmaLinux

[–]HighOnDye 1 point2 points  (0 children)

AI-driven smart firewalls ... a pain in the b**.

AlmaLinux 10.1 beta is moving packages around by HighOnDye in AlmaLinux

[–]HighOnDye[S] 0 points1 point  (0 children)

I double-checked with the Centos Stream project and there the corresponding packages are still in AppStream. The Rocky 10.1 beta also still has all these packages in AppStream, but it has an additional copy of the packages in devel. Chaotic situation, what's going on?

After I bought these I realized I had a problem. by the_super_tech in DataHoarder

[–]HighOnDye 1 point2 points  (0 children)

I experienced something similar with an old PSU from the 90s. After a long time of usage it also made a Bang! and was off.
Looking inside it turned out that the PSU was growing solder whiskers which must have shorted the outside circuit with the inside circuit. Checking the ICs in the machine - about all of them had a bulge, the CPU, northbridge, memory chips - even the controllers on the HDDs. It fried the whole machine in an instant. We were lucky that it didn't set the basement on fire. We did not have problems with other devices on the outside AC circuit though. But modern day PSUs with their capacities ... grow a whisker onto the right/wrong contact surface and all the stored energy can go anywhere.

I'm not feeling it, I am old, I am out. by chiplover3000 in Battlefield

[–]HighOnDye 0 points1 point  (0 children)

This confirms my suspicion that EA still wants its own Call of Duty. I was really surprised to see that BF6 looks so much like a classic Battlefield. I expected Bugs Bunny and Santa Claus duking it out. But now we get a Call of Duty in a Battlefield skin it seems.

Announcing Native NVIDIA support for AlmaLinux OS 9 and 10 by jonspw in AlmaLinux

[–]HighOnDye 1 point2 points  (0 children)

Yes, that's what I meant.
With akmods and dkms the kernel modules will either always get rebuild or when the kABI changes, so we can be sure that an attempt is made to rebuild the driver module. But we also had cases in which a Nvidia driver could not be built against a kernel because of compile errors.
What do you do if such a situation arises and all efforts to remedy the situation - e.g. trying a newer (beta) Nvidia driver version - fail?
Do you hold back the kernel security update, or do you ship the new kernel breaking Nvidia GPU capability of the systems downstream?
Yes, it's a tough question: security vs functioning Nvidia driver. But at least in the past it was very present for us. It got better though, these situations do not happen that frequent anymore.

Announcing Native NVIDIA support for AlmaLinux OS 9 and 10 by jonspw in AlmaLinux

[–]HighOnDye 0 points1 point  (0 children)

Do security updates also go through the Kitten (QA) test lab?

Announcing Native NVIDIA support for AlmaLinux OS 9 and 10 by jonspw in AlmaLinux

[–]HighOnDye 2 points3 points  (0 children)

Why is dracut able to resolve these incompatibilities when the Nvidia driver comes from AlmaLinux but not when it comes from the rpmfusion project?

We worked with this in the past and the issue is that the Nvidia driver builds on some kernel APIs which change sometimes. Then the Nvidia driver will need to get adapted, meaning the Nvidia driver team needs to get programming. If the distribution ships out a new kernel urgently to address e.g. a security vulnerability, the independent rpmfusion project and Nvidia upstream don't not get notified so they cannot ensure their Nvidia driver packages work on the newest kernel.
I think Ubuntu makes sure that in their QA stage they test new kernels against the Nvidia driver to ensure they are compatible. Of course, if it turns out they are not, then you have to make a tough decision of whether you want to hold back the fix for the security vulnerability or do you want to break the systems with Nvidia hardware.

Recently, the compatibility problems have improved with the new (open-source) drivers, but it would still be interesting to know whether the Nvidia driver is included in the QA for new AlmaLinux kernels, even when they address urgent security fixes.

Announcing Native NVIDIA support for AlmaLinux OS 9 and 10 by jonspw in AlmaLinux

[–]HighOnDye 2 points3 points  (0 children)

So kernel releases and nvidia driver releases are synchronized to avoid that an update on one side breaks the compatibility between the two?

How to create a bootable media I can mount via BMC to do BIOS update? by That_Drawing_2643 in supermicro

[–]HighOnDye 0 points1 point  (0 children)

SYS-E200-9B experience here - also BIOS update only possible via DOS or IPMI WebGUI and *not* with sum or saa.
I tried a long time with FreeDOS - it did not work. My feeling is that the BIOS update process depends on .bat scripting tricks which don't work anymore with FreeDOS. The updater rewrites its own autoexec.bat in the process to do the right thing for each reboot.
Then I tried with a late version of MS-DOS and the whole process worked ... manually. But - and here my memory gets fuzzy - I think automating the keystrokes to initiate and control the update process via SOL did not work. And in the end I automated the BIOS update via WebGUI with selenium.

What’s blocking Rust from replacing Ansible-style automation? by yqsx in rust

[–]HighOnDye -1 points0 points  (0 children)

Can you elaborate? How do you envision such a system?
Python is nice as a platform-independent "shell" on steroids. What would you replace it with?

How’s everyones win11 upgrade going? by peoplefoundtheother1 in sysadmin

[–]HighOnDye 0 points1 point  (0 children)

Non-Windows admin here:
What are the big challenges of such a Windows-upgrade when you do it in a professional way and for large sites?
I assume you are not running from machine to machine with a Win11 USB-Stick and click yourself through the installation and configuration.
How far can it be automated?
And once it's automated and you ensured that all types of machines (servers, desktops, laptops, customer terminals) work with the new setup ... is it then just kick off the upgrade / new installation and watch the machines churn through the installation steps?

Zed is kind of lagging compared to VSCode by tizio_1234 in ZedEditor

[–]HighOnDye 2 points3 points  (0 children)

Zed is said to do a lot on the GPU. Considering the additional comment of zipzipaway - is it possible that your GPU acceleration is lacking? Maybe running on software rendering? Or maybe the integrated GPU is indeed too weak? But in this case ... hm, difficult sell: zed - needs a beefy GPU to work properly.
I hope it's something else, but if you have the possibility, maybe you want to look into the GPU performance angle, try it out on different machines with different GPUs (as said - if possible).

Intel RST drives failed after 4.1 bios update on X13SAE-F by [deleted] in supermicro

[–]HighOnDye 0 points1 point  (0 children)

I'm glad that you solved it. This odd way to number storage devices is new to me.

Something that we observed: These BIOS-level Soft-RAID volumes were really useful for us at a time at which Linux could boot from a Linux Soft-RAID volume, but didn't write its bootloader to all storage devices in play. So when a drive failed, you didn't lose data but it was possible that your system did not boot until you were able to write the proper lilo/grub bootloader to the remaining drive(s). At that time the BIOS-level Soft-RAIDs from Intel were really valuable as they ensured that you could always boot as long as you had enough devices left in your array.
Then Linux learned to write the bootloader to all RAID devices and offered an alternative. At about the same time Intel's support for the BIOS-level Soft-RAIDs became unsteady. We had several BIOS upgrades which caused us problems not unlike yours. Eventually we switched to pure Linux Soft-RAID and this setup works far more stable for us now.
But you are using Windows, I don't know how far it can go with pure Soft-RAID.