|
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! Ok, now that's a new one.
|
#
?
Feb 21, 2024 15:37
|
|
|
|
| # ? May 31, 2024 05:02 |
|
|
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 15:42 on Feb 21, 2024 |
|
#
?
Feb 21, 2024 15:39
|
|
|
It would also be nice to have any modern gaming-capable GPU not cover like 3 freakin PCI slots.
|
|
#
?
Feb 21, 2024 16:15
|
|
|
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! 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.
|
|
#
?
Feb 21, 2024 16:19
|
|
|
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!
|
|
#
?
Feb 21, 2024 16:24
|
|
|
Zorak of Michigan posted:CPU -> RAID card -> GPU -> RAID card -> storage. I just had the best idea for a new startup...
|
|
#
?
Feb 21, 2024 16:26
|
|
|
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. Looks like AMD is/was funding some work to improve CUDA compatibility: https://www.phoronix.com/review/radeon-cuda-zluda
|
|
#
?
Feb 21, 2024 16:34
|
|
|
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
|
|
#
?
Feb 21, 2024 16:55
|
|
|
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! 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 20:36 on Feb 21, 2024 |
|
#
?
Feb 21, 2024 20:34
|
|
|
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.
|
|
#
?
Feb 21, 2024 23:24
|
|
|
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 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 23:44 on Feb 21, 2024 |
|
#
?
Feb 21, 2024 23:42
|
|
|
Thanks! But now I'm confused because the shim-x64 package did not get upgraded when the issue appearedBash code:
|
|
#
?
Feb 21, 2024 23:52
|
|
|
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? Is your uefi firmware DBX up to date?
|
|
#
?
Feb 22, 2024 00:28
|
|
Associate Christ
|
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)
|
|
#
?
Feb 22, 2024 00:29
|
|
|
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.
|
|
#
?
Feb 22, 2024 00:33
|
|
|
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.
|
|
#
?
Feb 22, 2024 01:08
|
|
|
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
|
|
#
?
Feb 22, 2024 01:29
|
|
|
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.
|
|
#
?
Feb 22, 2024 02:04
|
|
|
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.
|
|
#
?
Feb 22, 2024 06:29
|
|
|
Klyith posted:Also just how much Arch is a "learn the hard way" distro. 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. 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.
|
|
#
?
Feb 22, 2024 07:57
|
|
|
...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.
|
|
#
?
Feb 22, 2024 09:56
|
|
|
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.
|
|
#
?
Feb 22, 2024 14:13
|
|
|
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.
|
|
#
?
Feb 22, 2024 14:17
|
|
|
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.
|
|
#
?
Feb 22, 2024 14:19
|
|
|
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.
|
|
#
?
Feb 22, 2024 14:50
|
|
|
systemd-resolver or whatever can also do mDNS stuff pretty well, I think, but there are more guides out there for Avahi
|
|
#
?
Feb 22, 2024 14:52
|
|
|
Framboise posted:...okay.
|
|
#
?
Feb 22, 2024 15:29
|
|
|
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'.
|
|
#
?
Feb 22, 2024 15:32
|
|
|
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.
|
|
#
?
Feb 22, 2024 16:42
|
|
|
Framboise posted:...okay. 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.
|
|
#
?
Feb 22, 2024 16:45
|
|
|
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.
|
|
#
?
Feb 22, 2024 16:58
|
|
|
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 17:35 on Feb 22, 2024 |
|
#
?
Feb 22, 2024 17:32
|
|
|
Klyith posted:lmao 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. 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.
|
|
#
?
Feb 22, 2024 17:47
|
|
|
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. 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
|
|
#
?
Feb 22, 2024 18:51
|
|
|
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. Looks like it's quote:NOTE: This feature is currently a Tech Preview. Changes can be expected in upcoming versions.
|
|
#
?
Feb 22, 2024 18:55
|
|
|
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. 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.
|
|
#
?
Feb 22, 2024 19:07
|
|
|
I'm having an issue where certain applications aren't launching in Ubuntu. Some stuff does, like firefox or Gimp or preinstalled stuff like groovebox, but chromium and Krita and other installed stuff just won't open up. My memory is almost full and I thought it might be a part of it, but deleting stuff hasn't seemed to help. Once in a while I'll restart and these things will work, but I can't tell if there's any rhyme or reason to it.
|
|
#
?
Feb 24, 2024 18:17
|
|
|
FunkyAl posted:I'm having an issue where certain applications aren't launching in Ubuntu. Some stuff does, like firefox or Gimp or preinstalled stuff like groovebox, but chromium and Krita and other installed stuff just won't open up. My memory is almost full and I thought it might be a part of it, but deleting stuff hasn't seemed to help. Once in a while I'll restart and these things will work, but I can't tell if there's any rhyme or reason to it. Try launching them from a console session and see what it says when it fails. Typically there will be a lot of warnings and errors even on a successful launch (because all software is terrible), but there will possibly be some usable info when it fails.
|
|
#
?
Feb 24, 2024 18:22
|
|
|
AlexDeGruven posted:Try launching them from a console session and see what it says when it fails. Typically there will be a lot of warnings and errors even on a successful launch (because all software is terrible), but there will possibly be some usable info when it fails. It is telling me: timeout waiting for snap system profiles to get updated.
|
|
#
?
Feb 24, 2024 22:17
|
|
|
|
| # ? May 31, 2024 05:02 |
|
|
Ugh. Sounds like something isn't going right with snap. That's out of my depth.
|
|
#
?
Feb 24, 2024 23:16
|
|