The small linux problem thread

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.

1 Like

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.
Complete!

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…
image

I’ll go check my other desktop

@sceps

my gaming desktop has it…

image

Steam needs it.

2 Likes

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.

/etc/dnf/dnf.conf

[main]

keepcache=1

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

Thanks but I’d like to avoid those risks. I really should learn to make lvm snapshots, but this isn’t the best time to practice this! My dnf.conf doesn’t have keepcache=1, plus it has what seems like the opposite: clean_requirements_on_remove=True

More importantly, what would forcing dnf accomplish if the update to that package doesn’t exist, and is it possible to check for its existence in the repo?

I’m new to dnf (though not rpm) so I may not have all the answers. The dnf cache is in:
/var/cache/dnf
You could do ‘sudo find /var/cache/dnf -iname “glibc*.rpm”’ to see if any glibc packages are cached. Unfortunately I don’t know how to search the repos for a specific revision, though my understanding is that the vast majority of repos only have the very latest revision of packages.

I’ve been using dnf for a little under a year now, and my personal experience has been that aptitude is generally better. Bet that’ll raise a few hackles…

sudo find /var/cache/dnf -iname “glibc*.rpm” returns nothing. /var/cache/dnf contains directories for each repo, and I checked in the one for “updates” and there are just a few packages and nothing for glibc.

In any case, I’ll just wait it out. This type of update problem happens regularly for packages from rpmfusion such as virtualbox and chromium (due to a package with “bad” codecs). Usually after about a week, the missing package appears and the update is successful. I’m just surprised it’s happened with a core package like glibc from the updates repo.

I restored from a month old backup using dd, and now have Fedora 28 installed. My audio issues are also gone.

Moral: Always backup your OS as well as your data.

2 Likes

I’m sorry I missed your reply. I’m using AMD Vega 64 and Samsung 1TB 970Evo on Asus Crosshair VII Wifi.
With new Ubuntu 18.10 install I again had troubles waking from USB.
step1 – sudo su

step2 - grep . /sys/bus/usb/devices/*/product
take note the usb buss number between device and product, mine shows
/sys/bus/usb/devices/3-2.1.1.2/product:G Pro Gaming Mouse
if you are not using a hub it may show just (usb1,usb2,usb3,usb4,usb5,usb6,usb7,usb8)
between the devices and product.

Step3 - lsusb which will show buss and product ID’s
take note of the 4 digits before and after the colon, mine shows
Bus 003 Device 006: ID 046d:c085 Logitech, Inc.

step4 - sudo nano /etc/udev/rules.d/10-wakeup.rules
add this line replacing the idVendor and idProduct from step 3 and the usb buss number between devices and power taken from step 2

ACTION==“add”, SUBSYSTEM==“usb”, ATTRS{idVendor}==“046d”, ATTRS{idProduct}==“c085” RUN+="/bin/sh -c ‘echo enabled > /sys/bus/usb/devices/3-2.1.1.2/power/wakeup’"

step5 – reboot and run grep . /sys/bus/usb/devices/*/power/wakeup to verify your device shows “enabled”

What kernel are you using?