Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Volguus
Mar 3, 2009

Less Fat Luke posted:

Yeah same under Debian primarily; I need to use it for CUDA stuff but I also play a lot of games with the binary drivers on Debian, no real issues other than the usual Linux bullshit occasionally. That being said I would buy anything else if I didn't need it for work since their GPUs are so goddamned expensive.

Yeah, not only expensive but also not plug and play under linux. AMD and Intel are certainly nice when you just don't have to worry about that.


xzzy posted:

We just evaluated a "gpu accelerated software raid card" that requires an nvidia gpu in the system to work. So now not only can driver problems break your display, it can break access to your data!

https://www.graidtech.com/product/sr-1010/

Ok, now that's a new one.

Adbot
ADBOT LOVES YOU

Mega Comrade
Apr 22, 2004

Listen buddy, we all got problems!
Intels GPUs are coming along really well. It's good to have some options at the low end now that Nvidia don't seem to care about it.
Hopeful AI will force AMD to finally make a CUDA alternative that's worth a drat for those that need that functionality.

Mega Comrade fucked around with this message at 14:42 on Feb 21, 2024

Less Fat Luke
May 23, 2003

Exciting Lemon
It would also be nice to have any modern gaming-capable GPU not cover like 3 freakin PCI slots.

Zorak of Michigan
Jun 10, 2006

xzzy posted:

We just evaluated a "gpu accelerated software raid card" that requires an nvidia gpu in the system to work. So now not only can driver problems break your display, it can break access to your data!

https://www.graidtech.com/product/sr-1010/

Wait... it's not integrated into the RAID controller? It actually has to work with a separate GPU? The web page reads like it's just a RAID card that uses a GPU for its brain, which isn't nearly as insane as making data go CPU -> RAID card -> GPU -> RAID card -> storage.

xzzy
Mar 5, 2009

Zorak of Michigan posted:

Wait... it's not integrated into the RAID controller? It actually has to work with a separate GPU? The web page reads like it's just a RAID card that uses a GPU for its brain, which isn't nearly as insane as making data go CPU -> RAID card -> GPU -> RAID card -> storage.

Oh, you're right. The GPU is on the card you buy. Sorry, when I said "we" I meant a co-worker and I'm just parroting their report and that introduced errors!

cruft
Oct 25, 2007

Zorak of Michigan posted:

CPU -> RAID card -> GPU -> RAID card -> storage.

I just had the best idea for a new startup...

Sir Bobert Fishbone
Jan 16, 2006

Beebort

Mega Comrade posted:

Intels GPUs are coming along really well. It's good to have some options at the low end now that Nvidia don't seem to care about it.
Hopeful AI will force AMD to finally make a CUDA alternative that's worth a drat for those that need that functionality.

Looks like AMD is/was funding some work to improve CUDA compatibility: https://www.phoronix.com/review/radeon-cuda-zluda

Saukkis
May 16, 2003

Unless I'm on the inside curve pointing straight at oncoming traffic the high beams stay on and I laugh at your puny protest flashes.
I am Most Important Man. Most Important Man in the World.

Sir Bobert Fishbone posted:

Looks like AMD is/was funding some work to improve CUDA compatibility: https://www.phoronix.com/review/radeon-cuda-zluda

repiv had a good point about that product in the GPU thread.

repiv posted:

focusing on ZLUDA would put AMD in an awkward position strategically because it's dependent on nvidias whole toolchain, and if it's "good enough" then nobody is going to bother targeting AMD natively, making them a second class platform forever

BlankSystemDaemon
Mar 13, 2009



xzzy posted:

We just evaluated a "gpu accelerated software raid card" that requires an nvidia gpu in the system to work. So now not only can driver problems break your display, it can break access to your data!

https://www.graidtech.com/product/sr-1010/
Jail. Jail to everyone involved in this.

Also, for what it's worth, one of the things that QuickAssist is supposed to be useful for is offloading finite Galois Fields for RAID6+ - which is why ZFS Inline Acceleration is being developed by LANL:
https://www.youtube.com/watch?v=mKDDKG0yVRg

BlankSystemDaemon fucked around with this message at 19:36 on Feb 21, 2024

NihilCredo
Jun 6, 2011

iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

Question: running Fedora, where is the boot image that is signed with Red Hat's Secure Boot signature? And what userspace tool can I use to read it and/or verify it?

Context: I'm running Rawhide and while my current base image is fine, if I upgrade I get a boot failure from Secure Boot and have to roll back. I'd like to report this, but I have no idea which package or component is responsible for that.

Volguus
Mar 3, 2009
Just spitballing here since I don't have secure boot enabled, but wouldn't that be the kernel?
pre:
rpm -qf /boot/vmlinuz-6.8.0-0.rc5.41.fc40.x86_64                                                                                                         
kernel-core-6.8.0-0.rc5.41.fc40.x86_64
edit: maybe not.

pre:
rpm -qf /boot/efi/EFI/fedora/shimx64.efi                                                                                                                   
shim-x64-15.6-2.x86_64

rpm -qi shim-x64-15.6-2.x86_64                                                                                                                             
Name        : shim-x64
Version     : 15.6
Release     : 2
Architecture: x86_64
Install Date: Wed 20 Jul 2022 01:32:49 PM
Group       : Unspecified
Size        : 3787812
License     : BSD
Signature   : RSA/SHA256, Mon 18 Jul 2022 01:22:40 PM, Key ID 999f7cbf38ab71f4
Source RPM  : shim-15.6-2.src.rpm
Build Date  : Thu 07 Jul 2022 03:36:06 PM
Build Host  : bkernel01.iad2.fedoraproject.org
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : https://github.com/rhboot/shim/
Bug URL     : https://bugz.fedoraproject.org/shim
Summary     : First-stage UEFI bootloader
Description :
Initial UEFI bootloader that handles chaining to a trusted full
bootloader under secure boot environments. This package contains the
version signed by the UEFI signing service.

Volguus fucked around with this message at 22:44 on Feb 21, 2024

NihilCredo
Jun 6, 2011

iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

Thanks! But now I'm confused because the shim-x64 package did not get upgraded when the issue appeared

Bash code:
$ rpm-ostree db list 9a1 | grep shim # image that boots fine
shim-ia32-15.6-2.x86_64
shim-x64-15.6-2.x86_64

$ rpm-ostree db list 518 | grep shim # image that fails with 'bad shim signature'
shim-ia32-15.6-2.x86_64
shim-x64-15.6-2.x86_64

other people
Jun 27, 2004
Associate Christ

NihilCredo posted:

Question: running Fedora, where is the boot image that is signed with Red Hat's Secure Boot signature? And what userspace tool can I use to read it and/or verify it?

Context: I'm running Rawhide and while my current base image is fine, if I upgrade I get a boot failure from Secure Boot and have to roll back. I'd like to report this, but I have no idea which package or component is responsible for that.

Is your uefi firmware DBX up to date?

pseudorandom name
May 6, 2007

Fedora doesn't use Red Hat's Secure Boot signature, shim is Microsoft signed and exists to provide an easier way for users to boot signed kernels without having to deal with their UEFI firmware's cert database.

Any UEFI firmware that is configured to require Secure Boot will boot shim, but shim introduces the concept of Machine Owner Keys (MOKs), which is yet another database of trusted signing keys (or just SHA256 hashes of allowed UEFI executables), and there's a whole protocol for an OS to request the addition of a MOK and then you reboot into shim and it asks you if you want to add this MOK and then you say yes and from that point on shim will run any UEFI executable signed by that MOK.

If you don't have Secure Boot enabled when you install Fedora, it will configure all of this for you without any prompting because it's not secure anyways, and then if you enable Secure Boot afterwards it'll just invisibly work.

(grub is also involved in this somehow but I don't remember the details and am too lazy to look)

other people
Jun 27, 2004
Associate Christ
If your firmware is up to date then you should report this as a kernel issue in bugzilla. The rawhide kernel is built from kernel-ark in gitlab and I see an MR from last week which made a change to the signing keys. Maybe that aligns with your problem.

NihilCredo
Jun 6, 2011

iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

other people posted:

Is your uefi firmware DBX up to date?

other people posted:

If your firmware is up to date then you should report this as a kernel issue in bugzilla. The rawhide kernel is built from kernel-ark in gitlab and I see an MR from last week which made a change to the signing keys. Maybe that aligns with your problem.

Interesting. For a LONG time (like since Fedora 36) I've had this entry in Discover which failed to install:





It never caused any problem, and I think I found some issue that reported it, so I pretty much ignored it.

What is the command line program that performs that update? I regularly run `rpm-ostree upgrade` and `flatpak upgrade`, neither of which apparently updated it.

other people
Jun 27, 2004
Associate Christ
It is called fwupdmgr. I cannot find a fedora official doc on using it but these rhel9 steps should be the same:

https://access.redhat.com/documenta...revocation-list

NihilCredo
Jun 6, 2011

iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

Ok, I think I figured out the root of the issue. Apparently fedora 40 adds a new package, 'bootupd', which is supposed to fix that particular firmware upgrade error (among other things), and that package is indeed among those added when I upgrade.

So that's presumably the culprit for the secure boot violation. Now I know where to report the bug, at least. Thanks guys.

Bark! A Vagrant
Jan 3, 2007

Grad school is good for mental health

Framboise posted:

Reaching my wit's end with this suspend issue. I get that it's most likely because of my GPU but I've tried everything to the extent of my understanding at the moment. I even started a fresh install of EndeavourOS with KDE instead of GNOME to see if it made a difference. It doesn't, but I do like it more as a DE I guess so there's that.


I know this is a deeply unsatisfying answer, but how much do you really need suspend? Isn't that a desktop card? Disabling suspend and just using a lock screen or shutting down seems like an easier solution at the current moment.

If you want to keep soldiering on, someone reported that the newest beta driver (550.40.07) fixed the issue for them on a GTX 970.

Framboise
Sep 21, 2014

To make yourself feel better, you make it so you'll never give in to your forevers and live for always.


Lipstick Apathy

Klyith posted:

Also just how much Arch is a "learn the hard way" distro.

Endeavour should have fallback options in grub to give you text only boot.

Also it's possible that hitting ctrl-alt-F# on that screen will get a usable terminal, because that mess is from the display server failing to start up?

Ctrl+alt+F#s didn't do anything. I did manage to get in by using nomodeset, but if we're at the point where I've been googling for answers for over a week now and trying stuff suggested here and still not making headway, it may just be the distro and I just might not be able to use EndeavourOS/Arch etc for now and I may just need to explore other options until I can upgrade my PC. I got in, salvaged the files I had collected since starting to use it (just some nice wallpapers really), and nuked it all so I can try something else.

I don't really feel like Arch has been any easier or harder to use than any other distro I've tried out (on virtual machine at least)-- it's really just this suspend/hibernate issue that's been such a bummer to deal with. I actively wanted to "learn the hard way" because that's how I learn best, and I like that it's got rolling updates and the AUR, so that's why I had leaned toward it.

I tried installing plain Arch instead of Endeavour tonight and I couldn't even get into the installer (which doesn't even have a graphical interface) without it freezing up the same way that EOS was doing. It really may just be Arch not wanting to play along, so it's time to see if it's just Linux in general that doesn't want to play along with my GPU.


Bark! A Vagrant posted:

I know this is a deeply unsatisfying answer, but how much do you really need suspend? Isn't that a desktop card? Disabling suspend and just using a lock screen or shutting down seems like an easier solution at the current moment.

If you want to keep soldiering on, someone reported that the newest beta driver (550.40.07) fixed the issue for them on a GTX 970.

It's just my general way of doing things that I've done for years. Ever since I had a burn-in issue with Windows that I had managed to fix, I've been cautious to make sure my screen isn't on/won't come back on while I'm not around, so whenever I leave my computer for any extended period of time I'm just used to putting it to sleep. I could just turn the screen off, but I just figured putting the whole thing in a low power state would be better, I dunno.

I'm gonna give Fedora and Kubuntu a try, and if I don't have any better results with those I'll just go back to EOS and lockscreen + turn screen off instead of putting the PC to sleep.

Framboise
Sep 21, 2014

To make yourself feel better, you make it so you'll never give in to your forevers and live for always.


Lipstick Apathy
...okay.

I can suspend without a loving problem on Kubuntu. It's not my GPU at all, it's whatever was going on with EOS that didn't want to play along.

It boots up slower than EOS does, apt feels slower and it seems like I'll need to use whatever snaps are to get certain apps working, but it works for now. I'll take it.

VictualSquid
Feb 29, 2012

Gently enveloping the target with indiscriminate love.
I am trying to figure out transactional systems, microos specifically. Got it running on my spare rpi right now.
How do I install an alternative shell like fish or a terminal manager like zellij? Running them in a distrobox feels wrong, and the manual says installing through transactional-upgrade should be avoided whenever possible.

Nitrousoxide
May 30, 2011

do not buy a oneplus phone



I use an OSTree based system and I just overlay terminals if I need to use a different one. It interacts so deeply with the base system it really does not work well if you're trying to do it in a container.

VictualSquid
Feb 29, 2012

Gently enveloping the target with indiscriminate love.

Nitrousoxide posted:

I use an OSTree based system and I just overlay terminals if I need to use a different one. It interacts so deeply with the base system it really does not work well if you're trying to do it in a container.

99% of my terminal manager usage is because I never learned to use nohup correctly.


Also, which sevice provides the testsystem.local adresses? It always came preinstalled with the bigger distros.

Less Fat Luke
May 23, 2003

Exciting Lemon
Avahi is the usual mDNS provider - fun fact I spent like an hour trying to figure out why websockets won't work connecting to .local addresses yesterday with Wireshark (with multiple apps!) and ended up giving the targets actual hostnames to get it to work. First time in years I've had issues with .local.

Subjunctive
Sep 12, 2006

✨sparkle and shine✨

systemd-resolver or whatever can also do mDNS stuff pretty well, I think, but there are more guides out there for Avahi

Less Fat Luke
May 23, 2003

Exciting Lemon

Framboise posted:

...okay.

I can suspend without a loving problem on Kubuntu. It's not my GPU at all, it's whatever was going on with EOS that didn't want to play along.

It boots up slower than EOS does, apt feels slower and it seems like I'll need to use whatever snaps are to get certain apps working, but it works for now. I'll take it.
Awesome to hear that your GPU isn't hosed!

NihilCredo
Jun 6, 2011

iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

Nitrousoxide posted:

I use an OSTree based system and I just overlay terminals if I need to use a different one. It interacts so deeply with the base system it really does not work well if you're trying to do it in a container.

For a different opinion, I use an OSTree system and all my CLI toys are in a Debian distrobox (alongside my development tools and VSCode), and Konsole is set to open that distrobox by default.

If I do need to run something that's tied to the actual system (usually rpm-ostree or systemctl), I have aliased distrobox-host-exec to just 'dhe'.

Framboise
Sep 21, 2014

To make yourself feel better, you make it so you'll never give in to your forevers and live for always.


Lipstick Apathy

Less Fat Luke posted:

Awesome to hear that your GPU isn't hosed!

When you said it "works out of the box" you weren't kidding.

I'll still go back to an arch distro eventually when I can figure out what the configuration difference is between that and this so things work as they should (likely after I upgrade my PC; it may not even be a problem then), but this hasn't been giving me any static beyond the package manager/repository being a bit more finicky than pacman.

Klyith
Aug 3, 2007

GBS Pledge Week

Framboise posted:

...okay.

I can suspend without a loving problem on Kubuntu. It's not my GPU at all, it's whatever was going on with EOS that didn't want to play along.

lmao

(not at you, at this whole... linux)


Re: learning the hard way, I totally get that. But this is kinda what learning the hard way looks like.

Uh, speaking of which I think this is your issue -- seems like a lot of 970 owners in particular are having sleep/resume issues with recent kernels. Many of those reports seem similar or identical to yours. Ubuntu is still on 6.5 which is why your new install works out of the box.


Framboise posted:

It boots up slower than EOS does, apt feels slower and it seems like I'll need to use whatever snaps are to get certain apps working, but it works for now. I'll take it.

Snaps are sandboxed applications, very similar to flatpak, but Ubuntu's own thing. Sandboxed apps are what a lot of the big-deal linux desktops are moving towards now, because it simplifies dependencies and has security benefits. Con: stuff is slower to start up than a bare-metal app, and you have to manage permissions even for some basic things like storage access.

Arch is starting to be the odd one out for still doing everything bare-metal by default.

You can probably avoid snaps and install apps directly, but it may require adding extra repositories to apt.

ExcessBLarg!
Aug 31, 2001
Snaps are pretty aggressive about automatic/forced updates, but since they're sandboxed you know the updates won't break anything else.

Last I checked the only things Ubuntu had moved to snaps packing exclusively was Firefox ("at Mozilla's request") and LXD. The latter seems like an odd choice, but I totally get distros wanting to be aggressive about pushing updates to your web browser given the nature of the attack surface there.

Eletriarnation
Apr 6, 2005

People don't appreciate the substance of things...
objects in space.


Oven Wrangler
Yeah, my experience has been that Ubuntu and Fedora are both pretty good at supporting most recent hardware configurations out of the box. They might be making compromises to get reliability over performance, but I haven't been playing games on them so I probably wouldn't notice.

This past weekend I decided to waste some time by seeing if drat Small Linux 2024 would work on a 2003-era 875P board + Pentium 2.6C + 2GB DDR-400 that I found in an e-recycling bin a few years ago but never tested. The board is fortunately just new enough to have SATA, so installation on an SSD was quick and easy. Unfortunately DSL didn't have drivers already for my first choice of GPU, a Radeon 4650 which was among the last models ever released for AGP. The only three modes available were 640x400, 640x480, and 720x480 which all looked slightly painful on a 1080p screen. My second choice, a Radeon 9600 which actually came with the board, worked fine and after using it to install the Debian repo's Radeon drivers the 4650 worked as well. Firefox ESR was not bad for browsing the web with a few tabs at a time.

I then installed current Debian x86 with LXDE just for a quick comparison, and was not surprised to find that everything worked out of the box. Unfortunately any Windows 10 flash drives I create won't boot and I'm not motivated enough by curiosity to take an optical drive out of any other systems, so the gaming capabilities of this system in 2024 will have to go unexplored for now. Still, I was pleased to see that Linux can still make the equivalent of my desktop from 2003 into a workable if slow web browser. I assume it would choke if it had to play any video, though.

Eletriarnation fucked around with this message at 16:35 on Feb 22, 2024

Framboise
Sep 21, 2014

To make yourself feel better, you make it so you'll never give in to your forevers and live for always.


Lipstick Apathy

Klyith posted:

lmao

(not at you, at this whole... linux)


Re: learning the hard way, I totally get that. But this is kinda what learning the hard way looks like.

Uh, speaking of which I think this is your issue -- seems like a lot of 970 owners in particular are having sleep/resume issues with recent kernels. Many of those reports seem similar or identical to yours. Ubuntu is still on 6.5 which is why your new install works out of the box.

Amazing. (I use a 980 Ti, don't know if that is treated the same or not.) I'm just glad to know that I'm not the only one with this specific issue and it's just as baffling to others as it is to me. I like to think I'm generally good with computers, then something like this happens and I become completely clueless.

Good to know that it's ultimately just something mostly out of my control and not something I was particularly doing wrong.

Klyith posted:

Snaps are sandboxed applications, very similar to flatpak, but Ubuntu's own thing. Sandboxed apps are what a lot of the big-deal linux desktops are moving towards now, because it simplifies dependencies and has security benefits. Con: stuff is slower to start up than a bare-metal app, and you have to manage permissions even for some basic things like storage access.

Arch is starting to be the odd one out for still doing everything bare-metal by default.

You can probably avoid snaps and install apps directly, but it may require adding extra repositories to apt.

Ah, I see. I kind of liked not needing to deal with those, but it is what it is for now. So long as everything works we're good.


Eletriarnation posted:

Yeah, my experience has been that Ubuntu and Fedora are both pretty good at supporting most recent hardware configurations out of the box. They might be making compromises to get reliability over performance, but I haven't been playing games on them so I probably wouldn't notice.

I had tried installing Fedora first but for some reason I couldn't even get the installer/live environment to work at all. I tried fedora's media manager, rufus, etc and no matter what I did, it just wouldn't start up at all. Moved on to kubuntu and that did the trick.

Nitrousoxide
May 30, 2011

do not buy a oneplus phone



NihilCredo posted:

For a different opinion, I use an OSTree system and all my CLI toys are in a Debian distrobox (alongside my development tools and VSCode), and Konsole is set to open that distrobox by default.

If I do need to run something that's tied to the actual system (usually rpm-ostree or systemctl), I have aliased distrobox-host-exec to just 'dhe'.

There is a "podman shell" implementation which is supposed to containerize the terminal in a way that still integrates well with the host. I've not tried it though.

https://docs.podman.io/en/v4.6.1/markdown/podmansh.1.html

mawarannahr
May 21, 2019

Nitrousoxide posted:

There is a "podman shell" implementation which is supposed to containerize the terminal in a way that still integrates well with the host. I've not tried it though.

https://docs.podman.io/en/v4.6.1/markdown/podmansh.1.html

Looks like it's

quote:

NOTE: This feature is currently a Tech Preview. Changes can be expected in upcoming versions.
I'm fairly sure you can accomplish this more easily with Apptainer but you would need to adapt the unit files.

Adbot
ADBOT LOVES YOU

NihilCredo
Jun 6, 2011

iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

Nitrousoxide posted:

There is a "podman shell" implementation which is supposed to containerize the terminal in a way that still integrates well with the host. I've not tried it though.

https://docs.podman.io/en/v4.6.1/markdown/podmansh.1.html

As I understand, the purpose of this tool is to limit other users to only have access to a shell inside a podman, and not a regular shell. So they can have their own little sandbox where they can 'sudo apt install' whatever they want but they cannot touch anything that isnīt mounted into the pod. (I imagine this isn't more secure than regular Linux ACLs, but it is considerably more flexible and transparent)

If it's for yourself, all you need to do is add 'distrobox enter <name>' to your .bash_rc.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply