Re: [gentoo-user] Why is KDE so bad at multiple monitors?
Michael wrote: > On Sunday, 3 March 2024 19:31:30 GMT Dale wrote: >> >> Since my last post, I did my weekly updates. During that, I log out, >> switch to boot runlevel, restart anything that checkrestart says needs >> it, then back to default runlevel and log back in. With the config file >> change, my monitors came up just like they should. I didn't have to >> adjust anything. >> >> I guess it goes to show, one thing fixes one person's system while yet >> another fixes someone else's system. Go figure. ROFL >> >> Dale >> >> :-) :-) > You don't need to replace openrc with systemd to use Wayland. These days I > run all my systems' desktops on Wayland and openrc. OpenRC will not > interfere > with or try to replace my network settings, my cron jobs, my chronyd, syslog, > or whatever. > > Pipewire is the new sound server for KDE. Take a look here in case yours > needs some tweaking: > > https://wiki.gentoo.org/wiki/PipeWire > > I run on my main desktop with USE="-pulseaudio", but if you have any > applications which need pulseaudio you'll need to enable it, if you haven't > done this already. When pipewire first showed up, I was kinda hesitant about it. Here's something new that is going to annoy me for a while until the bugs gets worked out and I figure out how to use it. Then I got Kmix cut off. I started using pipewire and it was like, cool. It actually works pretty well. The other day it did some strange things tho. I would set the volume but every time it went to the next video in my play list, it would reset the volume to 0 or very close to it. It was annoying since I kept having to turn it back up. I ended up closing everything that would play sound and setting the volume levels where I wanted it. I then restarted smplayer and such. It has worked ever since. I guess it got confused between some setting somewhere and what I wanted. Doing it with all the apps gone seems to have fixed it. So far, that's the only time it gave me any trouble and it could have been something I clicked by accident or something. I don't know that it was pipewire's fault. Could be, could have been me. Since I use smplayer to watch TV, doing that reset while everything was closed, it also fixed the volume setting on mpv when I'm playing some temporary video to test and make sure a file is good, and in English. It actually fixed two problems. Oh, I also figured out how to set the audio in smplayer as well. I used to have it set to a user setting in preferences to get sound. Now it's using a regular device like it should. Overall, I kinda like pipewire. It does manage the sound better than Kmix did. It not only manages devices but also manages apps as well. Anyone who hasn't switched should give it a try. Just look for both tabs. One is for devices and one is for apps. Have to check them both and adjust as needed. Dale :-) :-)
Re: [gentoo-user] Why is KDE so bad at multiple monitors?
Daniel Frey wrote: > On 3/3/24 13:57, Dale wrote: >> I think most is in the .config directory now. I have to say tho, I used >> to zap that thing about once a year, sometimes two, to correct some >> things that were weird but couldn't fix otherwise. I think the devs try >> to make things forward compatible but no one is perfect. Sometimes, you >> just have to start fresh. I do hate resetting everything tho. It takes >> a while to get everything back to at least close to the old way. >> >> Dale >> >> :-) :-) >> > > So many programs store config in there now it's hard to just zap it so > I generally won't try that. It's not just setting up kde again, it's > dozens of other programs too. :o( > > Dan > > True. Inside .config is kdedefaults. That would likely be a good start. The directories inside there are mostly KDE. Here's my list. root@fireball / # /bin/ls /home/dale/.config/kdedefaults/ kcminputrc kdeglobals kscreenlockerrc ksplashrc kwinrc package plasmarc root@fireball / # There's also some files in .config that start with a 'k' that may need to be renamed or deleted if you are brave. It's not as easy as it used to be tho. I wonder, can the old .kde4 directory be removed now??? I suspect everything is KDE5 now, with KDE6 right around the corner I think. Dale :-) :-)
Re: [gentoo-user] Emerge trouble with firefox and thunderbird ...
On 03/03/24 at 04:18, Jack wrote: On 2024.03.03 15:23, Wol wrote: On 03/03/2024 19:40, Jack wrote: On 2024.03.03 13:54, Wols Lists wrote: On 03/03/2024 09:47, Wols Lists wrote: I'm getting this output from emerge --update --newuse --deep --with-bdeps=y @world whoops I mean "emerge --depclean" I'm trying to get a clean system, and don't know what exactly is wrong, or what to try ... Cheers, Wol As the error says, you generally need to do a full update before you can depclean. What error(s) do you get when trying to update firefox or thunderbird? What happens if you try to update @world? Both firefox and thunderbird seemed to die for no obvious reason. Where do I find the logs? But because depclean complained, I did blah-blah-with-bdeps, which emerged (or tried to) 21 packages, but firefox/thunderbird still bombed, and then --depclean still complained. So I don't know what's going on, but basically Mozilla won't emerge, and I don't know why ... Cheers, Wol Did the other 19 package emerge OK? Are the mozilla progs crashing when running, or when emerging? If emerging, the log is just console output, as indecipherable as we know it sometimes can be. If they crash when running, try running from command line. Some time ago on one of my machines Thunderbird and Firefox stopped to compile with USE="clang". As they can be build with gcc I never digged too deep into that problem but maybe it's worth a shot. Greetings, Carsten
Re: [gentoo-user] AMD microkernel update failing (trying to patch zenbleed)
On 3/3/24 13:48, Michael wrote: It could be AMD have not yet released microcode updates for the community. OEMs receive new microcode first and patch it in their MoBo BIOS/UEFI firmware. Eventually the CPU manufacturers release microcode for older CPUs no longer supported by OEMs. Since you have embedded 'amd-ucode/ microcode_amd_fam17h.bin' in your kernel I don't think there's anything else you can do at this point in time, beyond emerging the latest sys-kernel/linux- firmware and rebooting. PS. I always place the microcode string first in the CONFIG_EXTRA_FIRMWARE= entries, since it should be the fist thing to load by the CPU. I don't know if it would makes any difference, since the whole string of firmwares will be parsed in one go. That's a good point about the microcode - I'll change that now (it's easy enough to do. And after an hour messing about and reading documentation and various articles, I have found out AMD does not release microcode for my CPU. I ran the spectre-meltdown-checker script (I've removed non-Zenbleed info): * Hardware support (CPU microcode) for mitigation techniques * CPU microcode is known to fix Zenbleed: NO (required version: 0x08701032) * CPU microcode is known to cause stability problems: NO (family 0x17 model 0x71 stepping 0x0 ucode 0x8701030 cpuid 0x870f10) * CPU microcode is the latest known available version: YES (latest version is 0x8701030 dated 2022/03/28 according to builtin firmwares DB v271+i20230614) * CPU vulnerability to the speculative execution attack variants * Affected by CVE-2023-20593 (Zenbleed, cross-process information leak): YES CVE-2023-20593 aka 'Zenbleed, cross-process information leak' * Zenbleed mitigation is supported by kernel: YES (found zenbleed message in kernel image) * Zenbleed kernel mitigation enabled and active: YES (FP_BACKUP_FIX bit set in DE_CFG) * Zenbleed mitigation is supported by CPU microcode: NO > STATUS: NOT VULNERABLE (Your kernel mitigates Zenbleed) So my processor is indeed family 17h - the model is 71h. It indicates the most recent microcode is being run (probably because I've updated the motherboard firmware.) I did find a tool to inspect the microcode blobs so I could see what's included: # ./amd_ucode_info.py /usr/lib/firmware/amd-ucode/microcode_amd_fam17h.bin Microcode patches in /usr/lib/firmware/amd-ucode/microcode_amd_fam17h.bin: Family=0x17 Model=0x08 Stepping=0x02: Patch=0x0800820d Length=3200 bytes Family=0x17 Model=0x31 Stepping=0x00: Patch=0x0830107b Length=3200 bytes Family=0x17 Model=0xa0 Stepping=0x00: Patch=0x08a8 Length=3200 bytes Family=0x17 Model=0x01 Stepping=0x02: Patch=0x0800126e Length=3200 bytes This just confirmed there's no microcode update for my processor model (71h.) I did download a different distribution's firmware package (mostly out of curiosity) and the results are identical. So AMD just doesn't have microcode for my model of CPU. As the spectre-meltdown-checker script says the kernel is mitigating Zenbleed for now, I'm just going forget about this and move on. Dan
Re: [gentoo-user] Why is KDE so bad at multiple monitors?
On 3/3/24 13:57, Dale wrote: I think most is in the .config directory now. I have to say tho, I used to zap that thing about once a year, sometimes two, to correct some things that were weird but couldn't fix otherwise. I think the devs try to make things forward compatible but no one is perfect. Sometimes, you just have to start fresh. I do hate resetting everything tho. It takes a while to get everything back to at least close to the old way. Dale :-) :-) So many programs store config in there now it's hard to just zap it so I generally won't try that. It's not just setting up kde again, it's dozens of other programs too. :o( Dan
Re: [gentoo-user] Why is KDE so bad at multiple monitors?
Daniel Frey wrote: > On 3/3/24 11:31, Dale wrote: >> Since my last post, I did my weekly updates. During that, I log out, >> switch to boot runlevel, restart anything that checkrestart says needs >> it, then back to default runlevel and log back in. With the config file >> change, my monitors came up just like they should. I didn't have to >> adjust anything. >> >> I guess it goes to show, one thing fixes one person's system while yet >> another fixes someone else's system. Go figure. ROFL >> >> Dale >> >> :-) :-) >> > > I strongly suspect that it was a kde setting somewhere in ~. The > problem is that config is littered all over the place now instead of > one place (I recall zapping the .kde[4] directory from the user home > folder in the past, can't do that now...) > > Although, that doesn't explain the problem I have with X11 and > displays. Had those same issues on the fresh install. > > Dan > > I think most is in the .config directory now. I have to say tho, I used to zap that thing about once a year, sometimes two, to correct some things that were weird but couldn't fix otherwise. I think the devs try to make things forward compatible but no one is perfect. Sometimes, you just have to start fresh. I do hate resetting everything tho. It takes a while to get everything back to at least close to the old way. Dale :-) :-)
Re: [gentoo-user] AMD microkernel update failing (trying to patch zenbleed)
On Sunday, 3 March 2024 19:14:23 GMT Daniel Frey wrote: > Hi all, > > I've always had problems updating the microcode for my AMD processor. I > have various other Intel-based PCs and this has never been an issue. > > I have confirmed it's not updating: > > > ~ # dmesg | grep -i microcode > [0.201619] Zenbleed: please update your microcode for the most > optimal fix > [0.748482] microcode: CPU1: patch_level=0x08701030 > [0.748482] microcode: CPU0: patch_level=0x08701030 > [0.748484] microcode: CPU3: patch_level=0x08701030 > [0.748485] microcode: CPU5: patch_level=0x08701030 > [0.748485] microcode: CPU4: patch_level=0x08701030 > [0.748486] microcode: CPU6: patch_level=0x08701030 > [0.748486] microcode: CPU7: patch_level=0x08701030 > [0.748487] microcode: CPU8: patch_level=0x08701030 > [0.748488] microcode: CPU9: patch_level=0x08701030 > [0.748488] microcode: CPU10: patch_level=0x08701030 > [0.748488] microcode: CPU11: patch_level=0x08701030 > [0.748491] microcode: CPU12: patch_level=0x08701030 > [0.748491] microcode: CPU13: patch_level=0x08701030 > [0.748492] microcode: CPU14: patch_level=0x08701030 > [0.748493] microcode: CPU15: patch_level=0x08701030 > [0.748496] microcode: CPU17: patch_level=0x08701030 > [0.748496] microcode: CPU18: patch_level=0x08701030 > [0.748498] microcode: CPU19: patch_level=0x08701030 > [0.748498] microcode: CPU20: patch_level=0x08701030 > [0.748500] microcode: CPU21: patch_level=0x08701030 > [0.748500] microcode: CPU22: patch_level=0x08701030 > [0.748501] microcode: CPU24: patch_level=0x08701030 > [0.748501] microcode: CPU23: patch_level=0x08701030 > [0.748503] microcode: CPU16: patch_level=0x08701030 > [0.748503] microcode: CPU26: patch_level=0x08701030 > [0.748503] microcode: CPU27: patch_level=0x08701030 > [0.748505] microcode: CPU28: patch_level=0x08701030 > [0.748506] microcode: CPU29: patch_level=0x08701030 > [0.748507] microcode: CPU30: patch_level=0x08701030 > [0.748508] microcode: CPU25: patch_level=0x08701030 > [0.748509] microcode: CPU31: patch_level=0x08701030 > [0.748511] microcode: CPU2: patch_level=0x08701030 > [0.748554] microcode: Microcode Update Driver: v2.2. > > I'm pretty sure I wouldn't be getting a zenbleed warning if it was using > the most recent microcode. > > My processor is this one: > > vendor_id : AuthenticAMD > cpu family : 23 > model : 113 > model name : AMD Ryzen 9 3950X 16-Core Processor > > This leads me to the 17h family. > > I do not use an initramfs as my system doesn't require one. I am not > willing to try an initramfs as my system fully functions without one and > this is not an issue with the Intel machines I have. > > I have properly configured the kernel (gentoo-sources-6.6.13): > > CONFIG_CPU_SUP_AMD=y > CONFIG_EXTRA_FIRMWARE="brcm/BCM20702B0-19ff-0239.hcd > amd-ucode/microcode_amd_fam17h.bin" > CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" > > The firmware loading is working as it does load the firmware for my > bluetooth adapter with no issues. > > (In the newer kernels microcode loading is enabled by default - no way > to turn it off. All you have to do is select CPU_SUP_AMD apparently. It > works on Intel machines.) > > I've even updated the motherboard BIOS firmware, and while that fixed > all the other issues it apparently does not have patches for zenbleed. > > Does anyone have any idea why this will not update? > > -Dan It could be AMD have not yet released microcode updates for the community. OEMs receive new microcode first and patch it in their MoBo BIOS/UEFI firmware. Eventually the CPU manufacturers release microcode for older CPUs no longer supported by OEMs. Since you have embedded 'amd-ucode/ microcode_amd_fam17h.bin' in your kernel I don't think there's anything else you can do at this point in time, beyond emerging the latest sys-kernel/linux- firmware and rebooting. PS. I always place the microcode string first in the CONFIG_EXTRA_FIRMWARE= entries, since it should be the fist thing to load by the CPU. I don't know if it would makes any difference, since the whole string of firmwares will be parsed in one go. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Why is KDE so bad at multiple monitors?
On Sunday, 3 March 2024 19:31:30 GMT Dale wrote: > Daniel Frey wrote: > > On 2/29/24 03:27, Dale wrote: > >> To provide a little more info on how this works. This is how I did > >> it. It helps a LOT to have tab completion with this. It will fill > >> in a lot of the info and when unsure, list the available options. > >> First, I had to install the package xrandr. My first problem is the > >> command isn't available since it wasn't installed. So, if you don't > >> have it, install it. It's tiny. This is what I have for my setup. > >> You can ignore that I watch TV and just pretend you have two monitors > >> side by side or whatever and get the same results. I have a DB15HD > >> connector, referred to as VGA within xrandr. That is my main > >> monitor. The second monitor is is connected to a HDMI port, seen as > >> same in xrandr, and what I watch TV with. This is the output I > >> started with to get good clues. > >> > >> > >> root@fireball / # xrandr --listmonitors > >> Monitors: 2 > >> 0: +*VGA-0 1920/598x1080/336+0+0 VGA-0 > >> 1: +HDMI-0 1920/1150x1080/650+1920+0 HDMI-0 > >> root@fireball / # > >> > >> > >> Since I have different ports, it is easy to see which is which. The > >> last bit is what you use in the command, not the first bits. If all > >> your ports are the same, mini HDMI for example, I think the port > >> lowest to the bottom of the video card is number 0, or the first > >> port. Anyway, mine is easy. I then typed in xrandr --output and hit > >> tab twice. It will list all the available monitors. Pick the one > >> you want to be the first output or main monitor. In my case, VGA-0 > >> as shown on the end of line one. Once you type enough, tab > >> completion will fill it in. Then add --primary to that to make it > >> the primary display. > >> > >> For the second monitor, continue on with the command and tab > >> completion. Type in --output and hit tab twice again to list > >> options. Pick the second monitor and type enough in for tab > >> completion to fill in the rest. Then add --right-of, --left-of, > >> --above or --below and then the output device for the main monitor. > >> For me, this is what my command looks like. > >> > >> > >> root@fireball / # xrandr --output VGA-0 --primary --output HDMI-0 > >> --right-of VGA-0 > >> root@fireball / # > >> > >> > >> That makes VGA the primary, HDMI-0 second and to the right of VGA-0. > >> If you have more than two monitors, just keep adding --output and > >> list and place the other monitors. I don't have the means to test > >> but that should work. I'd think setting the primary is key in this > >> so I wouldn't forget to include that. > >> > >> Once you get that command, you can test it by going to a Konsole if > >> using KDE or some other similar tool you can type commands in as root > >> and run the command manually. If it works correctly, add the command > >> to the file in this path. /usr/share/sddm/scripts/Xsetup I haven't > >> logged out and back in again yet so we will see when that happens if > >> it really works and my little quirk goes away. > >> > >> There is a man page for this. It may have other options that you may > >> need to add. Just keep in mind, what is between each --output is > >> what it applies too. One could have different resolutions, image > >> flipped or something and lots of other options. Just keep the > >> options in the right section of the command. > >> > >> I hope this helps someone and makes decent sense. I also hope it > >> works after I logout and back in again. :/ I'm making a note of > >> the location in case I need to comment it out. Better to be safe > >> than sorry. LOL > >> > >> Dale > >> > >> :-) :-) > > > > I've been gone for a few days as I was rebuilding my main PC. > > > > I thought I'd provide an update: it was xorg-server causing all the > > issues. > > > > I figured as I had to redo everything anyway to switch to systemd and > > wayland as that's what the bigger DE's tend to be supporting nowadays. > > > > After fiddling around with systemd for a day (I'd tried it once before > > converting a system from openrc->systemd and failed miserably - > > nothing worked) I've reconfigured most things the "systemd" way. > > > > I guess starting fresh solves all sorts of issues. :o) > > > > Some things I like about systemd: > > - It is capable of automounting NFS shares out of the box; I just > > configured fstab so systemd automatically generated the automount > > configured it required. No extra steps needed; > > - It provides a scrollable list by default showing all the items you > > have access to in order to change how your machines behaves; > > - It isolates services in logs. This was helpful when sddm didn't want > > to behave. > > > > Some things I don't like: > > - It has nutty network configuration. It was applying an APIPA network > > address as the primary for my interface which broke all sorts of
Re: [gentoo-user] Emerge trouble with firefox and thunderbird ...
On 2024.03.03 15:23, Wol wrote: On 03/03/2024 19:40, Jack wrote: On 2024.03.03 13:54, Wols Lists wrote: On 03/03/2024 09:47, Wols Lists wrote: I'm getting this output from emerge --update --newuse --deep --with-bdeps=y @world whoops I mean "emerge --depclean" I'm trying to get a clean system, and don't know what exactly is wrong, or what to try ... Cheers, Wol As the error says, you generally need to do a full update before you can depclean. What error(s) do you get when trying to update firefox or thunderbird? What happens if you try to update @world? Both firefox and thunderbird seemed to die for no obvious reason. Where do I find the logs? But because depclean complained, I did blah-blah-with-bdeps, which emerged (or tried to) 21 packages, but firefox/thunderbird still bombed, and then --depclean still complained. So I don't know what's going on, but basically Mozilla won't emerge, and I don't know why ... Cheers, Wol Did the other 19 package emerge OK? Are the mozilla progs crashing when running, or when emerging? If emerging, the log is just console output, as indecipherable as we know it sometimes can be. If they crash when running, try running from command line.
Re: [gentoo-user] Emerge trouble with firefox and thunderbird ...
On 03/03/2024 19:40, Jack wrote: On 2024.03.03 13:54, Wols Lists wrote: On 03/03/2024 09:47, Wols Lists wrote: I'm getting this output from emerge --update --newuse --deep --with-bdeps=y @world whoops I mean "emerge --depclean" I'm trying to get a clean system, and don't know what exactly is wrong, or what to try ... Cheers, Wol As the error says, you generally need to do a full update before you can depclean. What error(s) do you get when trying to update firefox or thunderbird? What happens if you try to update @world? Both firefox and thunderbird seemed to die for no obvious reason. Where do I find the logs? But because depclean complained, I did blah-blah-with-bdeps, which emerged (or tried to) 21 packages, but firefox/thunderbird still bombed, and then --depclean still complained. So I don't know what's going on, but basically Mozilla won't emerge, and I don't know why ... Cheers, Wol
Re: [gentoo-user] Emerge trouble with firefox and thunderbird ...
On 2024.03.03 13:54, Wols Lists wrote: On 03/03/2024 09:47, Wols Lists wrote: I'm getting this output from emerge --update --newuse --deep --with-bdeps=y @world whoops I mean "emerge --depclean" I'm trying to get a clean system, and don't know what exactly is wrong, or what to try ... Cheers, Wol As the error says, you generally need to do a full update before you can depclean. What error(s) do you get when trying to update firefox or thunderbird? What happens if you try to update @world?
Re: [gentoo-user] Why is KDE so bad at multiple monitors?
On 3/3/24 11:31, Dale wrote: Since my last post, I did my weekly updates. During that, I log out, switch to boot runlevel, restart anything that checkrestart says needs it, then back to default runlevel and log back in. With the config file change, my monitors came up just like they should. I didn't have to adjust anything. I guess it goes to show, one thing fixes one person's system while yet another fixes someone else's system. Go figure. ROFL Dale :-) :-) I strongly suspect that it was a kde setting somewhere in ~. The problem is that config is littered all over the place now instead of one place (I recall zapping the .kde[4] directory from the user home folder in the past, can't do that now...) Although, that doesn't explain the problem I have with X11 and displays. Had those same issues on the fresh install. Dan
Re: [gentoo-user] Why is KDE so bad at multiple monitors?
Daniel Frey wrote: > On 2/29/24 03:27, Dale wrote: >> To provide a little more info on how this works. This is how I did >> it. It helps a LOT to have tab completion with this. It will fill >> in a lot of the info and when unsure, list the available options. >> First, I had to install the package xrandr. My first problem is the >> command isn't available since it wasn't installed. So, if you don't >> have it, install it. It's tiny. This is what I have for my setup. >> You can ignore that I watch TV and just pretend you have two monitors >> side by side or whatever and get the same results. I have a DB15HD >> connector, referred to as VGA within xrandr. That is my main >> monitor. The second monitor is is connected to a HDMI port, seen as >> same in xrandr, and what I watch TV with. This is the output I >> started with to get good clues. >> >> >> root@fireball / # xrandr --listmonitors >> Monitors: 2 >> 0: +*VGA-0 1920/598x1080/336+0+0 VGA-0 >> 1: +HDMI-0 1920/1150x1080/650+1920+0 HDMI-0 >> root@fireball / # >> >> >> Since I have different ports, it is easy to see which is which. The >> last bit is what you use in the command, not the first bits. If all >> your ports are the same, mini HDMI for example, I think the port >> lowest to the bottom of the video card is number 0, or the first >> port. Anyway, mine is easy. I then typed in xrandr --output and hit >> tab twice. It will list all the available monitors. Pick the one >> you want to be the first output or main monitor. In my case, VGA-0 >> as shown on the end of line one. Once you type enough, tab >> completion will fill it in. Then add --primary to that to make it >> the primary display. >> >> For the second monitor, continue on with the command and tab >> completion. Type in --output and hit tab twice again to list >> options. Pick the second monitor and type enough in for tab >> completion to fill in the rest. Then add --right-of, --left-of, >> --above or --below and then the output device for the main monitor. >> For me, this is what my command looks like. >> >> >> root@fireball / # xrandr --output VGA-0 --primary --output HDMI-0 >> --right-of VGA-0 >> root@fireball / # >> >> >> That makes VGA the primary, HDMI-0 second and to the right of VGA-0. >> If you have more than two monitors, just keep adding --output and >> list and place the other monitors. I don't have the means to test >> but that should work. I'd think setting the primary is key in this >> so I wouldn't forget to include that. >> >> Once you get that command, you can test it by going to a Konsole if >> using KDE or some other similar tool you can type commands in as root >> and run the command manually. If it works correctly, add the command >> to the file in this path. /usr/share/sddm/scripts/Xsetup I haven't >> logged out and back in again yet so we will see when that happens if >> it really works and my little quirk goes away. >> >> There is a man page for this. It may have other options that you may >> need to add. Just keep in mind, what is between each --output is >> what it applies too. One could have different resolutions, image >> flipped or something and lots of other options. Just keep the >> options in the right section of the command. >> >> I hope this helps someone and makes decent sense. I also hope it >> works after I logout and back in again. :/ I'm making a note of >> the location in case I need to comment it out. Better to be safe >> than sorry. LOL >> >> Dale >> >> :-) :-) > > I've been gone for a few days as I was rebuilding my main PC. > > I thought I'd provide an update: it was xorg-server causing all the > issues. > > I figured as I had to redo everything anyway to switch to systemd and > wayland as that's what the bigger DE's tend to be supporting nowadays. > > After fiddling around with systemd for a day (I'd tried it once before > converting a system from openrc->systemd and failed miserably - > nothing worked) I've reconfigured most things the "systemd" way. > > I guess starting fresh solves all sorts of issues. :o) > > Some things I like about systemd: > - It is capable of automounting NFS shares out of the box; I just > configured fstab so systemd automatically generated the automount > configured it required. No extra steps needed; > - It provides a scrollable list by default showing all the items you > have access to in order to change how your machines behaves; > - It isolates services in logs. This was helpful when sddm didn't want > to behave. > > Some things I don't like: > - It has nutty network configuration. It was applying an APIPA network > address as the primary for my interface which broke all sorts of > tools. Took me a while to figure out how to stop that. > - It doesn't update resolv.conf even though I'd specified a DNS > server! So literally nothing worked. For now I manually removed > resolv.conf and put the DNS server there. Plan to use something >
[gentoo-user] AMD microkernel update failing (trying to patch zenbleed)
Hi all, I've always had problems updating the microcode for my AMD processor. I have various other Intel-based PCs and this has never been an issue. I have confirmed it's not updating: ~ # dmesg | grep -i microcode [0.201619] Zenbleed: please update your microcode for the most optimal fix [0.748482] microcode: CPU1: patch_level=0x08701030 [0.748482] microcode: CPU0: patch_level=0x08701030 [0.748484] microcode: CPU3: patch_level=0x08701030 [0.748485] microcode: CPU5: patch_level=0x08701030 [0.748485] microcode: CPU4: patch_level=0x08701030 [0.748486] microcode: CPU6: patch_level=0x08701030 [0.748486] microcode: CPU7: patch_level=0x08701030 [0.748487] microcode: CPU8: patch_level=0x08701030 [0.748488] microcode: CPU9: patch_level=0x08701030 [0.748488] microcode: CPU10: patch_level=0x08701030 [0.748488] microcode: CPU11: patch_level=0x08701030 [0.748491] microcode: CPU12: patch_level=0x08701030 [0.748491] microcode: CPU13: patch_level=0x08701030 [0.748492] microcode: CPU14: patch_level=0x08701030 [0.748493] microcode: CPU15: patch_level=0x08701030 [0.748496] microcode: CPU17: patch_level=0x08701030 [0.748496] microcode: CPU18: patch_level=0x08701030 [0.748498] microcode: CPU19: patch_level=0x08701030 [0.748498] microcode: CPU20: patch_level=0x08701030 [0.748500] microcode: CPU21: patch_level=0x08701030 [0.748500] microcode: CPU22: patch_level=0x08701030 [0.748501] microcode: CPU24: patch_level=0x08701030 [0.748501] microcode: CPU23: patch_level=0x08701030 [0.748503] microcode: CPU16: patch_level=0x08701030 [0.748503] microcode: CPU26: patch_level=0x08701030 [0.748503] microcode: CPU27: patch_level=0x08701030 [0.748505] microcode: CPU28: patch_level=0x08701030 [0.748506] microcode: CPU29: patch_level=0x08701030 [0.748507] microcode: CPU30: patch_level=0x08701030 [0.748508] microcode: CPU25: patch_level=0x08701030 [0.748509] microcode: CPU31: patch_level=0x08701030 [0.748511] microcode: CPU2: patch_level=0x08701030 [0.748554] microcode: Microcode Update Driver: v2.2. I'm pretty sure I wouldn't be getting a zenbleed warning if it was using the most recent microcode. My processor is this one: vendor_id : AuthenticAMD cpu family : 23 model : 113 model name : AMD Ryzen 9 3950X 16-Core Processor This leads me to the 17h family. I do not use an initramfs as my system doesn't require one. I am not willing to try an initramfs as my system fully functions without one and this is not an issue with the Intel machines I have. I have properly configured the kernel (gentoo-sources-6.6.13): CONFIG_CPU_SUP_AMD=y CONFIG_EXTRA_FIRMWARE="brcm/BCM20702B0-19ff-0239.hcd amd-ucode/microcode_amd_fam17h.bin" CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" The firmware loading is working as it does load the firmware for my bluetooth adapter with no issues. (In the newer kernels microcode loading is enabled by default - no way to turn it off. All you have to do is select CPU_SUP_AMD apparently. It works on Intel machines.) I've even updated the motherboard BIOS firmware, and while that fixed all the other issues it apparently does not have patches for zenbleed. Does anyone have any idea why this will not update? -Dan
Re: [gentoo-user] Why is KDE so bad at multiple monitors?
On 2/29/24 03:27, Dale wrote: To provide a little more info on how this works. This is how I did it. It helps a LOT to have tab completion with this. It will fill in a lot of the info and when unsure, list the available options. First, I had to install the package xrandr. My first problem is the command isn't available since it wasn't installed. So, if you don't have it, install it. It's tiny. This is what I have for my setup. You can ignore that I watch TV and just pretend you have two monitors side by side or whatever and get the same results. I have a DB15HD connector, referred to as VGA within xrandr. That is my main monitor. The second monitor is is connected to a HDMI port, seen as same in xrandr, and what I watch TV with. This is the output I started with to get good clues. root@fireball / # xrandr --listmonitors Monitors: 2 0: +*VGA-0 1920/598x1080/336+0+0 VGA-0 1: +HDMI-0 1920/1150x1080/650+1920+0 HDMI-0 root@fireball / # Since I have different ports, it is easy to see which is which. The last bit is what you use in the command, not the first bits. If all your ports are the same, mini HDMI for example, I think the port lowest to the bottom of the video card is number 0, or the first port. Anyway, mine is easy. I then typed in xrandr --output and hit tab twice. It will list all the available monitors. Pick the one you want to be the first output or main monitor. In my case, VGA-0 as shown on the end of line one. Once you type enough, tab completion will fill it in. Then add --primary to that to make it the primary display. For the second monitor, continue on with the command and tab completion. Type in --output and hit tab twice again to list options. Pick the second monitor and type enough in for tab completion to fill in the rest. Then add --right-of, --left-of, --above or --below and then the output device for the main monitor. For me, this is what my command looks like. root@fireball / # xrandr --output VGA-0 --primary --output HDMI-0 --right-of VGA-0 root@fireball / # That makes VGA the primary, HDMI-0 second and to the right of VGA-0. If you have more than two monitors, just keep adding --output and list and place the other monitors. I don't have the means to test but that should work. I'd think setting the primary is key in this so I wouldn't forget to include that. Once you get that command, you can test it by going to a Konsole if using KDE or some other similar tool you can type commands in as root and run the command manually. If it works correctly, add the command to the file in this path. /usr/share/sddm/scripts/Xsetup I haven't logged out and back in again yet so we will see when that happens if it really works and my little quirk goes away. There is a man page for this. It may have other options that you may need to add. Just keep in mind, what is between each --output is what it applies too. One could have different resolutions, image flipped or something and lots of other options. Just keep the options in the right section of the command. I hope this helps someone and makes decent sense. I also hope it works after I logout and back in again. :/ I'm making a note of the location in case I need to comment it out. Better to be safe than sorry. LOL Dale :-) :-) I've been gone for a few days as I was rebuilding my main PC. I thought I'd provide an update: it was xorg-server causing all the issues. I figured as I had to redo everything anyway to switch to systemd and wayland as that's what the bigger DE's tend to be supporting nowadays. After fiddling around with systemd for a day (I'd tried it once before converting a system from openrc->systemd and failed miserably - nothing worked) I've reconfigured most things the "systemd" way. I guess starting fresh solves all sorts of issues. :o) Some things I like about systemd: - It is capable of automounting NFS shares out of the box; I just configured fstab so systemd automatically generated the automount configured it required. No extra steps needed; - It provides a scrollable list by default showing all the items you have access to in order to change how your machines behaves; - It isolates services in logs. This was helpful when sddm didn't want to behave. Some things I don't like: - It has nutty network configuration. It was applying an APIPA network address as the primary for my interface which broke all sorts of tools. Took me a while to figure out how to stop that. - It doesn't update resolv.conf even though I'd specified a DNS server! So literally nothing worked. For now I manually removed resolv.conf and put the DNS server there. Plan to use something else for network management that sets resolv.conf properly. I have no desire to use networkd-resolved. But, back to the original problem... I don't know what was broken in my original system. I always had to
Re: [gentoo-user] Emerge trouble with firefox and thunderbird ...
On 03/03/2024 09:47, Wols Lists wrote: I'm getting this output from emerge --update --newuse --deep --with-bdeps=y @world whoops I mean "emerge --depclean" I'm trying to get a clean system, and don't know what exactly is wrong, or what to try ... Cheers, Wol
Re: [gentoo-user] CPU ISA level is lower than required
Am Sonntag, 3. März 2024, 14:32:41 CET schrieb Andreas K. Huettel: > > I set CFLAGS="-O2 -pipe march=x86-64-v2" on the buildhost and performed a > > emerge -ev @world, re-creating all packages in binary form. > > > > My expectation was that these packages would work on the target platform, > > but they don't. Error message "CPU ISA level is lower than required". > > Quiz question: did you rebuild your toolchain *before* or *after* bzip2? > > Suspicion without proof, the startup code embedded by gcc and glibc may well > be affected by the microarchitecture level. As may be libraries statically > linked in... > > The safer way would be to run emerge -ev world, and afterwards build the > packages with a second emerge -ev world ... Indeed, that seems to be the problem. I remember, my first try was with -v3 (as my buildhost supported this), and, after discovering the "surprise" on the target machine, started the emerge -ev @world. Likely, glibc was not the first package, so there are an unknown number of packets that have the problem. I started to recompile the "usual suspects", like bzip2 and xz, which made it a bit better, but still the emerge -uavDNk @world did not succeed. Now I'm doing again a emerge -ev @world on my buildhost again, so tomorrow it should be solved. Thanks for the hint Alex
Re: [gentoo-user] CPU ISA level is lower than required
> > I set CFLAGS="-O2 -pipe march=x86-64-v2" on the buildhost and performed a > emerge -ev @world, re-creating all packages in binary form. > > My expectation was that these packages would work on the target platform, but > they don't. Error message "CPU ISA level is lower than required". > Quiz question: did you rebuild your toolchain *before* or *after* bzip2? Suspicion without proof, the startup code embedded by gcc and glibc may well be affected by the microarchitecture level. As may be libraries statically linked in... The safer way would be to run emerge -ev world, and afterwards build the packages with a second emerge -ev world ... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice)
[gentoo-user] Emerge trouble with firefox and thunderbird ...
I'm getting this output from emerge --update --newuse --deep --with-bdeps=y @world Calculating dependencies... done! * Dependencies could not be completely resolved due to * the following required packages not being installed: * * >=dev-libs/icu-73.1:0/73.1= pulled in by: * www-client/firefox-115.6.0 * * Have you forgotten to do a complete update prior to depclean? The * most comprehensive command for this purpose is as follows: * * emerge --update --newuse --deep --with-bdeps=y @world * * Note that the --with-bdeps=y option is not required in many * situations. Refer to the emerge manual page (run `man emerge`) * for more information about --with-bdeps. * * Also, note that it may be necessary to manually uninstall * packages that no longer exist in the repository, since it may not * be possible to satisfy their dependencies. thewolery /usr/local/bin # icu is at 74.2 firefox failed to update ... * www-client/firefox Latest version available: 115.8.0 Latest version installed: 115.6.0 Size of files: 496,244 KiB Homepage: https://www.mozilla.com/firefox Description: Firefox Web Browser License: MPL-2.0 GPL-2 LGPL-2.1 as did thunderbird ... * mail-client/thunderbird Latest version available: 115.8.0 Latest version installed: 115.6.0 Size of files: 528,920 KiB Homepage: https://www.thunderbird.net/ Description: Thunderbird Mail Client License: MPL-2.0 GPL-2 LGPL-2.1 Andy ideas? Or is the mozilla emerge stuff slightly broken on my system? I've been having trouble with those two for the last few weeks ... Cheers, Wol
[gentoo-user] CPU ISA level is lower than required
Hi, I tried to tweak some settings regarding CFLAGS="march=x86-64-v2" on my buildhost and then install the binary packages on the target machines. Buildhost: AMD Ryzen 7 2700; ld.so --help says: Subdirectories of glibc-hwcaps directories, in priority order: x86-64-v4 x86-64-v3 (supported, searched) x86-64-v2 (supported, searched) Target platform: AMD A8-5500; ld.so --help says Subdirectories of glibc-hwcaps directories, in priority order: x86-64-v4 x86-64-v3 x86-64-v2 (supported, searched) I set CFLAGS="-O2 -pipe march=x86-64-v2" on the buildhost and performed a emerge -ev @world, re-creating all packages in binary form. My expectation was that these packages would work on the target platform, but they don't. Error message "CPU ISA level is lower than required". Q: The binary (e.g. /usr/bin/bzip2) obviously "knows" what it requires. How do I find out what this is? Neither ldd, ld.so or the like seem to give me this information. Q: Does the xpak format encode those requirements in any way, if so , how can I read them? Q: Can I compile binary packages with multiple ISA sets and let portage on the target machine decide which sub-package to use depending on capabilities of the target CPU?
