Return to

The small linux problem thread



This is definitely on xorg.

I’m not encountering any CPU issues though. I wonder if it’s a bug in the OpenGL version.


For those that are on Debian or Ubuntu and are having no audio in headphones despite there being audio through your other devices:

sudo alsactl restore

Activities > Settings > Sound > Output

Line Out > Flip to ON

Turn up volume to hear the bubbling volume up noise.


Upgraded computer from an R7 360 to an RX 570 I seem to have trouble booting.


Looks like docker.spec in Fedora pulls from atomic based on docker 1.13

That’s 2 years old, according to the docker branching. They’ve changed the numbering since then but they are releasing new stuff lately. The 18.06 stable release is only a month old.

The main difference that I remember from last year was that Fedora required sudo for docker container execution, but docker-ce did not. I would guess there is a lot security work at RedHat that is not present in docker-ce.


I mine using the terminal in linux.

To do this I need to go to the directory “cd /downloads/mining”
and once in that folder run a command “./miningapp cryptomine full power”

I’m new to Linux and I was wondering if I could make a ‘short-cut’
So open terminal and type “CPUMine” and then the terminal would automatically navigate to the correct folder and then run the command


setup an alias or script that you can run


What kernel version are you running?

There were some issues reported for certain GPU after kernel 4.19 was released.

In my case (with an MSI R9 390) when I upgraded to kernel 4.19 my PC would no longer boot, between the GRUB menu and the Plymouth boot manager the screen would go black and the monitor would go into standby mode.

The solution for me was to remove the amdgpu.dpm=1 kernel parameter. Might be worth a try if you are experiencing similar issues.

**EDIT: If anyone else is having issues with this there’s an open tracking bug here with more information. Also note, the amdgpu.dpm kernel parameter needs to be completely removed rather than setting it to 0


Sorry for the late response but I finally found the free time to do this and it works now.


OMG this is plaguing CentOS too.

ml-kernel 4.19

Son of a bitch. I just want a fucking RHEL distro on my desktop.


How do you edit the kernel parameter?


I have some info here in reply to another post that might help.

EDIT: Haha, I just noticed that my reply in that thread was to your question too :grinning:


I explained how to do this in the thread you started before.


Does anyone else have an issue with glibc not updating in Fedora 28?

 Problem 1: cannot install both glibc-headers-2.27-35.fc28.x86_64 and glibc-headers-2.27-32.fc28.x86_64
  - glibc-headers-2.27-32.fc28.i686 has inferior architecture
  - cannot install the best update candidate for package glibc-headers-2.27-32.fc28.x86_64
  - problem with installed package glibc-headers-2.27-32.fc28.i686
 Problem 2: package glibc-headers-2.27-32.fc28.i686 requires glibc = 2.27-32.fc28, but none of the providers can be installed
  - cannot install both glibc-2.27-35.fc28.i686 and glibc-2.27-32.fc28.i686
  - cannot install both glibc-2.27-35.fc28.x86_64 and glibc-2.27-32.fc28.x86_64
  - cannot install the best update candidate for package glibc-headers-2.27-32.fc28.i686
  - cannot install the best update candidate for package glibc-2.27-32.fc28.i686
  - cannot install the best update candidate for package glibc-2.27-32.fc28.x86_64
 Package              Arch          Version                Repository      Size
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 glibc                i686          2.27-35.fc28           updates        3.4 M
 glibc                x86_64        2.27-35.fc28           updates        3.6 M
 glibc-headers        x86_64        2.27-35.fc28           updates        460 k

Transaction Summary
Skip  3 Packages

Nothing to do.

The problem seems to be that there is no glibc-headers-2.27-35.fc28.i686 package. I don’t think I installed any glibc packages manually, and I’m thinking it’s a really bad idea to mess with this…


I dont have that issue… but after a yum clean all and update a min ago… I now see this on fedora 28


I don’t have mlt-freeworld installed, but it comes from the rpmfusion repo and maybe they’re a bit slower pushing updates, as is the case with virtualbox from rpmfusion.

Do you have a glibc-headers i686 version installed? I wondered if it’s installed by default or if it got installed as a dependency for something else. Either way considering how central it is to linux, I’m inclined not to touch it.


I’m having some audio issues w/WINE in Fedora 29 that I didn’t in F28. IIRC I did make a backup (with dd) before I upgraded, but how hard would it be to just install F28 to my / partition then mount /home?


I see these on one desktop so far…

I’ll go check my other desktop



my gaming desktop has it…


Steam needs it.


So you don’t have glibc-headers.i686. I wonder why that package is stuck at version 2.27-32.fc28, preventing the upgrade to 2.27-35.fc28.

$ dnf list installed | grep glibc
glibc.i686                            2.27-32.fc28                @updates      
glibc.x86_64                          2.27-32.fc28                @updates      
glibc-all-langpacks.x86_64            2.27-32.fc28                @updates      
glibc-common.x86_64                   2.27-32.fc28                @updates      
glibc-devel.i686                      2.27-32.fc28                @updates      
glibc-devel.x86_64                    2.27-32.fc28                @updates      
glibc-headers.i686                    2.27-32.fc28                @updates      
glibc-headers.x86_64                  2.27-32.fc28                @updates      
glibc-langpack-en.x86_64              2.27-32.fc28                @updates      


This is a higher level approach, but…if you have an lvm root partition you can supposedly take a snapshot, force upgrade glibc, and if breaks roll back the partition. Or you could just backup the entire partition, upgrade glibc with the dnf options ‘–best’ and ‘–allowerasing’, and restore from backup if it blows up.

dnf also has the ability to rollback transactions if they break something. Of course you have to able to boot, or mount your root partition in a chroot. You also have to make sure that dnf is configured to keep its cache of old packages when recovering from dnf transaction rollbacks, because most mirrors don’t keep old revisions of packages.




You’d also have to make sure glibc-2.27-32 is in dnf’s cache to restore in the event of failure.