Re: Fix failed DNF upgrade?
On Tue, 2022-11-08 at 08:03 -0800, Scott Beamer wrote: > Greetings, > > I recently read somewhere that there is a dnf command to finish > upgrading when an upgrade crashes during an upgrade. I tried Googling > to > find it just now and have come up empty. > > Does anyone know what it is? I think you mean this: https://linux.die.net/man/8/yum-complete-transaction However it seems to no longer exist with dnf. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Looking to get connection between 2 local networks?
On Wed, 2022-11-09 at 03:09 +1000, Michael D. Setzer II via users wrote: > Probable a simple solution, but its been a while since I done this > type of stuff. > > Have a cable modem that has 4 ports but using 2. > First port gets public IP xxx.xxx.233.11 with private network > 192.168.16.x > Second port gets public IP xxx.xxx.234.251 with private network > 192.168.24.x > > ip route > default via 192.168.16.1 dev enp8s0 proto dhcp metric 100 > default via 192.168.24.1 dev wlp7s0 proto dhcp metric 600 > 192.168.16.0/24 dev enp8s0 proto kernel scope link src 192.168.16.101 > metric 100 > 192.168.24.0/24 dev wlp7s0 proto kernel scope link src 192.168.24.13 > metric 600 > > > In searching found pages that say shouldn't have two default routes, > but that it what it shows on > systems connect to both networks by default. Many things work, but > others don't. > The setup you have here is fundamentally different from the one you used in the past. there you had different downstream networks, here you are combinigupstream networks. What do you need the 2 public IP adresses for? With what you have here packets from the internal network to the internet will gate routed to the gateway with the lowest metric. So all originating traffic will go out over the 192.168.16.1 gateway. As long as that gateway can reach the desired destination you are fine. Traffic originating from the outside to the second public IP will get to your box (through your .24.x gateway. Responses will however be sent to the preferred gateway (the Other gateway) and will probably be dropped there as there no connection on that gateway. you modem setup seems to be pretty strange. Please describe what the different public IP addresses are to be used for and what your box is to do with them. The modem splitting the public IP-addresses over different interfaces seems to suggest that there is to be some isolation between them. But then you seem to be combining these networks again, something that is probably not desirable I you want to just allow routing of pure internal traffic to the second network you may need to disable the setting of the default route on the second interface ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fix failed DNF upgrade?
On Tue, 8 Nov 2022 08:03:55 -0800 Scott Beamer wrote: > Greetings, > > I recently read somewhere that there is a dnf command to finish > upgrading when an upgrade crashes during an upgrade. I tried Googling > to find it just now and have come up empty. > > Does anyone know what it is? Others have answered this question, that it no longer exists. And suggested that just restarting dnf update might work, if the crash wasn't hardware related. However, you might look at man dnf, and check the distro-sync command. It ensures that you are synced with the latest of every package you have installed for your fedora version. Not exactly what you wanted, but might suffice. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
virt-sparsify ?
Any downside to ths tool? https://libguestfs.org/virt-sparsify.1.html ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: virt-sparsify ?
On 11/9/22 08:28, ToddAndMargo via users wrote: Any downside to ths tool? https://libguestfs.org/virt-sparsify.1.html This is what I am looking at: $ du -sh *.qcow* 4.6GKVM-Android.qcow2 72M KVM-BackupDrive.w10.qcow2 36M KVM-BackupDrive.w11.qcow2 72M KVM-BackupDrive.w7.qcow2 17G KVM-Fedora-23-AutoScan.qcow2 38G KVM-Fedora-Xfce.qcow2 8.1GKVM-LiveCDs.qcow2 61G KVM-W10.qcow2 60G KVM-W11.qcow2 40G KVM-W7.qcow 46M KVM-W7.qcow2 4.0KKVM-WinXP.qcow.02-13-2015.lin-bak.txt $ ls -lh *.qcow* -rwxrw-rw-. 1 root root 11G May 5 2022 KVM-Android.qcow2 -rw---. 1 qemu qemu 72M Nov 6 21:44 KVM-BackupDrive.w10.qcow2 -rw---. 1 qemu qemu 36M Nov 9 00:31 KVM-BackupDrive.w11.qcow2 -rw---. 1 qemu qemu 72M Nov 9 07:34 KVM-BackupDrive.w7.qcow2 -rwxrw-rw-. 1 todd users 17G Apr 23 2019 KVM-Fedora-23-AutoScan.qcow2 -rwxrw-rw-. 1 todd users 40G Jul 22 22:03 KVM-Fedora-Xfce.qcow2 -rwxrw-rw-. 1 todd users 8.1G Jul 17 2017 KVM-LiveCDs.qcow2 -rwxrw-rw-. 1 qemu qemu 61G Nov 6 21:44 KVM-W10.qcow2 -rw---. 1 qemu qemu 61G Nov 9 00:31 KVM-W11.qcow2 -rwxrw-rw-. 1 qemu qemu 40G Nov 9 07:34 KVM-W7.qcow -rwxrw-rw-. 1 qemu qemu 2.1G Nov 9 07:34 KVM-W7.qcow2 -rwxrw-rw-. 1 todd users 46 Feb 14 2015 KVM-WinXP.qcow.02-13-2015.lin-bak.txt ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: virt-sparsify ?
There shouldn't be any downside, but per the doc the virtual machine must be off, no other tools used concurrently. It seems that virt-sparsify can be used with an input and output image file or operate on the image file directly, the first option being the safest in the event of corruption on the new disk image the original image can reverted back to use. Regards, -Jamie On Wed, Nov 9, 2022 at 11:29 AM ToddAndMargo via users wrote: > > Any downside to ths tool? > > https://libguestfs.org/virt-sparsify.1.html > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Moving to a new GPU
I've replaced my ageing Nvidia card with a more recent and much faster AMD GPU. However when I boot the system, the default display still shows as the built-in Intel chip, even though AMD modules are loaded: $ sudo lsmod|grep -i amd amdgpu 10153984 1 iommu_v2 24576 1 amdgpu gpu_sched 49152 1 amdgpu drm_ttm_helper 16384 1 amdgpu drm_buddy 20480 2 amdgpu,i915 drm_display_helper180224 2 amdgpu,i915 ttm94208 3 amdgpu,drm_ttm_helper,i915 (Nvidia modules are not loaded). Inxi shows: $ inxi -G Graphics: Device-1: Intel IvyBridge GT2 [HD Graphics 4000] driver: i915 v: kernel Device-2: AMD Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] driver: amdgpu v: kernel Display: x11 server: X.Org v: 1.20.14 with: Xwayland v: 22.1.3 driver: X: loaded: amdgpu,modesetting unloaded: fbdev,vesa dri: crocus gpu: i915 resolution: 1920x1080~60Hz OpenGL: renderer: Mesa Intel HD Graphics 4000 (IVB GT2) v: 4.2 Mesa 22.1.7 Switcherooctl shows both GPUs: $ switcherooctl list Device: 0 Name:Intel® HD Graphics 4000 Default: yes Environment: DRI_PRIME=pci-_00_02_0 Device: 1 Name:Advanced Micro Devices, Inc. [AMD®/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (Radeon RX 580) Default: no Environment: DRI_PRIME=pci-_01_00_0 I should mention that both GPUs are connected through an HDMI switch to a single monitor. I've used this successfully in the past to get PCI passthrough on Windows VMs for gaming. I haven't touched anything else. I tried unplugging the i915 and rebooting (after removing the HDMI switch and connecting the monitor directly), but simply got a blank screen (in fact three dots at the top left). Is there some grub magic I need to do? I assumed this would be automatic but it seems not. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Moving to a new GPU
Patrick O'Callaghan composed on 2022-11-09 17:09 (UTC): > $ inxi -G That's not enough info. Show -GSaz please. Proprietary NVidia driver removal is not a simple matter of uninstalling rpms. Typically blacklisting and/or /etc/X11/xorg.con* files and/or kernel cmdline options get left behind, and sometimes even a replacement library, or an initrd rebuild is needed. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Moving to a new GPU
On Wed, 2022-11-09 at 12:27 -0500, Felix Miata wrote: > Patrick O'Callaghan composed on 2022-11-09 17:09 (UTC): > > > $ inxi -G > > That's not enough info. Show -GSaz please. > $ inxi -Gsaz Graphics: Device-1: Intel IvyBridge GT2 [HD Graphics 4000] vendor: Micro-Star MSI driver: i915 v: kernel arch: Gen-7 process: Intel 22nm built: 2012-13 ports: active: HDMI-A-1 empty: DP-1,VGA-1 bus-ID: 00:02.0 chip-ID: 8086:0162 class-ID: 0300 Device-2: AMD Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] vendor: Tul / PowerColor driver: amdgpu v: kernel arch: GCN-4 code: Arctic Islands process: GF 14nm built: 2016-20 pcie: gen: 1 speed: 2.5 GT/s lanes: 16 link-max: gen: 3 speed: 8 GT/s ports: active: none empty: DP-2, DP-3, DP-4, DVI-D-1, HDMI-A-2 bus-ID: 01:00.0 chip-ID: 1002:67df class-ID: 0300 temp: 29.0 C Display: x11 server: X.Org v: 1.20.14 with: Xwayland v: 22.1.3 compositor: kwin_x11 driver: X: loaded: amdgpu,modesetting unloaded: fbdev,vesa dri: crocus gpu: i915 display-ID: :0 screens: 1 Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22") s-diag: 582mm (22.93") Monitor-1: HDMI-A-1 mapped: HDMI-1 model: HP 24f serial: built: 2020 res: 1920x1080 hz: 60 dpi: 93 gamma: 1.2 size: 527x296mm (20.75x11.65") diag: 604mm (23.8") ratio: 16:9 modes: max: 1920x1080 min: 720x400 OpenGL: renderer: Mesa Intel HD Graphics 4000 (IVB GT2) v: 4.2 Mesa 22.1.7 direct render: Yes Sensors: System Temperatures: cpu: 29.0 C mobo: N/A gpu: amdgpu temp: 28.0 C Fan Speeds (RPM): N/A > Proprietary NVidia driver removal is not a simple matter of > uninstalling rpms. > Typically blacklisting and/or /etc/X11/xorg.con* files and/or kernel > cmdline > options get left behind, and sometimes even a replacement library, or > an initrd > rebuild is needed. I thought as much but wasn't sure. The current boot line is: $ cat /proc/cmdline BOOT_IMAGE=(hd2,gpt2)/vmlinuz-6.0.5-200.fc36.x86_64 root=UUID=8e1f7af4-c0bf-434e-b1c4-a9af2c810d56 ro rootflags=subvol=root modprobe.blacklist=nouveau rd.blacklist=nouveau vconsole.font=latarcyrheb-sun16 rhgb quiet audit=0 It's blacklisting nouveau because I used to use the proprietary Nvidia driver. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Moving to a new GPU
On Wed, 2022-11-09 at 19:25 +, Patrick O'Callaghan wrote: > On Wed, 2022-11-09 at 12:27 -0500, Felix Miata wrote: > > Patrick O'Callaghan composed on 2022-11-09 17:09 (UTC): > > > > > $ inxi -G > > > > That's not enough info. Show -GSaz please. > > > > $ inxi -Gsaz > Graphics: > Device-1: Intel IvyBridge GT2 [HD Graphics 4000] vendor: Micro-Star > MSI > driver: i915 v: kernel arch: Gen-7 process: Intel 22nm built: > 2012-13 > ports: active: HDMI-A-1 empty: DP-1,VGA-1 bus-ID: 00:02.0 > chip-ID: 8086:0162 class-ID: 0300 > Device-2: AMD Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] > vendor: Tul / PowerColor driver: amdgpu v: kernel arch: GCN-4 > code: Arctic Islands process: GF 14nm built: 2016-20 pcie: gen: 1 > speed: 2.5 GT/s lanes: 16 link-max: gen: 3 speed: 8 GT/s ports: > active: none empty: DP-2, DP-3, DP-4, DVI-D-1, HDMI-A-2 bus-ID: > 01:00.0 > chip-ID: 1002:67df class-ID: 0300 temp: 29.0 C > Display: x11 server: X.Org v: 1.20.14 with: Xwayland v: 22.1.3 > compositor: kwin_x11 driver: X: loaded: amdgpu,modesetting > unloaded: fbdev,vesa dri: crocus gpu: i915 display-ID: :0 > screens: 1 > Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm > (20.00x11.22") > s-diag: 582mm (22.93") > Monitor-1: HDMI-A-1 mapped: HDMI-1 model: HP 24f serial: > built: 2020 res: 1920x1080 hz: 60 dpi: 93 gamma: 1.2 > size: 527x296mm (20.75x11.65") diag: 604mm (23.8") ratio: 16:9 > modes: > max: 1920x1080 min: 720x400 > OpenGL: renderer: Mesa Intel HD Graphics 4000 (IVB GT2) v: 4.2 Mesa > 22.1.7 direct render: Yes > Sensors: > System Temperatures: cpu: 29.0 C mobo: N/A gpu: amdgpu temp: 28.0 C > Fan Speeds (RPM): N/A > > > Proprietary NVidia driver removal is not a simple matter of > > uninstalling rpms. > > Typically blacklisting and/or /etc/X11/xorg.con* files and/or > > kernel > > cmdline > > options get left behind, and sometimes even a replacement library, > > or > > an initrd > > rebuild is needed. Sorry, wrong options. Once again: $ inxi -GSaz System: Kernel: 6.0.5-200.fc36.x86_64 arch: x86_64 bits: 64 compiler: gcc v: 2.37-36.fc36 parameters: BOOT_IMAGE=(hd2,gpt2)/vmlinuz-6.0.5-200.fc36.x86_64 root=UUID=8e1f7af4-c0bf-434e-b1c4-a9af2c810d56 ro rootflags=subvol=root modprobe.blacklist=nouveau rd.blacklist=nouveau vconsole.font=latarcyrheb-sun16 rhgb quiet audit=0 Desktop: KDE Plasma v: 5.25.5 tk: Qt v: 5.15.6 wm: kwin_x11 vt: 2 dm: SDDM Distro: Fedora release 36 (Thirty Six) Graphics: Device-1: Intel IvyBridge GT2 [HD Graphics 4000] vendor: Micro-Star MSI driver: i915 v: kernel arch: Gen-7 process: Intel 22nm built: 2012-13 ports: active: HDMI-A-1 empty: DP-1,VGA-1 bus-ID: 00:02.0 chip-ID: 8086:0162 class-ID: 0300 Device-2: AMD Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] vendor: Tul / PowerColor driver: amdgpu v: kernel arch: GCN-4 code: Arctic Islands process: GF 14nm built: 2016-20 pcie: gen: 1 speed: 2.5 GT/s lanes: 16 link-max: gen: 3 speed: 8 GT/s ports: active: none empty: DP-2, DP-3, DP-4, DVI-D-1, HDMI-A-2 bus-ID: 01:00.0 chip-ID: 1002:67df class-ID: 0300 temp: 29.0 C Display: x11 server: X.Org v: 1.20.14 with: Xwayland v: 22.1.3 compositor: kwin_x11 driver: X: loaded: amdgpu,modesetting unloaded: fbdev,vesa dri: crocus gpu: i915 display-ID: :0 screens: 1 Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22") s-diag: 582mm (22.93") Monitor-1: HDMI-A-1 mapped: HDMI-1 model: HP 24f serial: built: 2020 res: 1920x1080 hz: 60 dpi: 93 gamma: 1.2 size: 527x296mm (20.75x11.65") diag: 604mm (23.8") ratio: 16:9 modes: max: 1920x1080 min: 720x400 OpenGL: renderer: Mesa Intel HD Graphics 4000 (IVB GT2) v: 4.2 Mesa 22.1.7 direct render: Yes There's nothing relevant in /etc/X11/xorg.conf.d poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Moving to a new GPU
Patrick O'Callaghan composed on 2022-11-09 20:07 (UTC): > $ inxi -GSaz > System: > Kernel: 6.0.5-200.fc36.x86_64 arch: x86_64 bits: 64 compiler: gcc > v: 2.37-36.fc36 > parameters: BOOT_IMAGE=(hd2,gpt2)/vmlinuz-6.0.5-200.fc36.x86_64 > root=UUID=8e1f7af4-c0bf-434e-b1c4-a9af2c810d56 ro rootflags=subvol=root > modprobe.blacklist=nouveau rd.blacklist=nouveau Competent FOSS display drivers for NVidia GPUs require the KMS that those two =nouveau parameters disable. Purging those two from /etc/default/grub & grub.cfg followed by reboot should be all you need, but you can test by editing them away via the E key at the Grub menu. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Moving to a new GPU
On 11/9/22 12:36, Felix Miata wrote: Patrick O'Callaghan composed on 2022-11-09 20:07 (UTC): $ inxi -GSaz System: Kernel: 6.0.5-200.fc36.x86_64 arch: x86_64 bits: 64 compiler: gcc v: 2.37-36.fc36 parameters: BOOT_IMAGE=(hd2,gpt2)/vmlinuz-6.0.5-200.fc36.x86_64 root=UUID=8e1f7af4-c0bf-434e-b1c4-a9af2c810d56 ro rootflags=subvol=root modprobe.blacklist=nouveau rd.blacklist=nouveau Competent FOSS display drivers for NVidia GPUs require the KMS that those two =nouveau parameters disable. Purging those two from /etc/default/grub & grub.cfg followed by reboot should be all you need, but you can test by editing them away via the E key at the Grub menu. How are those parameters relevant to the current situation? I agree that they should be removed because they are no longer relevant, but they shouldn't be affecting anything. The new graphics is AMD. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Moving to a new GPU
Samuel Sieb composed on 2022-11-09 16:38 (UTC-0500): > Felix Miata wrote: >> Patrick O'Callaghan composed on 2022-11-09 20:07 (UTC): >>> $ inxi -GSaz >>> System: >>>Kernel: 6.0.5-200.fc36.x86_64 arch: x86_64 bits: 64 compiler: gcc >>> v: 2.37-36.fc36 >>> parameters: BOOT_IMAGE=(hd2,gpt2)/vmlinuz-6.0.5-200.fc36.x86_64 >>> root=UUID=8e1f7af4-c0bf-434e-b1c4-a9af2c810d56 ro rootflags=subvol=root >>> modprobe.blacklist=nouveau rd.blacklist=nouveau >> Competent FOSS display drivers for NVidia GPUs require the KMS that those two >> =nouveau parameters disable. Purging those two from /etc/default/grub & >> grub.cfg >> followed by reboot should be all you need, but you can test by editing them >> away >> via the E key at the Grub menu. > How are those parameters relevant to the current situation? I agree > that they should be removed because they are no longer relevant, but > they shouldn't be affecting anything. The new graphics is AMD. They aren't relevant, but I got sidetracked and when I came back I thought I was done. Obviously I hadn't finished thinking through this before clicking send. :( -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Moving to a new GPU
On Wed, Nov 9, 2022 at 6:09 PM Patrick O'Callaghan wrote: > > I've replaced my ageing Nvidia card with a more recent and much faster > AMD GPU. However when I boot the system, the default display still > shows as the built-in Intel chip, even though AMD modules are loaded: > > $ sudo lsmod|grep -i amd > amdgpu 10153984 1 > iommu_v2 24576 1 amdgpu > gpu_sched 49152 1 amdgpu > drm_ttm_helper 16384 1 amdgpu > drm_buddy 20480 2 amdgpu,i915 > drm_display_helper180224 2 amdgpu,i915 > ttm94208 3 amdgpu,drm_ttm_helper,i915 > > (Nvidia modules are not loaded). > > Inxi shows: > > $ inxi -G > Graphics: > Device-1: Intel IvyBridge GT2 [HD Graphics 4000] driver: i915 v: kernel > Device-2: AMD Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] > driver: amdgpu v: kernel > Display: x11 server: X.Org v: 1.20.14 with: Xwayland v: 22.1.3 driver: X: > loaded: amdgpu,modesetting unloaded: fbdev,vesa dri: crocus gpu: i915 > resolution: 1920x1080~60Hz > OpenGL: renderer: Mesa Intel HD Graphics 4000 (IVB GT2) v: 4.2 Mesa > 22.1.7 > > Switcherooctl shows both GPUs: > > $ switcherooctl list > Device: 0 > Name:Intel® HD Graphics 4000 > Default: yes > Environment: DRI_PRIME=pci-_00_02_0 > > Device: 1 > Name:Advanced Micro Devices, Inc. [AMD®/ATI] Ellesmere > [Radeon RX 470/480/570/570X/580/580X/590] (Radeon RX 580) > Default: no > Environment: DRI_PRIME=pci-_01_00_0 > > I should mention that both GPUs are connected through an HDMI switch to > a single monitor. I've used this successfully in the past to get PCI > passthrough on Windows VMs for gaming. > > I haven't touched anything else. I tried unplugging the i915 and > rebooting (after removing the HDMI switch and connecting the monitor > directly), but simply got a blank screen (in fact three dots at the top > left). In order to disable i915 altogether, I used an option in bios/efi firmware. (I have an NVIDIA card and want to use it always/for any application.) > Is there some grub magic I need to do? I assumed this would be > automatic but it seems not. If the intention is to use either i915 or the AMD card depending on the application that is AMD Dynamic Switchable Graphics, I would suggest looking at https://wiki.archlinux.org/title/PRIME#Gnome_integration https://wiki.archlinux.org/title/PRIME https://wiki.archlinux.org/title/ATI https://wiki.archlinux.org/title/AMDGPU greg ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Moving to a new GPU
On Wed, 2022-11-09 at 22:55 +0100, greg wrote: > In order to disable i915 altogether, I used an option in bios/efi > firmware. > (I have an NVIDIA card and want to use it always/for any > application.) > That would certainly be an option, though I'd prefer to avoid BIOS settings id possible. > > Is there some grub magic I need to do? I assumed this would be > > automatic but it seems not. > > If the intention is to use either i915 or the AMD card depending on > the application > that is AMD Dynamic Switchable Graphics, > I would suggest looking at > > https://wiki.archlinux.org/title/PRIME#Gnome_integration > https://wiki.archlinux.org/title/PRIME > https://wiki.archlinux.org/title/ATI > https://wiki.archlinux.org/title/AMDGPU A lot of very detailed info there, thanks. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Moving to a new GPU
On Wed, 2022-11-09 at 13:38 -0800, Samuel Sieb wrote: > On 11/9/22 12:36, Felix Miata wrote: > > Patrick O'Callaghan composed on 2022-11-09 20:07 (UTC): > > > > > $ inxi -GSaz > > > System: > > > Kernel: 6.0.5-200.fc36.x86_64 arch: x86_64 bits: 64 compiler: > > > gcc > > > v: 2.37-36.fc36 > > > parameters: BOOT_IMAGE=(hd2,gpt2)/vmlinuz-6.0.5- > > > 200.fc36.x86_64 > > > root=UUID=8e1f7af4-c0bf-434e-b1c4-a9af2c810d56 ro > > > rootflags=subvol=root > > > modprobe.blacklist=nouveau rd.blacklist=nouveau > > > > Competent FOSS display drivers for NVidia GPUs require the KMS that > > those two > > =nouveau parameters disable. Purging those two from > > /etc/default/grub & grub.cfg > > followed by reboot should be all you need, but you can test by > > editing them away > > via the E key at the Grub menu. > > How are those parameters relevant to the current situation? I agree > that they should be removed because they are no longer relevant, but > they shouldn't be affecting anything. The new graphics is AMD. They may be relevant if they remove KMS, which apparently AMD requires. I've removed them in any case and rebooted, but it doesn't seem to make a lot of difference. I'll read through the material Greg referenced, which suggests I need to install some extra packages. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Looking to get connection between 2 local networks?
On 9 Nov 2022 at 15:53, Louis Lagendijk wrote: Subject:Re: Looking to get connection between 2 local networks? From: Louis Lagendijk To: users@lists.fedoraproject.org Date sent: Wed, 09 Nov 2022 15:53:39 +0100 Send reply to: Community support for Fedora users > On Wed, 2022-11-09 at 03:09 +1000, Michael D. Setzer II via users > wrote: > > Probable a simple solution, but its been a while since I done this > > type of stuff. > > > > Have a cable modem that has 4 ports but using 2. > > First port gets public IP xxx.xxx.233.11 with private network > > 192.168.16.x > > Second port gets public IP xxx.xxx.234.251 with private network > > 192.168.24.x > > > > ip route > > default via 192.168.16.1 dev enp8s0 proto dhcp metric 100 > > default via 192.168.24.1 dev wlp7s0 proto dhcp metric 600 > > 192.168.16.0/24 dev enp8s0 proto kernel scope link src 192.168.16.101 > > metric 100 > > 192.168.24.0/24 dev wlp7s0 proto kernel scope link src 192.168.24.13 > > metric 600 > > > > > > In searching found pages that say shouldn't have two default routes, > > but that it what it shows on > > systems connect to both networks by default. Many things work, but > > others don't. > > > The setup you have here is fundamentally different from the one you > used in the past. there you had different downstream networks, here you > are combinigupstream networks. > What do you need the 2 public IP adresses for? With what you have here > packets from the internal network to the internet will gate routed to > the gateway with the lowest metric. So all originating traffic will go > out over the 192.168.16.1 gateway. As long as that gateway can reach > the desired destination you are fine. > Traffic originating from the outside to the second public IP will get > to your box (through your .24.x gateway. Responses will however be sent > to the preferred gateway (the Other gateway) and will probably be > dropped there as there no connection on that gateway. > > you modem setup seems to be pretty strange. Please describe what the > different public IP addresses are to be used for and what your box is > to do with them. The modem splitting the public IP-addresses over > different interfaces seems to suggest that there is to be some > isolation between them. But then you seem to be combining these > networks again, something that is probably not desirable > > I you want to just allow routing of pure internal traffic to the second > network you may need to disable the setting of the default route on the > second interface Thanks for info. My older wifi router only 2.4 and occassional was requiring resets, and has public IP mapped to name and number of ports routed to various machines behind it. Wanted to setup the new one with 2.4/5 setup and running before switching everything over. As you mentioned, incoming traffic on second interface was sending return traffic via first interface and thus http didn't work since it had the 100 metric. So, that machine I switched the connections to interfaces. Thanks. > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ++ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mi...@guam.net mailto:msetze...@gmail.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ ++ ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Looking to get connection between 2 local networks?
On 9 Nov at 16:43, Community support for Fedora users wrote: > Thanks for info. My older wifi router only 2.4 and occassional was > requiring resets, and has public IP mapped to name and number of ports > routed to various machines behind it. Wanted to setup the new one with > 2.4/5 setup and running before switching everything over. Hmm. If it's only temporary, you might save yourself heartache by doing a big-bang cutover in this case. > As you mentioned, incoming traffic on second interface > was sending return traffic via first interface and thus http > didn't work since it had the 100 metric. So, that machine > I switched the connections to interfaces. You could also have changed the metrics. Just a thought. Cheers, -- Dave Ihnat dih...@dminet.com ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Looking to get connection between 2 local networks?
On 9 Nov 2022 at 16:58, Dave Ihnat wrote: Date sent: Wed, 9 Nov 2022 16:58:08 -0600 From: Dave Ihnat To: mi...@guam.net, Community support for Fedora users Subject:Re: Looking to get connection between 2 local networks? Copies to: Louis Lagendijk Send reply to: Community support for Fedora users > On 9 Nov at 16:43, Community support for Fedora users > wrote: > > Thanks for info. My older wifi router only 2.4 and occassional was > > requiring resets, and has public IP mapped to name and number of ports > > routed to various machines behind it. Wanted to setup the new one with > > 2.4/5 setup and running before switching everything over. > > Hmm. If it's only temporary, you might save yourself heartache by doing a > big-bang cutover in this case. > > > As you mentioned, incoming traffic on second interface > > was sending return traffic via first interface and thus http > > didn't work since it had the 100 metric. So, that machine > > I switched the connections to interfaces. > > You could also have changed the metrics. Just a thought. What command would allow that? I looked, but didn't see option to set metric in edit connection? Know that one can setup to use multiple ISP. In this case that is not a point, since both links are same ISP. Have done a setup years ago with multiple ISPs tha would split traffic across multiple links, but that was long ago. Think it would look at load on each link, and opt how to send traffic. It would also handle if any link failed to move traffic to working ones. Thanks. > > Cheers, > -- > Dave Ihnat > dih...@dminet.com > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ++ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mi...@guam.net mailto:msetze...@gmail.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ ++ ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Moving to a new GPU
On 11/9/22 14:28, Patrick O'Callaghan wrote: On Wed, 2022-11-09 at 13:38 -0800, Samuel Sieb wrote: On 11/9/22 12:36, Felix Miata wrote: Patrick O'Callaghan composed on 2022-11-09 20:07 (UTC): $ inxi -GSaz System: Kernel: 6.0.5-200.fc36.x86_64 arch: x86_64 bits: 64 compiler: gcc v: 2.37-36.fc36 parameters: BOOT_IMAGE=(hd2,gpt2)/vmlinuz-6.0.5- 200.fc36.x86_64 root=UUID=8e1f7af4-c0bf-434e-b1c4-a9af2c810d56 ro rootflags=subvol=root modprobe.blacklist=nouveau rd.blacklist=nouveau Competent FOSS display drivers for NVidia GPUs require the KMS that those two =nouveau parameters disable. Purging those two from /etc/default/grub & grub.cfg followed by reboot should be all you need, but you can test by editing them away via the E key at the Grub menu. How are those parameters relevant to the current situation? I agree that they should be removed because they are no longer relevant, but they shouldn't be affecting anything. The new graphics is AMD. They may be relevant if they remove KMS, which apparently AMD requires. I've removed them in any case and rebooted, but it doesn't seem to make a lot of difference. KMS isn't really something you can remove, except maybe by recompiling the kernel. It's an interface that the various graphics drivers use. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
