[Bug 1224773] New: Cannot install NVIDIA drivers in latest Aeon RC2
https://bugzilla.suse.com/show_bug.cgi?id=1224773 Bug ID: 1224773 Summary: Cannot install NVIDIA drivers in latest Aeon RC2 Classification: openSUSE Product: openSUSE Aeon Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation Assignee: rbrown@suse.com Reporter: sunscape1@hotmail.com QA Contact: qa-bugs@suse.de Target Milestone: --- Found By: --- Blocker: --- Installing NVIDIA drivers in Aeon RC2 (https://en.opensuse.org/SDB:NVIDIA_drivers) fails because the MOK cannot be enrolled after boot. Error during installation using pkg is: SKIP: /var/lib/nvidia-pubkeys/MOK-nvidia-driver-G06-550.78-22.1-default.der is not in MokList Without the nvidia-pubkeys folder it is impossible to enroll the MOK or try to enable it after reboot. The key doesn't exist :( -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c1 --- Comment #1 from Benjamin Sabatini <sunscape1@hotmail.com> --- Warning: The following files were changed in the snapshot, but are shadowed by other mounts and will not be visible to the system: /.snapshots/3/snapshot/var/lib/nvidia-pubkeys/MOK-nvidia-driver-G06-550.78-22.1-default.der --After the second attempt, having used the home backup option. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c2 Richard Brown <rbrown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|qa-bugs@suse.de |screening-team-bugs@suse.de Assignee|rbrown@suse.com |screening-team-bugs@suse.de Component|Installation |3rd party software Product|openSUSE Aeon |openSUSE.org Version|Current |unspecified --- Comment #2 from Richard Brown <rbrown@suse.com> --- Not an Aeon specific bug, nor a package in any Aeon-supported/maintained repo Looks to me that the packaging of the NVIDIA package is wrong /var/ should be avoided when packaging for any transactional distribution (ie Aeon, MicroOS, SLE Micro, etc) because the whole premise is that such systems don't change during runtime, whereas the whole premise of /var is for data that needs to change at runtime This is why transactonal-update doesn't mount var during the update, hence the observation in Comment #1 /usr/share/$FOO seems like a more natural and correct location for NVIDIA's public keys, as I assume they're not meant to change at runtime. Assigning to the appropriate category and a commnuity packager who may be willing to help -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 Richard Brown <rbrown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbrown@suse.com Assignee|screening-team-bugs@suse.de |sndirsch@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c6 --- Comment #6 from Benjamin Sabatini <sunscape1@hotmail.com> --- The 555 driver was released a few hours ago, so hopefully, the fix was in before. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c8 Imo Hester <vortex@z-ray.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vortex@z-ray.de --- Comment #8 from Imo Hester <vortex@z-ray.de> --- Created attachment 875233 --> https://bugzilla.suse.com/attachment.cgi?id=875233&action=edit Aeon RC2 systemd-boot log -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c9 Imo Hester <vortex@z-ray.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|RESOLVED |REOPENED --- Comment #9 from Imo Hester <vortex@z-ray.de> --- Hi there, I just updated an old MicroOS Desktop system to Aeon RC 2 using the Aeon Installer. Unfortunately I need to report that nVidia drivers still can't be installed on Aeon RC2.
Mai 31 07:32:47 localhost systemd-udevd[1106]: modprobe: ERROR: could not insert 'nvidia': Key was rejected by service
It seems it still can't import the MOK's for the nVidia driver. Looking up https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot Revealed: 1) The Wiki is outdated, as the MOKs has been moved to "/usr/share/nvidia-pubkeys" according to this ticket but 2) The directory "/usr/share/nvidia-pubkeys" does not exist on my system at all. Neither does the old "/var/lib/nvidia-pubkeys" I uploaded the full boot-log file of my current system. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c10 Imo Hester <vortex@z-ray.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|REOPENED |RESOLVED --- Comment #10 from Imo Hester <vortex@z-ray.de> --- Oh sorry I missed the last comment that the changes are available early June. My bad. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c11 Imo Hester <vortex@z-ray.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #11 from Imo Hester <vortex@z-ray.de> --- I think there is another issues with the driver. After disabling secure boot in my system the nvidia driver still does not get loaded because of nouveau it seems:
Mai 31 07:55:03 localhost kernel: NVRM: GPU 0000:01:00.0 is already bound to nouveau.
After manually running:
sudo transactional-update initrd sudo reboot
It still seems not to pickup the file "/usr/lib/modprobe.d/nvidia-default.conf" Which states:
blacklist nouveau
I'll attach a 2nd boot log -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c12 --- Comment #12 from Imo Hester <vortex@z-ray.de> --- Created attachment 875234 --> https://bugzilla.suse.com/attachment.cgi?id=875234&action=edit Aeon RC2 boot log with out secure boot enabled -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c13 --- Comment #13 from Imo Hester <vortex@z-ray.de> --- Created attachment 875235 --> https://bugzilla.suse.com/attachment.cgi?id=875235&action=edit transactional update initrd log file -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c24 --- Comment #24 from Imo Hester <vortex@z-ray.de> --- Hey everyone after a bit of digging and tons or rebooting I found the issue(s) 1) The initrd file is being generated to the wrong location. Running "sudo transactional-update initrd" will generate the initrd file to: /boot/initrd-<current-kernel-version> 2) The systemd-boot entry of the actual snapshot which is to be booted is not being updated as it uses the any initrd file located at: /boot/efi/opensuse-aeon/6.9.1-1-default/
vortexacherontic@linux:/boot/efi/opensuse-aeon/6.9.1-1-default> ll total 277568 -rwxr-xr-x. 1 root root 178947935 Mai 25 10:22 initrd-4c6dba516f5f3d230a1f5f1e144106e46c960602 -rwxr-xr-x. 1 root root 90530598 Jun 2 07:58 initrd-6.9.1-1-default <<<<< Manually moved this here -rwxr-xr-x. 1 root root 14641520 Mai 17 13:59 linux-6b13316fa0178df1fd6898c8f96f96ab9ecbbbe1
As you can see the initrd file generated this morning is also there because I manually moved it there and edited the systemd-boot entry of the current snapshot: Original file: # Boot Loader Specification type#1 entry title openSUSE Aeon 20240524 version 36@6.9.1-1-default sort-key opensuse-aeon options quiet loglevel=2 systemd.show_status=no console=ttyS0,115200 console=tty0 vt.global_cursor_default=0 ignition.platform.id=metal security=selinux selinux=1 root=UUID=42fc02eb-e038-424f-b5a5-aed45173338d rootflags=subvol=@/.snapshots/36/snapshot systemd.machine_id=7b5e214ac1c6413b9145cd262341e2fe linux /opensuse-aeon/6.9.1-1-default/linux-6b13316fa0178df1fd6898c8f96f96ab9ecbbbe1 initrd /opensuse-aeon/6.9.1-1-default/initrd-4c6dba516f5f3d230a1f5f1e144106e46c960602 Modifieed file: # Boot Loader Specification type#1 entry title openSUSE Aeon 20240524 version 36@6.9.1-1-default sort-key opensuse-aeon options quiet loglevel=2 systemd.show_status=no console=ttyS0,115200 console=tty0 vt.global_cursor_default=0 ignition.platform.id=metal security=selinux selinux=1 root=UUID=42fc02eb-e038-424f-b5a5-aed45173338d rootflags=subvol=@/.snapshots/36/snapshot systemd.machine_id=7b5e214ac1c6413b9145cd262341e2fe linux /opensuse-aeon/6.9.1-1-default/linux-6b13316fa0178df1fd6898c8f96f96ab9ecbbbe1 initrd /opensuse-aeon/6.9.1-1-default/initrd-6.9.1-1-default The entry still point's to the very first initrd as generated upon installing the system. Also I do expect the next update to reset the entry. But as of writing these lines I have the nvidia driver loaded and nouveau is no where near to be found. It seems to be a transactional-update issue I believe and they have to update/patch this? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c26 --- Comment #26 from Imo Hester <vortex@z-ray.de> --- (In reply to Stefan Dirsch from comment #25)
Thanks for figuring this out, Imo! So it seems
transactional-update initrd
doesn't work in a consistent way, at least not together with systemd-boot. Ignaz will look into this.
I'm wondering if we're seing two separate issues here. Could you check once more by re-installing the KMP if transactional-update initrd is being running during that installation (it should!)? I need to know if the initrd is just being installed to the wrong location or systemd-boot configuration not adjusted correctly respectively. Or if no initrd is being re-created at all during KMP installation.
Hey there. I am not entirely sure how to test this so here is what I did: 1) sudo transactional-update pkg rm nvidia-driver-G06-kmp-default (This removed also *-compute-G06, *-video-G06, *-util-G06, *-gl-G06 2) sudo reboot 3) sudo transactional-update pkg in nvidia-driver-G06-kmp-default 4) sudo reboot 5) cd /boot 6) ll
total 88476 drwxr-xr-x. 5 root root 65536 Jan 1 1970 efi -rw-------. 1 root root 90530598 Jun 2 07:53 initrd-6.9.1-1-default
As you can see the initrd-6.9.1-1-default is still the one from yesterday which I manually generated using transactional-update initrd Also 7) cd /boot/efi/opensuse-aeon/6.9.1-1-default 8) ll
total 277568 -rwxr-xr-x. 1 root root 178947935 Mai 25 10:22 initrd-4c6dba516f5f3d230a1f5f1e144106e46c960602 -rwxr-xr-x. 1 root root 90530598 Jun 2 07:58 initrd-6.9.1-1-default -rwxr-xr-x. 1 root root 14641520 Mai 17 13:59 linux-6b13316fa0178df1fd6898c8f96f96ab9ecbbbe1
does not reveal any new initramfs files. I suppose transactional-update initrd is not being executed or the initramfs is stored to an entirely different location I did not yet found. Does this help? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c27 --- Comment #27 from Imo Hester <vortex@z-ray.de> --- Another thing I noticed is, that systemd-boot took over my initramfs modification to the boot loader entry I did a few snapshots ago. Therefore I expect the next Kernel update to break the system or at least the boot process and (hopefully) Aeon will rollback to the previous snapshot. I attached an archive with the entries for snapshot 34 - 39. As you can see 34 and 35 are still lisitng initrd-4c6dba516f5f3d230a1f5f1e144106e46c960602 as theri initramfs while every entry after 35 (thus 36, 37, 38, 39) all list initrd-6.9.1-1-default. Which is the one I manually moved there and initially modified the entrie 36 to use this. This changes seems to have been carried over to every following entry. Therefore I expect a new Kernel or driver update to break the system. Unless I re-generated a initramfs manually and fix the boot entry before rebooting -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c28 --- Comment #28 from Imo Hester <vortex@z-ray.de> --- Created attachment 875264 --> https://bugzilla.suse.com/attachment.cgi?id=875264&action=edit SystemD Boot entries 34 till 39 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c30 --- Comment #30 from Imo Hester <vortex@z-ray.de> --- While I must say the first one surprises me as with Aeon RC 1 I had no issues with the drivers or had to manually trigger transactional-update initrd after the installation. At least not that I remember. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c36 --- Comment #36 from Imo Hester <vortex@z-ray.de> --- Just want to add some details: Unlike anticipated I did not require to re-fix the driver as I updated from Kernel 6.9.1 to 6.9.3. Somehow the kernel update itself or systemd-boot build a new initramfs for 6.9.3 AND the modprobe rules where included as well as put into the right location:
cd /boot/efi/opensuse-aeon/6.9.3-1-default/ ll -rwxr-xr-x. 1 root root 95383117 5. Jun 19:49 initrd-56b6a5223453a59edeb15854dc0ed58154332456 -rwxr-xr-x. 1 root root 14625136 30. Mai 10:00 linux-58d6d3c7cc8c858e239a8137fe4faa5b2fea52bf
vim /boot/efi/loader/entries/opensuse-aeon-6.9.3-1-default-50.conf # Boot Loader Specification type#1 entry title openSUSE Aeon 20240531 version 50@6.9.3-1-default sort-key opensuse-aeon options quiet loglevel=2 systemd.show_status=no console=ttyS0,115200 console=tty0 vt.global_cursor_default=0 ignition.platform.id=metal security=selinux selinux=1 root=UUID=42fc02eb-e038-424f-b5a5-aed45173338d rootflags=subvol=@/.snapshots/50/snapshot systemd.machine_id=7b5e214ac1c6413b9145cd262341e2fe linux /opensuse-aeon/6.9.3-1-default/linux-58d6d3c7cc8c858e239a8137fe4faa5b2fea52bf initrd /opensuse-aeon/6.9.3-1-default/initrd-56b6a5223453a59edeb15854dc0ed58154332456
So it seems at least updating just the kernel seem not to break things after the initial fix. A new initramfs is somehow generated correctly and picks up the additional modprode confs. I'll keep this thread updated as soon as driver 550.90.07 lands in the repos and get's updated. Probably that will require the re-fix as required initially as it might be a similar situation as like on a new system with a newly installed driver package. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 Ken Rice <krinpaus@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |krinpaus@gmail.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c49 Jonathon Duvall <elvish.legion@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |elvish.legion@gmail.com --- Comment #49 from Jonathon Duvall <elvish.legion@gmail.com> --- I just tested on Aeon's RC3 and still had to manually configure initrd and manually point to it for systemd boot to properly load the drivers. Prior to this manual process nvidia-smi would report the driver as not connected. I am not sure what logs or information I can provide to help aid in this. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c50 --- Comment #50 from Imo Hester <vortex@z-ray.de> --- I can confirm as well (Aeon RC2) without manual intervention it is still not working. Part of the reason is that the boot entry still uses the wrong initrd file. While something has changed we're not quite there as it seems: First a new initrd file gets now generated automatically and put into the right place:
ll /boot/efi/opensuse-aeon/6.9.9-1-default -rwxr-xr-x. 1 root root 85487083 20. Jul 20:02 initrd-0fe5bd25b3a5d3d94d6ca2c9dfa99608939d9ef7 -rwxr-xr-x. 1 root root 85521828 26. Jul 12:36 initrd-1df97a9ad45e70c894f405cf1a46869045ce64f0 -rwxr-xr-x. 1 root root 85655672 30. Jul 09:07 initrd-82e2dc492931967db49ba2a4cffc6eee4ce1293d -rwxr-xr-x. 1 root root 14633328 11. Jul 13:31 linux-02693107eb256a62b3c42ecebad7ad5607cebb48
The initrd file from 30rd Jul (today) is the one which was automatically generated. However it did not become the initrd of the boot entry:
vim /boot/efi/loader/entries/opensuse-aeon-6.9.9-1-default-30.conf # Boot Loader Specification type#1 entry title openSUSE Aeon 20240726 version 30@6.9.9-1-default sort-key opensuse-aeon options quiet loglevel=2 systemd.show_status=no console=ttyS0,115200 console=tty0 vt.global_cursor_default=0 ignition.platform.id=metal security=selinux selinux=1 root=UUID=42fc02eb-e038-424f-b5a5-aed45173338d rootflags=subvol=@/.snapshots/30/snapshot systemd.machine_id=09f6061f16784d3288fa56271c151e56 linux /opensuse-aeon/6.9.9-1-default/linux-02693107eb256a62b3c42ecebad7ad5607cebb48 initrd /opensuse-aeon/6.9.9-1-default/initrd-0fe5bd25b3a5d3d94d6ca2c9dfa99608939d9ef7
sudo transactional-update initrd Which suprisingly still generates the initrd to /boot/ and not as the automatic
As you can see the latest entry (30 in my case) is still refering to the initrd from 20 Jul 20:02 while it should at least list initrd-82e2dc492931967db49ba2a4cffc6eee4ce1293d. However even if it would it is an incomplete initrd file which somehow still misses the driver modules and the blacklist. Therefore manually running: process to /boot/efi/opensuse-aeon/KERNEL_VERION-default. To sum this up, the steps to fix this are still the same but now you get an extra initrd file with it :D Kind regards, Imo. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c53 --- Comment #53 from Imo Hester <vortex@z-ray.de> --- (In reply to Alberto Planas Dominguez from comment #51)
(In reply to Imo Hester from comment #50)
The initrd file from 30rd Jul (today) is the one which was automatically generated. However it did not become the initrd of the boot entry:
This is very interesting, as the command that generates the initrd is the same that creates the entry.
What steps did you used to trigger this bug?
For example, when I update the kernel or install a new dracut module I can see the new initrd and the new entry for the new snapshot, pointing to the correct initrd.
How can I replicate this?
Hm, maybe it was that I installed the G05 drivers on an Optimus System featuring a GT 730M without any proprietary driver installed prior to test this from a clean install. Will counter test this with G06 on a supported system. -- You are receiving this mail because: You are on the CC list for the bug.
sudo transactional-update dup
The following 62 packages are going to be upgraded: Aeon-release Aeon-release-appliance NetworkManager NetworkManager-bluetooth NetworkManager-branding-openSUSE NetworkManager-wwan btrfsprogs btrfsprogs-udev-rules coreutils coreutils-systemd cryptsetup gdm gdm-schema gdmflexiserver gnome-control-center gnome-control-center-color gnome-control-center-goa gnome-control-center-user-faces gnome-control-center-users gtk4-branding-openSUSE gtk4-schema gtk4-tools health-checker health-checker-plugins-MicroOS libX11-6 libX11-data libX11-xcb1
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c55 Imo Hester <vortex@z-ray.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(vortex@z-ray.de) | --- Comment #55 from Imo Hester <vortex@z-ray.de> --- Just migraded my G06 compatible system from RC2 to RC3 which involves a re-install of the entire system and thus gives a clean unmodified state to test this issue: Things got even worse... libbtrfs0 libbtrfsutil1 libcryptsetup12 libgdm1 libgtk-4-1 libldap2 libnm0 libp11-kit0 libpython3_11-1_0 libvte-2_91-0 libzypp mutter p11-kit p11-kit-tools patterns-aeon-base perl-Bootloader python311 python311-base python311-cryptography python311-pycairo samba samba-ad-dc-libs samba-client samba-client-libs samba-libs selinux-policy selinux-policy-targeted systemd-presets-branding-Aeon sysuser-shadow typelib-1_0-Gdm-1_0 typelib-1_0-Gtk-4_0 typelib-1_0-NM-1_0 vim-data-common vim-small x86_64_v3-branding-Aeon
sudo reboot
sudo transactional-update pkg in openSUSE-repos-MicroOS-NVIDIA
sudo reboot
After this the system was stuck in a boot loop or bnetter said the helthchecker thingks the system did not bootet right:
Aug 04 15:03:00 localhost.localdomain systemd-logind[1231]: New session 1 of user gdm. Aug 04 15:03:00 localhost.localdomain (systemd)[1539]: pam_unix(systemd-user:session): session opened for user gdm(uid=467) by gdm(uid=0) Aug 04 15:03:00 localhost.localdomain root[1543]: ERROR: "/usr/libexec/health-checker/rpmdb-consistency.sh check" failed Aug 04 15:03:00 localhost.localdomain health-checker[1543]: <10>Aug 4 15:03:00 root: ERROR: "/usr/libexec/health-checker/rpmdb-consistency.sh check" failed Aug 04 15:03:00 localhost.localdomain health-checker[1364]: Health check failed! Aug 04 15:03:00 localhost.localdomain root[1560]: Machine didn't come up correctly, trying rebooting into default snapshot Aug 04 15:03:00 localhost.localdomain health-checker[1560]: <9>Aug 4 15:03:00 root: Machine didn't come up correctly, trying rebooting into default snapshot Aug 04 15:03:00 localhost.localdomain systemd-logind[1231]: The system will reboot now! Aug 04 15:03:00 localhost.localdomain systemd-logind[1231]: System is rebooting. Aug 04 15:03:00 localhost.localdomain gdm-launch-environment][1524]: pam_systemd(gdm-launch-environment:session): Failed to create session: Job 1577 for unit 'session-c1.scope' failed with 'canceled' Aug 04 15:03:00 localhost.localdomain systemd[1]: health-checker.service: Main process exited, code=exited, status=1/FAILURE Aug 04 15:03:00 localhost.localdomain systemd[1]: health-checker.service: Failed with result 'exit-code'. Aug 04 15:03:00 localhost.localdomain systemd[1]: Stopped MicroOS Health Checker. Aug 04 15:03:00 localhost.localdomain systemd[1]: Removed slice Slice /system/modprobe.
I attached the full boot log. Until I found a solution for this issue I am not going to be able to test this situation any further. :/ -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c56 --- Comment #56 from Imo Hester <vortex@z-ray.de> --- Created attachment 876470 --> https://bugzilla.suse.com/attachment.cgi?id=876470&action=edit Boot Loop after adding MicroOS nVidia repo package -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c57 --- Comment #57 from Imo Hester <vortex@z-ray.de> --- Edit: Also I like to note that there seems to be a bug in nouveau too. Because if I have any displays connected to the nvidia GPU the desktop randomly freezes after a few minutes. If I attach my display directly to my integrated AMD GPU (thankfully this desktop CPU has one) I can operate the system properly. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c58 --- Comment #58 from Imo Hester <vortex@z-ray.de> --- Okay found the issue to the boot loop. The repo key get's not accepted automatically and there is no way for the user to accept this unless you run another TU command with the -c option so you get into an interactive mode to accept the key. Continue: (All steps included)
sudo transactional-update dup
The following 62 packages are going to be upgraded: Aeon-release Aeon-release-appliance NetworkManager NetworkManager-bluetooth NetworkManager-branding-openSUSE NetworkManager-wwan btrfsprogs btrfsprogs-udev-rules coreutils coreutils-systemd cryptsetup gdm gdm-schema gdmflexiserver gnome-control-center gnome-control-center-color gnome-control-center-goa gnome-control-center-user-faces gnome-control-center-users gtk4-branding-openSUSE gtk4-schema gtk4-tools health-checker health-checker-plugins-MicroOS libX11-6 libX11-data libX11-xcb1 libbtrfs0 libbtrfsutil1 libcryptsetup12 libgdm1 libgtk-4-1 libldap2 libnm0 libp11-kit0 libpython3_11-1_0 libvte-2_91-0 libzypp mutter p11-kit p11-kit-tools patterns-aeon-base perl-Bootloader python311 python311-base python311-cryptography python311-pycairo samba samba-ad-dc-libs samba-client samba-client-libs samba-libs selinux-policy selinux-policy-targeted systemd-presets-branding-Aeon sysuser-shadow typelib-1_0-Gdm-1_0 typelib-1_0-Gtk-4_0 typelib-1_0-NM-1_0 vim-data-common vim-small x86_64_v3-branding-Aeon
sudo reboot
sudo transactional-update pkg in openSUSE-repos-MicroOS-NVIDIA sudo transactional-update -c pkg in nvidia-drivers-G06
Accepted repo key sudo vim /etc/zypp/zypper.conf - # autoAgreeWithLicenses = no + autoAgreeWithLicenses = yes ESC + :x
sudo reboot
nvidia-smi NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.
No driver without intervention it seems. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c59 --- Comment #59 from Imo Hester <vortex@z-ray.de> --- Sorry for the third comment. These steps here include the inspection of the driver situation after installing everthigns as described before. There fore after migrating RC2 to RC3 (eg clean install) making one tu dup and adding the driver repo as well as the driver package:
ll /boot/efi/opensuse-aeon/6.10.2-1-default -rwxr-xr-x. 1 root root 116592503 4. Aug 12:34 initrd-7bf5b5fcae77501847811e3a432233ec3211b6b6 -rwxr-xr-x. 1 root root 99049249 4. Aug 14:45 initrd-e1249e1e31f744bba1e54eaf85488ac211ea5fba -rwxr-xr-x. 1 root root 14768496 29. Jul 10:51 linux-2c329eaa923faa1adec30975f32f6b98bb77d87c This reveals 2 initrd files. One from 12:34 from the installation of RC3 and one from 14:45 after adding the nvidia driver.
Currently I have 6 snapshots:
sudo snapper list # │ Typ │ Vorher # │ Datum │ Benutzer │ Verwendeter Platz │ Bereinigen │ Beschreibung │ Imo's Comments ───┼────────┼──────────┼──────────────────────────────┼──────────┼───────────────────┼────────────┼───────────────────────┼────────────── 0 │ single │ │ │ root │ │ │ current │ 1 │ single │ │ Di 30 Jul 2024 12:49:45 CEST │ root │ 6,05 MiB │ │ first root filesystem │ 2 │ single │ │ So 04 Aug 2024 14:43:18 CEST │ root │ 288,00 KiB │ │ Snapshot Update of #1 │ produces by: aeon-first-run 3 │ single │ │ So 04 Aug 2024 14:45:05 CEST │ root │ 3,29 MiB │ number │ Snapshot Update of #2 │ produced by: tu dup 4 │ single │ │ So 04 Aug 2024 14:49:31 CEST │ root │ 3,41 MiB │ number │ Snapshot Update of #3 │ IGNORE: Boot loop Snapshot 5 │ single │ │ So 04 Aug 2024 15:12:00 CEST │ root │ 600,00 KiB │ number │ Snapshot Update of #2 │ produced by: tu pkg in openSUSE-repos-MicroOS-NVIDIA 6* │ single │ │ So 04 Aug 2024 15:12:25 CEST │ root │ 614,75 MiB │ number │ Snapshot Update of #5 │ produced by: tu -c pkg in in nvidia-drivers-G06
Therefore the boot entry of the latest snapshot 6 looks like:
vim /boot/efi/loader/entries/opensuse-aeon-6.10.2-1-default-6.conf # Boot Loader Specification type#1 entry title openSUSE Aeon 20240730 version 6@6.10.2-1-default sort-key opensuse-aeon options quiet loglevel=2 systemd.show_status=no console=ttyS0,115200 console=tty0 vt.global_cursor_default=0 ignition.platform.id=metal security=selinux selinux=1 root=UUID=ad82e6ac-d651-4b6f-9ff7-3d1806934acc rootflags=subvol=@/.snapshots/6/snapshot systemd.machine_id=69299731df054911a3ff0d640ef9d14b linux /opensuse-aeon/6.10.2-1-default/linux-2c329eaa923faa1adec30975f32f6b98bb77d87c initrd /opensuse-aeon/6.10.2-1-default/initrd-e1249e1e31f744bba1e54eaf85488ac211ea5fba
As we see it includes the latest initrd as seen above but apparently it does lack the nvidia driver and looking at the boot log of the current system it is also still using nouveaou. Therefore the blacklist isn't used either:
Aug 04 15:16:45 localhost kernel: nouveau 0000:01:00.0: NVIDIA GA102 (b72000a1) Aug 04 15:16:46 localhost kernel: nouveau 0000:01:00.0: bios: version 94.02.71.40.6c Aug 04 15:16:46 localhost kernel: nouveau 0000:01:00.0: bios: M0203E type 0a Aug 04 15:16:46 localhost kernel: nouveau 0000:01:00.0: fb: 10240 MiB of unknown memory type Aug 04 15:16:46 localhost kernel: nouveau 0000:01:00.0: DRM: VRAM: 10240 MiB Aug 04 15:16:46 localhost kernel: nouveau 0000:01:00.0: DRM: GART: 536870912 MiB Aug 04 15:16:46 localhost kernel: nouveau 0000:01:00.0: DRM: BIT table 'A' not found Aug 04 15:16:46 localhost kernel: nouveau 0000:01:00.0: DRM: BIT table 'L' not found Aug 04 15:16:46 localhost kernel: nouveau 0000:01:00.0: DRM: TMDS table version 2.0 Aug 04 15:16:46 localhost kernel: nouveau 0000:01:00.0: DRM: MM: using COPY for buffer copies Aug 04 15:16:46 localhost kernel: [drm] Initialized nouveau 1.4.0 20120801 for 0000:01:00.0 on minor 1 Aug 04 15:16:46 localhost kernel: nouveau 0000:01:00.0: [drm] Cannot find any crtc or sizes Aug 04 15:16:46 localhost kernel: nouveau 0000:01:00.0: [drm] Cannot find any crtc or sizes Aug 04 15:16:46 localhost kernel: nouveau 0000:01:00.0: [drm] Cannot find any crtc or sizes
Therefore doing the manual fix is still required eg: Generating an initrd manually using tu initrd, moving it to /boot/efi/opensuse-aeon/KERNEL_VERSION and then edit the latest boot entry to use the correct initrd. This is as detailes as I can get because there is nothing else I did so far. I hope this helps in any way :/ -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c60 --- Comment #60 from Imo Hester <vortex@z-ray.de> --- Sorry, 4th comment... I just noticed something regarding the date of the initrd files and the snapper list. The snapshot which has the driver is from 15:12:25 while the latest initrd is from 14:45. Which makes me suspect the driver package does not trigger a rebuild of the initrd. Actually it seems to be generated by my tu dup prior to adding the repo. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c61 --- Comment #61 from Imo Hester <vortex@z-ray.de> --- With RC3 another issue just turned up with the FDE (full disk encryption) using TPM2. As soon as manually trying to fix the driver by generating the initrd moving it to the right location, fixing the boot entry of the latest snapshot the following happens: The user gets asked (twice? or I misspelled it) for the recovery key. Then it appears nothing happens and then suddenly there are tons of timeout messages from dracut, the system resets after a while and the user is again asked for the recovery key. I think something else is broken too. I attached an image of the what appears on the screen. As of now it seems RC3 is completely broken with nvidia drivers and there seems no way to recover from this manually. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c62 --- Comment #62 from Imo Hester <vortex@z-ray.de> --- Created attachment 876471 --> https://bugzilla.suse.com/attachment.cgi?id=876471&action=edit dracut timeout -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c63 --- Comment #63 from Imo Hester <vortex@z-ray.de> --- Woop woop working nvidia drivers on rc3:
nvidia-smi Sun Aug 4 23:56:15 2024 +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 550.100 Driver Version: 550.100 CUDA Version: 12.4 | |-----------------------------------------+------------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 NVIDIA GeForce RTX 3080 Off | 00000000:01:00.0 Off | N/A | | 0% 54C P8 15W / 320W | 7MiB / 10240MiB | 0% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+
+-----------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=========================================================================================| | 0 N/A N/A 3924 G /usr/bin/gnome-shell 3MiB | +-----------------------------------------------------------------------------------------+
cat /etc/os-release NAME="openSUSE Aeon" # VERSION="20240730" ID="opensuse-aeon" ID_LIKE="suse opensuse opensuse-tumbleweed opensuse-microos microos" VERSION_ID="20240730" PRETTY_NAME="openSUSE Aeon" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:aeon:20240730" BUG_REPORT_URL="https://bugzilla.opensuse.org" SUPPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.aeondesktop.org/" DOCUMENTATION_URL="https://en.opensuse.org/Portal:Aeon" LOGO="distributor-logo-Aeon"
What did I do? Well ignroe the post iwth the dracut timeout ... RC3 does not apply the correct keyboard layout during the stage whare the user has to input the recovery key. Thus I typed the character "-" as "/" ... Therefore after manually moving the inird to the right location, editing the latest boot entry you get promed with the recovery key on the next boot. Enter the recovery key correctly and then things will start working. Will report this issue to Richard then as this is a huge issue if someone has to input the recovery key. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c65 --- Comment #65 from Imo Hester <vortex@z-ray.de> --- I re-tested the driver installation on another fresh Aeon RC3 install with similar results. The sole issue the 2nd system did not ran into is the TPM issue as the system has no TPM chip and thus uses the fallback mode and is asking for a password to unlock the system on every boot anyway. To summarize the issues observed so far: 1) Installing the driver repository and then immediately reboot will result in a boot loop as the repository key does not get automatically accepted. The Aeon healthchecker will notice an issue and then reboot the system without rolling back. Therefore the "broken" snapshot is booted again and the situation repeats. To circumvent this issue the user has to run any transactional-update packaging command using -c to get into a interactive mode based on the latest unbooted snapshot to (always) trust the repository key. 2) Installing the actual driver package itself does not seem to trigger a rebuild of the initrd file. The user has to do this manually, move the initrd file from /boot/ to the correct location and edit the latest boot entry to use the newly created initrd file. 3) Installing the driver package will break the automatic decryption of the root file system as the TPM predictions have changed. Which is to be expected as the initrd file was altered. Therefore the TPM chip refuses to unlock the system and asks for the recovery key. The user has to input this key on every boot. Also updating the TPM predictions manually does not work either see: boo#1228859. For the 3rd issue I did not yet found a manual solution. All 3 issues apply at least for the G06 and G05 driver package at least for me. For more detailed step by step descriptions feel free to checkout my previous replies. Kind regards, Imo -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c69 --- Comment #69 from Imo Hester <vortex@z-ray.de> ---
Sorry for my ignorance. If the package is installed you need first to accept the key, right? Is the NVIDIA package different?
The issue was the repo key not getting accepted nor was the user ask about it. I made the mistake and installed the driver repo and immediately rebooted the system. Which then caused the health checker to freak out about it and reboot but not rolling back and thus rebooted to the snapshot with the new repo but the unaccepted key. Freak out. Reboot but not rollback. Freak out. Reboot but not rollback and so on. Only option was to boot an earlier snapshot from the bootmanager to get out of the loop. The actual fix was to run:
sudo transactional-update pkg in openSUSE-repos-MicroOS-NVIDIA sudo transactional-update -c pkg in nvidia-drivers-G06
During the 2nd tu command I then got ask whether to accept the key or not. I set it to always accept and then continued with the driver installation. I did not try the first tu command with -i thought. But also the 2nd tu command asked me about the key without -i. After the repo and driver was installed the issue with the initrd file occurred. Until now I didn't knew about "sdbootutil mkinitrd" and didn't try. I used:
sudo transactional-update -c initrd
The full procedure was:
sudo transactional-update pkg in openSUSE-repos-MicroOS-NVIDIA sudo transactional-update -c pkg in nvidia-drivers-G06 sudo transactional-update -c initrd sudo transactional-update -c run mv /boot/initrd-KERNEL-VERSION /boot/efi/opensuse-aeon/KERNEL-VERION/ sudo vim /boot/efi/loader/entries/opensuse-aeon-KERNEL_VERION-LATEST-SNAPSHOT.conf Replace initrd with the new one copied earlier sudo reboot
About the TPM I tried the following to solve the issue:
sudo sdbootutil update-predictions Which didn't helped then I tried:
sudo sdbootutil --ask-pin update-predictions With the same result. Then I cleared the TPM entirely from within my BIOS then rebooted, entered the recovery key and tried to update the predictions again to no avail.
I did not tried and didn't knew about:
sdbootutil unenroll --method=tpm2 sdbootutil enroll --method=tpm2
Was about to re-try the procedure on my Laptop just today as my main system currently runs Kalpa until this issue is fixed. But I have to re-install the system for other reasons rn. Unfortunately my Laptop has no TPM chip so I can only test the driver installation but not the TPM stuff with it. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c72 --- Comment #72 from Imo Hester <vortex@z-ray.de> ---
What error did you have?
The error was:
sudo sdbootutil --ask-pin update-predictions
Recovery PIN: WARNING:esys:src/tss2-esys/api/Esys_NV_Write.c:310:Esys_NV_Write_Finish() Received TPM Error ERROR:esys:src/tss2-esys/api/Esys_NV_Write.c:110:Esys_NV_Write() Esys Finish ErrorCode (0x0000099d) Failed to write to NV index: State not recoverable Error creating the policy! Provided PIN incorrect or TPM2 locked after too many retries NVIndex policy created -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c73 --- Comment #73 from OBSbugzilla Bot <bwiedemann+obsbugzillabot@suse.com> --- This is an autogenerated message for OBS integration: This bug (1224773) was mentioned in https://build.opensuse.org/request/show/1197870 Factory / suse-module-tools -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c75 --- Comment #75 from Imo Hester <vortex@z-ray.de> --- (In reply to Alberto Planas Dominguez from comment #74)
Changes for sdbootutil and suse-module-tools are already released. Once published maybe you can try, Imo?
Hello everyone, finally got to re-test the whole thing but it seems things are not quite functioning yet. It improved no doubt. I did a fresh Aeon RC3 install to avoid any previous modifications to interfere.
sudo transactional-update pkg in openSUSE-repos-MicroOS-NVIDIA sudo transactional-update -c pkg in nvidia-drivers-G06 sudo reboot
After the reboot I ran nvidia-smi in terminal:
nvidia-smi NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.
Doing the usual inspections now:
sudo snapper list # | Type | Pre # | Date | User | Used Space | Cleanup | Description | Userdata | Imo's comment ---+--------+-------+--------------------------+------+------------+---------+-----------------------+----------+---------------- 0 | single | | | root | | | current | | 1 | single | | Fri Sep 13 20:26:31 2024 | root | 7.70 MiB | | first root filesystem | | 2 | single | | Mon Sep 16 10:17:47 2024 | root | 256.00 KiB | number | Snapshot Update of #1 | | Aeon first run 3 | single | | Mon Sep 16 10:42:18 2024 | root | 564.00 KiB | number | Snapshot Update of #2 | | nvidia driver repo 4* | single | | Mon Sep 16 10:43:21 2024 | root | 618.93 MiB | number | Snapshot Update of #3 | | nvidia driver package
ll /boot/efi/aeon/6.10.9-1-default/ total 408576 -rwxr-xr-x. 1 root root 97582950 Sep 16 10:45 initrd-1602c4dff5c2a8813d608f777ed5171bc121619c -rwxr-xr-x. 1 root root 117032724 Sep 16 2024 initrd-28370856245476c6e7f576440405197f050912ec -rwxr-xr-x. 1 root root 91277584 Sep 16 10:30 initrd-6038b475126dba875a4d87ed64dc5933b7ac8e95 -rwxr-xr-x. 1 root root 97543064 Sep 16 10:32 initrd-f3a34080b192912d16d946e7446be5439c2ccbdb -rwxr-xr-x. 1 root root 14887280 Sep 8 15:36 linux-7afb7207baeb9be7786bdc54e7a622d60fe39f0e
vim /boot/efi/loader/entries/aeon-6.10.9-1-default-4.conf # Boot Loader Specification type#1 entry title Aeon 20240913 version 4@6.10.9-1-default sort-key aeon options quiet loglevel=2 systemd.show_status=no console=ttyS0,115200 console=tty0 vt.global_cursor_default=0 ignition.platform.id=metal security=selinux selinux=1 root=UUID=2a091829-684d-42be-a83e-3f76020430c2 rootflags=subvol=@/.snapshots/4/snapshot systemd.machine_id=7cfb97ba64864c2a87d046da4fe1dc69 linux /aeon/6.10.9-1-default/linux-7afb7207baeb9be7786bdc54e7a622d60fe39f0e initrd /aeon/6.10.9-1-default/initrd-1602c4dff5c2a8813d608f777ed5171bc121619c
There seems to be a new initrd which matches the date and time of the driver installation (snapshot 4) which is also used in the latest boot entry but for some reason it seems not to contain the nvidia driver modules but nouveau seems to be black listed now.
sudo lsmod | grep -E 'nvidia|nouveau'
Returns nothing which makes me suspect nouveau is not loaded but nvidia or nvidia-drm is not as well. Thankfully I have an AMD iGPU :D A quick check at the package versions:
zypper se --installed-only -s sdbootutil suse-module-tools S | Name | Type | Version | Arch | Repository ---+------------------------------+---------+---------------------------+--------+----------- i | sdbootutil | package | 1+git20240903.81f1f40-1.1 | x86_64 | repo-oss i | sdbootutil-snapper | package | 1+git20240903.81f1f40-1.1 | x86_64 | repo-oss i | sdbootutil-tukit | package | 1+git20240903.81f1f40-1.1 | x86_64 | repo-oss i | suse-module-tools | package | 16.0.51-1.1 | x86_64 | repo-oss i | suse-module-tools-scriptlets | package | 16.0.51-1.1 | x86_64 | repo-oss
I hope these are the latest versions. at least transactional-update dup didn't generated a new snapshot as I tired post install. Kind regards, Imo -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c77 --- Comment #77 from Imo Hester <vortex@z-ray.de> --- (In reply to Alberto Planas Dominguez from comment #76)
(In reply to Imo Hester from comment #75)
There seems to be a new initrd which matches the date and time of the driver installation (snapshot 4) which is also used in the latest boot entry but for some reason it seems not to contain the nvidia driver modules but nouveau seems to be black listed now.
If you generate the initrd manually, do you less the modules included?
dracut --reproducible --force /tmp/initrd-0 6.10.9-1-default
you can use lsinitrd to inspect it
lsinitrd /tmp/initrd-0 | grep -i nvidia
I need to do a correction to my previous reply. In fact the driver installation did worked just fine for some reason the MOK enrollment for secure boot never happened. I had to disable secure boot for a quick test and the driver is now loaded. Whcih lkeaves us with the following issues: - GPG repo key is not imported automatically and the user has to do this after adding the repo and before rebooting the system other wise the health check will get stuck in a boot loop - TPM predictions are not updated on it's own - Seucre boot MOK enrollment seems to be not happening. The later I tested with Kalpa where the MOK enrollment worked as usual. After installing the driver and rebooting I was prompted to enroll the MOK and the driver was loaded afterwards. I know Kalpa is very different from Aeon but I just had it at hand as I am running it on this very same machine. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c85 --- Comment #85 from Imo Hester <vortex@z-ray.de> --- (In reply to Stefan Dirsch from comment #84)
Is there anything to be done by the nvidia driver packager?
I am so sorry! I've read the mail and then forgot to respond. q_q No the driver package is fine as only MOK enrolment was the last thing I knew of wasn't working on it's own. But I didn't ran into this issue as of lately. I guess it is either fixed or will not occur with the next 560 stable release due to it using the open kernel module to my knowledge and not relying on the nvidia keys? Depends on how many 550 releases nvidia plans on doing before calling 560 stable :D -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c86 --- Comment #86 from Imo Hester <vortex@z-ray.de> --- I'd like to add. That even G05 is working fine in my Laptop too! Even thought it has no secure boot (it's broken by firmware) and no TPM and uses classics FDE. But the kernel module build just fine, installs and the systemd-boot entries are updated accordingly as well. Also additional kernel modules like bbswitch (it is a reaaaaaaly old Laptop) works fine as well. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1224773 https://bugzilla.suse.com/show_bug.cgi?id=1224773#c92 --- Comment #92 from Imo Hester <vortex@z-ray.de> --- Good day everyone. For some reason on a new Aeon install nouveau get no longer blacklisted. I am not sure why though because as reported in this bug previously it did at some point. During installing the driver I noticed the following lines:
Modprobe blacklist files have been created at /usr/lib/modprobe.d to prevent Nouveau from loading. This can be reverted by deleting /usr/lib/modprobe.d/nvidia-*.conf. *** Reboot your computer and verify that the NVIDIA graphics driver can be loaded. *** No <initramfs file> specified and the default image '/boot/efi/01b217b106b14d2284b6b1f5cff1fa5d/6.11.8-1-default/initrd' cannot be accessed! Usage: lsinitrd [options] [<initramfs file> [<filename> [<filename> [...] ]]] Usage: lsinitrd [options] -k <kernel version> -h, --help print a help message and exit. -s, --size sort the contents of the initramfs by size. -m, --mod list modules. -f, --file <filename> print the contents of <filename>. --unpack unpack the initramfs, instead of displaying the contents. If optional filenames are given, will only unpack specified files, else the whole image will be unpacked. Won't unpack anything from early cpio part. --unpackearly unpack the early microcode part of the initramfs. Same as --unpack, but only unpack files from early cpio part. -v, --verbose unpack verbosely. -k, --kver <kernel version> inspect the initramfs of <kernel version>. done]
I am not sure what is happening here but the path where it tries to find the initrd seems messed up. The only path where the system could offer any initrd files is actually:
ll /boot/efi/aeon/6.11.8-1-default/ -rwxr-xr-x. 1 root root 101915865 12. Dez 00:15 initrd-2a718d985b5fe292e0e6c893da12f6abe18ba42f -rwxr-xr-x. 1 root root 14940528 14. Nov 13:44 linux-735bfc1bd7e24c541fa174ce8c8b939215ddf744
Therefore I don't know what it tries to do at: "/boot/efi/01b217b106b14d2284b6b1f5cff1fa5d/6.11.8-1-default/initrd". At best the random character string is to be attached to the initrd- file but not the path. Not to mention that there is no "initrd-01b217b106b14d2284b6b1f5cff1fa5d" file matching the string in the path at all. I also made sure the MOK was enrolled as this needs to be done manually with the proprietary module still. After running
sudo transactional-update initrd Gave a new initrd in the right location with everything in it and correct boot entries. Now I have running nv drivers.
Sorry for bothering you guys again with this nasty issue :/ Kind regards, Imo (My name not "In my Opinion" :D) -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com