Upgrade to leap 16 -- will mesa-dri-nouveau remain tabooed?

English Install/Boot/Login
1

I have mesa-dri-nouveau in"taboo" mode on leap 15.6. I am using nvidia proprietary drivers.

Am planning to upgrade to leap 16 using “zypper releasever=16 dup” or “migration-tool”. Will these methods “untaboo” mesa-dri-nouvea and have system using that driver. I’m aware that it is the default. Or will “taboo” remain in effect?

I wish to keep using proprietary drivers.

thanks, tom kosvic

2

@tckosvic just use nomodeset in the boot options after the upgrade if things go pear shaped, then sort it out.
I suspect it will remain locked.

I don’t even have it installed (or locked) With Nvidia and Intel for Prime Render Offload. I did the install on purpose with the Nvidia card as the default to see how it went, it went fine…

3

Please be careful, that will not work without extensive repo editing beforehand.
That is exactly why the “Migration Tool” was devised.

4

I am aware of needed repo adjustments to set up the upgrade. The root of my question here was focused on whether “nouveau” would remain locked or not.

I don’t want to do the online upgrade and have no graphics afterward.

thanks for the warning, tom kosvic

5

Just add rd.driver.blacklist=nouveau to the boot options and nomodeset

System:
  Kernel: 6.12.0-160000.9-default arch: x86_64 bits: 64 compiler: gcc
    v: 13.4.0 clocksource: tsc avail: acpi_pm
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.12.0-160000.9-default
    root=UUID=e2911003-8a7b-490a-89b4-de68d08f1200 intel_iommu=on
    mitigations=auto quiet security=selinux selinux=1 ia32_emulation=1
    rd.driver.blacklist=nouveau
  Desktop: GNOME v: 48.4 tk: GTK v: 3.24.50 wm: gnome-shell
    tools: gsd-screensaver-proxy dm: GDM v: 48.0 Distro: openSUSE Leap 16.0
Graphics:
  Device-1: Intel CoffeeLake-S GT2 [UHD Graphics 630] vendor: Dell
    driver: i915 v: kernel arch: Gen-9.5 process: Intel 14nm built: 2016-20
    ports: active: none empty: DP-1, DP-2, DP-3, HDMI-A-1, HDMI-A-2, HDMI-A-3
    bus-ID: 00:02.0 chip-ID: 8086:3e92 class-ID: 0380
  Device-2: NVIDIA TU117GLM [Quadro T400 Mobile] driver: nvidia
    v: 580.126.09 alternate: nouveau,nvidia_drm non-free: 550.xx+ status: current
    (as of 2024-09; EOL~2026-12-xx) arch: Turing code: TUxxx
    process: TSMC 12nm FF built: 2018-2022 pcie: gen: 1 speed: 2.5 GT/s
    lanes: 16 link-max: gen: 3 speed: 8 GT/s ports: active: DP-4
    empty: DP-5,DP-6 bus-ID: 01:00.0 chip-ID: 10de:1fb2 class-ID: 0300
  Display: wayland server: Xwayland v: 24.1.6 compositor: gnome-shell
    driver: N/A display-ID: 0
  Monitor-1: DP-4 res: 1920x1080 size: N/A modes: N/A
  API: EGL v: 1.5 hw: drv: intel iris drv: nvidia platforms: device: 0
    drv: nvidia device: 1 drv: iris gbm: drv: iris surfaceless: drv: nvidia
    wayland: drv: nvidia x11: drv: nvidia
  API: OpenGL v: 4.6.0 compat-v: 4.6 vendor: nvidia mesa v: 580.126.09
    glx-v: 1.4 direct-render: yes renderer: NVIDIA T400/PCIe/SSE2
    memory: 1.95 GiB display-ID: :0.0
  API: Vulkan v: 1.4.309 layers: 3 device: 0 type: discrete-gpu
    name: NVIDIA T400 driver: N/A device-ID: 10de:1fb2
    surfaces: xcb,xlib,wayland device: 1 type: integrated-gpu name: Intel UHD
    Graphics 630 (CFL GT2) driver: N/A device-ID: 8086:3e92
    surfaces: xcb,xlib,wayland
6

The question is more: why do you believe that a lock for this package is necessary?

When you install the Nvidia drivers, an automatic blacklisting of Nouveau is added to the kernel command line. If you remove the drivers, also the blacklist is removed.

There is absolutely no need for this package lock.

7

Hmmmm, I seem to recall that zypper kept trying to reinstall nouveau on normal updates even when I was running proprietary drivers. Thus, I tabooed it. That could have been a decade or so ago though.

I will un-taboo it for a test.

thanks, tom kosvic

8

It is completely normal that it get installed even when the Nvidia drivers are installed. The package is not used due to the blacklist on the kernel command line. There is simply no tinkering/tabooing needed.

9

IME, zypper locks survive zypper dups intact. In confirmation on Thursday, I used NET installation media, thus YaST, to upgrade a hopelessly broken 32bit TW, with locked kernel-de*, among other locks. The successful upgrade, as expected, did not install kernel-default-6.18.8 (or any other kernel-de*).

10

TW NET-isos are not a means for upgrading Leap 15.6 ⇒ 16.0, why is this here?

11
  1. I wouldn’t expect dup competence, a SUSE/openSUSE package management staple, to have become absent from Agama since the six times I used it to upgrade from 15.6 to 16.0.
  2. AFAICT, Taboo=zypper lock, no different in Leap from TW, the development platform from which SLE and thus Leap are derived.
  3. On an overall basis AFAICT, the Leap Agama installer doesn’t differ from the TW NET installer, both capable of distribution upgrade.
12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.