PS: I seem to have forgotten to mention that i enabled snapshots in the BTRFS mount in step 1, but that is just a side-detail i think wrt the problem at hand :)

I just noticed the following:
> mount /dev/mapper/Linux-suseLeap /mnt/btrfs/
> l /mnt/btrfs/lib/modules/
> > total 0
> > drwxr-xr-x 1 root root   92 Aug 13 08:37 ./
> > drwxr-xr-x 1 root root 1904 Aug 13 08:37 ../
> > drwxr-xr-x 1 root root  292 Aug 13 08:38 5.3.18-lp152.19-default/
> > drwxr-xr-x 1 root root  470 Aug 13 08:38 5.3.18-lp152.33-default/
> l /mnt/btrfs/lib/modules/5.3.18-lp152.33-default/updates
> > ls: cannot access '/mnt/btrfs/lib/modules/5.3.18-lp152.33-default/updates': No such file or directory
> l /mnt/btrfs/lib/modules/5.3.18-lp152.19-default/updates/
> > total 86220
> > drwxr-xr-x 1 root root      104 Aug 13 08:38 ./
> > drwxr-xr-x 1 root root      292 Aug 13 08:38 ../
> > -rw-r--r-- 1 root root  5335800 Aug 13 08:38 nvidia-drm.ko
> > -rw-r--r-- 1 root root  2183776 Aug 13 08:38 nvidia-modeset.ko
> > -rw-r--r-- 1 root root 42425800 Aug 13 08:38 nvidia-uvm.ko
> > -rw-r--r-- 1 root root 38338392 Aug 13 08:38 nvidia.ko

Seems the kernel modules are not installed for the latest kernel used, maybe that's part of the problem?

> umount /mnt/btrfs
> mount /dev/mapper/Linux-suseLeap --options=subvol=/@/var /mnt/btrfs/
> l /mnt/btrfs/var/lib/nvidia-pubkeys
> > ls: cannot access '/mnt/btrfs/var/lib/nvidia-pubkeys': No such file or directory

For completeness and documentation:
> btrfs filesystem show
---
Label: none  uuid: a9a4f792-15e9-41e3-983a-ae0bb6d00b2f
        Total devices 1 FS bytes used 7.79GiB
        devid    1 size 64.00GiB used 10.07GiB path /dev/mapper/Linux-suseTumbleWeed

Label: 'Backups'  uuid: 7f9302f6-0006-480e-84a5-771c9e185581
        Total devices 1 FS bytes used 597.05GiB
        devid    1 size 1.82TiB used 601.02GiB path /dev/sdb

Label: 'Leap'  uuid: 42ae1b56-75fb-432e-aa02-cec4c7cd6b4d
        Total devices 1 FS bytes used 6.71GiB
        devid    1 size 64.00GiB used 9.02GiB path /dev/mapper/Linux-suseLeap
---
> mount /dev/mapper/Linux-suseLeap /mnt/btrfs
> btrfs subvolume list /mnt/btrfs
---
ID 256 gen 29 top level 5 path @
ID 258 gen 121 top level 256 path @/var
ID 259 gen 60 top level 256 path @/usr/local
ID 260 gen 39 top level 256 path @/srv
ID 261 gen 105 top level 256 path @/root
ID 262 gen 32 top level 256 path @/opt
ID 263 gen 65 top level 256 path @/boot/grub2/x86_64-efi
ID 264 gen 25 top level 256 path @/boot/grub2/i386-pc
ID 265 gen 105 top level 256 path @/.snapshots
ID 266 gen 123 top level 265 path @/.snapshots/1/snapshot
ID 273 gen 64 top level 265 path @/.snapshots/2/snapshot
ID 274 gen 71 top level 265 path @/.snapshots/3/snapshot
ID 275 gen 92 top level 265 path @/.snapshots/4/snapshot
ID 277 gen 102 top level 265 path @/.snapshots/5/snapshot
ID 278 gen 104 top level 265 path @/.snapshots/6/snapshot
---
> umount /mnt/btrfs

(In reply to Tripple Moon from comment #2)

> Seems the kernel modules are not installed for the latest kernel used, maybe
> that's part of the problem?

No, it's not. it's called KABI compatibility, and it's a core feature of openSUSE Leap. But if you believe this is the problem, simply boot the 5.3.18-lp152.19-default kernel and see if it goes away.

> You asked me for "the detailed log", which part of what you need?
> (I can access this Leap install via /dev/mapper/Linux-suseLeap )

For a start, provide "zypper lr -d" output, exact version and release of the relevant packages (kernel and nvidia drivers at least), full boot log ("journalctl -b -o short-monotonic"), and yast logs (/var/log/YaST2).

Use common sense. You may also want to provide info from efivarfs, for example:

> hexdump /sys/firmware/efi/vars/SecureBoot-*/data

or the content of other EFI variables mentioned in bug 1173158. Your list of btrfs subvolumes is quite unlikely to provide a clue for solving the issue.

You can also run "supportconfig" from the "supportutils" package, but using common sense is still helpful.

(In reply to Martin Wilck from comment #4)
> (In reply to Tripple Moon from comment #2)
> 
> > Seems the kernel modules are not installed for the latest kernel used, maybe
> > that's part of the problem?
> 
> No, it's not. it's called KABI compatibility, and it's a core feature of
> openSUSE Leap. But if you believe this is the problem, simply boot the
> 5.3.18-lp152.19-default kernel and see if it goes away.
I thought modprobe only looked for modules in the current kernel version's sub-directory, i might be wrong in case of suse as im a freshmen wrt suse.

> > You asked me for "the detailed log", which part of what you need?
> > (I can access this Leap install via /dev/mapper/Linux-suseLeap )
> 
> For a start, provide "zypper lr -d" output, exact version and release of the
> relevant packages (kernel and nvidia drivers at least), full boot log
> ("journalctl -b -o short-monotonic"), and yast logs (/var/log/YaST2).
I intentionally installed a fresh version of Leap in a LVM sub-volume so that it would not change by user interactions (restarts etc) to provide accurate feedback.
I am unwilling to boot into that install because i do *not* want anything to change so i can provide accurate info without dynamic changes in between.
So if you can provide me with filenames to attach i can do that, like fe. '/var/log/YaST2' you mentioned and i will try to attach now.
---
> mount /dev/mapper/Linux-suseLeap --options=subvol=/@/var /mnt/btrfs/
> l /mnt/btrfs/log/YaST2
total 3996
drwx------ 1 root root     270 Aug 13 08:25 ./
drwxr-xr-x 1 root root     556 Aug 13 08:43 ../
drwxr-xr-x 1 root root      34 Aug 13 08:25 control/
drwxr-xr-x 1 root root      34 Aug 13 08:23 control-01/
-rw-r--r-- 1 root root    3367 Aug 13 08:20 curl_log
-rw-r--r-- 1 root root   53366 Aug 13 08:20 macro_inst_initial.ycp
-rw-r--r-- 1 root root   10511 Aug 13 08:39 mkinitrd.log
drwxr-xr-x 1 root root     356 Aug 13 08:20 storage-inst/
-rw-r--r-- 1 root root    4660 Aug 13 08:20 y2changes
-rw-r--r-- 1 root root 2249737 Aug 13 08:40 y2log
-rw-r--r-- 1 root root  938100 Aug 13 08:20 y2log-1.gz
-rw-r--r-- 1 root root    3858 Aug 13 08:20 y2start.log
-rw-r--r-- 1 root root  808648 Aug 13 08:20 yast-installation-logs.tar.xz
> du -h /mnt/btrfs/log/YaST2
168K    /mnt/btrfs/log/YaST2/storage-inst
64K     /mnt/btrfs/log/YaST2/control-01
64K     /mnt/btrfs/log/YaST2/control
4.2M    /mnt/btrfs/log/YaST2
> cd /mnt/btrfs/log/
> tar --create --gzip --verbose --file=/tmp/bug-attachment-YaST2-logdir.tar.gz YaST2
YaST2/
YaST2/mkinitrd.log
YaST2/y2changes
YaST2/curl_log
YaST2/storage-inst/
YaST2/storage-inst/01-probed.xml
YaST2/storage-inst/01-probed.yml
YaST2/storage-inst/02-probed.xml
YaST2/storage-inst/02-probed.yml
YaST2/storage-inst/03-proposed.xml
YaST2/storage-inst/03-proposed.yml
YaST2/storage-inst/04-actions.txt
YaST2/storage-inst/05-partitioner.xml
YaST2/storage-inst/05-partitioner.yml
YaST2/storage-inst/06-actions.txt
YaST2/storage-inst/07-committed.xml
YaST2/storage-inst/07-committed.yml
YaST2/macro_inst_initial.ycp
YaST2/y2log-1.gz
YaST2/y2start.log
YaST2/yast-installation-logs.tar.xz
YaST2/y2log
YaST2/control-01/
YaST2/control-01/control.xml
YaST2/control-01/README
YaST2/control/
YaST2/control/control.xml
YaST2/control/README
> l /tmp/bug-attachment-YaST2-logdir.tar.gz
-rw-r--r-- 1 root root 1913569 Aug 14 12:15 /tmp/bug-attachment-YaST2-logdir.tar.gz
---


> Use common sense. You may also want to provide info from efivarfs, for
> example:
> 
> > hexdump /sys/firmware/efi/vars/SecureBoot-*/data
> or the content of other EFI variables mentioned in bug 1173158.
My personal deficient is that i can not operate without common sense, so that is always enabled r/o ;)
If you don't believe a bug reporter (giving so much details as me) stating the installation started with SB *enabled*, we have no point to continue.
I'm writing this from Tumbleweed in SB-mode...(Same as while installing Leap)
---
hexdump /sys/firmware/efi/vars/SecureBoot-*/data
0000000 0001                                   
0000001

hexdump /sys/firmware/efi/efivars/use_openSUSE_cert-605dab50-e046-4300-abb6-3dd810dd8b23
0000000 0006 0000 0001                         
0000005
---
I couldn't find any other EFI variables mentioned, if i missed any just ask...


> Your list of btrfs subvolumes is quite unlikely to provide a clue for solving the issue.
That was meant as documenting the layout of the used BTRFS, both for you guys and myself to ease accessing files inside it without going "live" in that install.
Thus keeping that install at exactly the same state as it was when i submitted this issue...

> 
> You can also run "supportconfig" from the "supportutils" package, but using
> common sense is still helpful.
Like i said lets not go the route of running commands in a live boot of that install and instead stick to static data left inside...

Created attachment 840635 [details]
YaST2 logdir

As requested

(In reply to Tripple Moon from comment #5)

> I thought modprobe only looked for modules in the current kernel version's
> sub-directory, i might be wrong in case of suse as im a freshmen wrt suse.

True. There should be a weak-updates subdirectory there, with symlinks to the .ko files in the other kernel's directory which are KABI-compatible.

> If you don't believe a bug reporter (giving so much details as me) stating
> the installation started with SB *enabled*, we have no point to continue.
> I'm writing this from Tumbleweed in SB-mode...(Same as while installing Leap)

I don't judge the trustworthiness of information by the amount of detail
someone provides. You wrote in bug 1173158, comment 106: "I am also unable to
locate '/var/lib/nvidia-pubkeys'". Takashi and Steffen, whom I have every
reason to trust absolutely, both assert that on a system booted with secure
boot and with the recent NVidia packages installed, that directory will be
created during the installation procedure of the driver packages. Therefore
double-checking whether Secure Boot was actually active makes sense. It's not
about "believing" but about evidence. Your BIOS may have a bug, for example,
and not set the SecureBoot variable as the kernel expects.

> ---
> hexdump /sys/firmware/efi/vars/SecureBoot-*/data
> 0000000 0001                                   
> 0000001

Thanks.

From the YaST2 logs, I was able to verify that you installed a KMP version that should support the automatic creation of the pubkey, and that the installation was successful:

> 2020-08-13 08:37:11 <1> localhost.localdomain(2897) [zypp::exec++] ExternalProgram.cc(start_program):260 Executing[C] 'rpm' '--root' '/
' '--dbpath' '/var/lib/rpm' '-U' '--percent' '--noglob' '--force' '--nodeps' '--noposttrans' '--' '/var/cache/zypp/packages/download.nv
idia.com-leap/x86_64/nvidia-gfxG05-kmp-default-450.57_k5.3.18_lp152.19-lp152.38.1.x86_64.rpm'
> 2020-08-13 08:37:11 <1> localhost.localdomain(2897) [zypp::exec++] ExternalProgram.cc(start_program):444 pid 3642 launched
> 2020-08-13 08:38:55 <1> localhost.localdomain(2897) [zypp::exec++] ExternalProgram.cc(checkStatus):548 Pid 3642 successfully completed

The %post script of this package contains this script:

if [ -x /usr/bin/mokutil ]; then
  mokutil --sb-state | grep -q "SecureBoot enabled" 
  if [ $? -eq 0 ]; then
    privkey=$(mktemp /tmp/MOK.priv.XXXXXX)
    pubkeydir=/var/lib/nvidia-pubkeys
    pubkey=$pubkeydir/MOK-nvidia-gfxG05-450.57-$flavor.der

    # make sure creation of pubkey doesn't fail later
    test -d pubkeydir || mkdir -p $pubkeydir
    rm -f $pubkey

    # Create a key pair (private key, public key)
    openssl req -new -x509 -newkey rsa:2048 \
                -keyout $privkey \
                -outform DER -out $pubkey -days 1000 \
                -subj "/CN=Local build for nvidia-gfxG05 450.57 on $(date +"%Y-%m-%d")/" \
                -nodes

    # Install the public key to MOK
    mokutil --import $pubkey --root-pw

    # Sign the Nvidia modules (weak-updates appears to be broken)
    for i in /lib/modules/5.3.18-lp152.19-$flavor/updates/nvidia*.ko; do
      /lib/modules/$kver/build/scripts/sign-file sha256 $privkey $pubkey $i
    done

    # cleanup: private key no longer needed
    rm -f $privkey
  fi
fi

Thus after the successful completion of the installation of this package,
/var/lib/nvidia-pubkeys should indeed exist, and the key should be enrolled
for importing. I can see but a few possible explanations for this not being
the case:

 1. mokutil not installed
 2. SB not enabled
 3. mokutil --sb-state | grep -q "SecureBoot enabled" fails for some other
    reason
 4. mkdir -p $pubkeydir failed
 5. either rpm or bash totally buggy so that the above script isn't correctly
    executed
 6. I overlooked something

All of these (except 6., maybe) look extremely unlikely, yet one of them must
be true, otherwise the directory would exist. Agree?

The only way we can proceed here I think is by you trying to install this
package manually with high verbosity, check the results and provide the logs.
I guess you'll have to boot that problematic installation again for that purpose.

Just for avoiding confusion: as already mentioned in another bug report, the recent support of the one-time cert generation is included *only* in SLE/Leap 15.2 Nvidia package, and *not* in TW package.  The reason is that TW kernel has no strict lockdown, hence it still works with an unsigned module.  That said, the file /var/lib/nvidia-pubkeys/* is present only on SLE/Leap 15.2 (and IFF you enabled Secure Boot at the installation time).

(In reply to Martin Wilck from comment #7)
> (In reply to Tripple Moon from comment #5)
> 
> The %post script of this package contains this script:
> 
> if [ -x /usr/bin/mokutil ]; then
>   mokutil --sb-state | grep -q "SecureBoot enabled" 
>   if [ $? -eq 0 ]; then
>     privkey=$(mktemp /tmp/MOK.priv.XXXXXX)
>     pubkeydir=/var/lib/nvidia-pubkeys
>     pubkey=$pubkeydir/MOK-nvidia-gfxG05-450.57-$flavor.der
> 
>     # make sure creation of pubkey doesn't fail later
>     test -d pubkeydir || mkdir -p $pubkeydir
Maybe this part needs better error checking indeed.
Because seeing this code i am puzzled why it wasn't created also.
Maybe "mokutil" is not available at runtime in the path that is checked for?
> l /mnt/btrfs/usr/bin/mokutil
> > -rwxr-xr-x 1 root root 49064 May 16 16:34 /mnt/btrfs/usr/bin/mokutil*
Nope it looks present...

>     # Install the public key to MOK
>     mokutil --import $pubkey --root-pw
This spot is problematic also, see: https://bugzilla.opensuse.org/show_bug.cgi?id=1173158#c138

> I can see but a few possible explanations for this not being the case:
> 
>  1. mokutil not installed
>  2. SB not enabled
>  3. mokutil --sb-state | grep -q "SecureBoot enabled" fails for some other
>     reason
>  4. mkdir -p $pubkeydir failed
>  5. either rpm or bash totally buggy so that the above script isn't correctly
>     executed
>  6. I overlooked something
> 
> All of these (except 6., maybe) look extremely unlikely, yet one of them must
> be true, otherwise the directory would exist. Agree?
Indeed, that's why code always needs bug fixes ;)

> The only way we can proceed here I think is by you trying to install this
> package manually with high verbosity, check the results and provide the logs.
> I guess you'll have to boot that problematic installation again for that
> purpose.
Not my favorite way of spending time, but sure in due time i will be willing to do a new fresh install.
But when i do, i will need explicit directions wrt "install this package manually with high verbosity, check the results and provide the logs."
A step by step command line or menu selection etc would be best guidance for both sides...

(In reply to Takashi Iwai from comment #8)
> Just for avoiding confusion: as already mentioned in another bug report, the
> recent support of the one-time cert generation is included *only* in
> SLE/Leap 15.2 Nvidia package, and *not* in TW package.  The reason is that
> TW kernel has no strict lockdown, hence it still works with an unsigned
> module.  That said, the file /var/lib/nvidia-pubkeys/* is present only on
> SLE/Leap 15.2 (and IFF you enabled Secure Boot at the installation time).

Yea i already noticed that TW does not force signed kernel-modules, and thus successfully loads the unsigned (or wrong signed) ones with only a log message...

The installation log of each package is found rather in /var/log/zypper.log (or /var/log/zypp/*, sorry I forgot which is which), and you might be able to find the post script outputs there.

(In reply to Takashi Iwai from comment #11)
> The installation log of each package is found rather in /var/log/zypper.log
> (or /var/log/zypp/*, sorry I forgot which is which), and you might be able
> to find the post script outputs there.

It's zypper.log, but doesn't that show %posttrans script output only?

My recommendation would be to chroot into the already installed Leap 15.2 system, uninstall the nvidia KMP, re-download it with "zypper in --download-only", and carry out the installation with "rpm -ivvh".

I forgot to reply to this part of you reply...
(In reply to Martin Wilck from comment #7)
> (In reply to Tripple Moon from comment #5)
> 
> > I thought modprobe only looked for modules in the current kernel version's
> > sub-directory, i might be wrong in case of suse as im a freshmen wrt suse.
> 
> True. There should be a weak-updates subdirectory there, with symlinks to
> the .ko files in the other kernel's directory which are KABI-compatible.

So let me check that...
> mount /dev/mapper/Linux-suseLeap /mnt/btrfs/
> l /mnt/btrfs/lib/modules/
> > total 0
> > drwxr-xr-x 1 root root   92 Aug 13 08:37 ./
> > drwxr-xr-x 1 root root 1904 Aug 13 08:37 ../
> > drwxr-xr-x 1 root root  292 Aug 13 08:38 5.3.18-lp152.19-default/
> > drwxr-xr-x 1 root root  470 Aug 13 08:38 5.3.18-lp152.33-default/
> l /mnt/btrfs/lib/modules/5.3.18-lp152.33-default/weak-updates/
> > total 0
> > drwxr-xr-x 1 root root  14 Aug 13 08:38 ./
> > drwxr-xr-x 1 root root 470 Aug 13 08:38 ../
> > drwxr-xr-x 1 root root 104 Aug 13 08:38 updates/
> l /mnt/btrfs/lib/modules/5.3.18-lp152.33-default/weak-updates/updates/
> > total 16
> > drwxr-xr-x 1 root root 104 Aug 13 08:38 ./
> > drwxr-xr-x 1 root root  14 Aug 13 08:38 ../
> > lrwxrwxrwx 1 root root  58 Aug 13 08:38 nvidia-drm.ko -> /lib/modules/5.3.18-lp152.19-default/updates/nvidia-drm.ko
> > lrwxrwxrwx 1 root root  62 Aug 13 08:38 nvidia-modeset.ko -> /lib/modules/5.3.18-lp152.19-default/updates/nvidia-modeset.ko
> > lrwxrwxrwx 1 root root  58 Aug 13 08:38 nvidia-uvm.ko -> /lib/modules/5.3.18-lp152.19-default/updates/nvidia-uvm.ko
> > lrwxrwxrwx 1 root root  54 Aug 13 08:38 nvidia.ko -> /lib/modules/5.3.18-lp152.19-default/updates/nvidia.ko
Looks fine even with the weird sub-sub dir?
(Because one would expect them to be right under "weak-updates")

That's fine.

(In reply to Takashi Iwai from comment #11)
> The installation log of each package is found rather in /var/log/zypper.log
> (or /var/log/zypp/*, sorry I forgot which is which), and you might be able
> to find the post script outputs there.

I see these:
> mount /dev/mapper/Linux-suseLeap --options=subvol=/@/var /mnt/btrfs/
> find /mnt/btrfs/log -iname \*zypp\*
> > /mnt/btrfs/log/zypp
> > /mnt/btrfs/log/zypper.log
> > /mnt/btrfs/log/pk_backend_zypp
Want me to tar-up and attach these also?

it can't hurt, although I think if any, only zypper.log would be helpful here.

(In reply to Martin Wilck from comment #16)
> it can't hurt, although I think if any, only zypper.log would be helpful
> here.

Will do:
> mount /dev/mapper/Linux-suseLeap --options=subvol=/@/var /mnt/btrfs
> cd /mnt/btrfs/log
> tar --create --gzip --verbose --file=/tmp/bug-attachment-zypper-logs.tar.gz zypp zypper.log pk_backend_zypp 
> > zypp/
> > zypp/history
> > zypper.log
> > pk_backend_zypp

Created attachment 840651 [details]
zypper logs

Comment on attachment 840651 [details]
zypper logs

As requested

(In reply to Tripple Moon from comment #18)
> zypper logs

Thanks. Unfortunately, it contains no traces of nvidia driver installation, and no %post script traces. So I guess we need to resort to the more cumbersome manual debug method I suggested in comment 12.

(In reply to Martin Wilck from comment #20)
> (In reply to Tripple Moon from comment #18)
> > zypper logs
> 
> Thanks. Unfortunately, it contains no traces of nvidia driver installation,
> and no %post script traces. So I guess we need to resort to the more
> cumbersome manual debug method I suggested in comment 12.

If you could tell me where the rpm logs should be, i could attach those also, instead of going (semi-)live in that install...

I didn't see them either in the Yast log or in the zypper log. I don't think they've been saved. I'm not quite sure what you're afraid of wrt that installation. It seems to be broken anyway, so there's little risk to break it even further, is it?

Btw I was looking for a *trace* of the %post script and you won't get that under normal conditions anyway. I'm not aware of any other method besides "rpm -ivvh".

(In reply to Martin Wilck from comment #22)
> I didn't see them either in the Yast log or in the zypper log. I don't think
> they've been saved. I'm not quite sure what you're afraid of wrt that
> installation. It seems to be broken anyway, so there's little risk to break
> it even further, is it?

As i said before, it's not a matter of me being "afraid".
I just don't want to risk "polluting" that install, so that i can provide accurate feedback, wrt the state the machine was after the steps taken to install it (eg. STR).
I also said if it is absolutely necessary that i would be willing to perform another fresh install, but it is not something i enjoy doing with my time ;)

But it looks like i will have to do it anyway now, it will take a bit of time though due to RL and other issues im involved in like https://bugzilla.suse.com/show_bug.cgi?id=1175325#c4

(In reply to Martin Wilck from comment #12)
> My recommendation would be to chroot into the already installed Leap 15.2
> system, uninstall the nvidia KMP, re-download it with "zypper in
> --download-only", and carry out the installation with "rpm -ivvh".

New fresh install:
- After booting into Leap
  - Added nVidia community repository
    - Accepted GPG key.
    - Deselected automatically selected packages due to nVidia drivers.

> zypper se x11-video-nvidiaG05
> > Loading repository data...
> > Reading installed packages...
> > 
> > S | Name                | Summary                                                 | Type
> > --+---------------------+---------------------------------------------------------+--------
> >   | x11-video-nvidiaG05 | NVIDIA graphics driver for GeForce 600 series and newer | package

Download only: (See: https://paste.opensuse.org/7336793)

RPM install with verbosity:
# rpm -ivvh x11-video-nvidiaG05
# > ufdio:       1 reads,    19077 total bytes in 0.000007 secs
# > D: ============== x11-video-nvidiaG05
# > error: open of x11-video-nvidiaG05 failed: No such file or directory
# > D: found 0 source and 0 binary packages
# > D: Exit status: 1
# rpm -ivvh x11-video-nvidiaG05-450.57-lp152.38.1.x86_64
# > ufdio:       1 reads,    19077 total bytes in 0.000016 secs
# > D: ============== x11-video-nvidiaG05-450.57-lp152.38.1.x86_64
# > error: open of x11-video-nvidiaG05-450.57-lp152.38.1.x86_64 failed: No such file or directory
# > D: found 0 source and 0 binary packages
# > D: Exit status: 1
# rpm -ivvh x11-video-nvidiaG05-450.57-lp152.38.1.x86_64.rpm
# > ufdio:       1 reads,    19077 total bytes in 0.000009 secs
# > D: ============== x11-video-nvidiaG05-450.57-lp152.38.1.x86_64.rpm
# > error: open of x11-video-nvidiaG05-450.57-lp152.38.1.x86_64.rpm failed: No such file or directory
# > D: found 0 source and 0 binary packages
# > D: Exit status: 1

Not able to install, because i have no idea where the above downloaded packages are stored on a suse system.

I will be actively searching for another Linux distribution because suse does not use:
- Is too much hardcoded for Grub2 usage in UEFI mode.
  Which makes it too hard/much hassle to switch to systemd-boot and the like.
- DKMS for kernel modules.
  Which eliminates custom modules in a distribution-independent fashion.
  Eliminates signing these automatically for SecureBoot on a per-install basis.
- The following hook directories:
  /etc/kernel/postinst.d
  /etc/kernel/postrm.d
  /etc/initramfs/post-update.d
  Which eliminates standards used in the Linux community to create kernel and ramdisks.

I'm sorry that im unable to be of more help in this case...
It's hard enough to struggle with nVidia drivers, struggling with the distribution is a bit too much...

(In reply to Tripple Moon from comment #25)
> Not able to install, because i have no idea where the above downloaded
> packages are stored on a suse system.

Understandable, it's cryptic. I've created bug 1175592. Sorry, I should have made this more explicit for you. You know, you act like a highly experienced user here on bugzilla, but at the same time you lack knowledge about things that would need no explanation for experienced *openSUSE* users. That has lead to wrong assumptions on my side, sorry again.

I didn't ask you to install "x11-video-nvidiaG05", only the nvidia driver packages, in particular nvidia-gfxG05-kmp-default. That at least I think I mentioned. I don't understand why you made a fresh reinstall. IIRC I had asked you to boot the broken installation, uninstall the nvidia driver packages, and reinstall them manually.

(In reply to Tripple Moon from comment #26)
> I will be actively searching for another Linux distribution

Sorry to hear that.

> - Is too much hardcoded for Grub2 usage in UEFI mode.
>   Which makes it too hard/much hassle to switch to systemd-boot and the like.

Not sure what you ultimately want to achieve. The early boot stages are typically carefully crafted by distribution engineers. If you really need systemd-boot, yes, you'd probably be better off with a different distro that allows more low-level tampering than openSUSE does.

> - DKMS for kernel modules.
>   Which eliminates custom modules in a distribution-independent fashion.
>   Eliminates signing these automatically for SecureBoot on a per-install
> basis.

I'm curious how DKMS would achieve that. I haven't used DKMS for at least a decade, IMO it's broken technology and vastly inferior to other approaches like kernel module packages. I've done a quick search and basically found that this works if module signature checking is globally disabled (https://wiki.ubuntu.com/UEFI/SecureBoot/DKMS). But I may be overlooking something of course.

> - The following hook directories:
>   /etc/kernel/postinst.d
>   /etc/kernel/postrm.d
>   /etc/initramfs/post-update.d
>   Which eliminates standards used in the Linux community to create kernel
> and ramdisks.

These are *not* standard paths outside of the Debian/Ubuntu universe.

(In reply to Martin Wilck from comment #7)
> 
>  1. mokutil not installed
>  2. SB not enabled
>  3. mokutil --sb-state | grep -q "SecureBoot enabled" fails for some other
>     reason
>  4. mkdir -p $pubkeydir failed
>  5. either rpm or bash totally buggy so that the above script isn't correctly
>     executed
>  6. I overlooked something
> 

7. Paths on @/var subvolume do not begin with /var.

(In reply to Tripple Moon from comment #2)
> > umount /mnt/btrfs
> > mount /dev/mapper/Linux-suseLeap --options=subvol=/@/var /mnt/btrfs/
> > l /mnt/btrfs/var/lib/nvidia-pubkeys
> > > ls: cannot access '/mnt/btrfs/var/lib/nvidia-pubkeys': No such file or directory

(In reply to Andrei Borzenkov from comment #28)
> 7. Paths on @/var subvolume do not begin with /var.

=> 6. :-)

Kudos!

And? So the reporter should have tried 

  ls /mnt/btrfs/lib/nvidia-pubkeys

instead. He did it correctly in comment #5 (removing the "var" there).

> mount /dev/mapper/Linux-suseLeap --options=subvol=/@/var /mnt/btrfs/
> l /mnt/btrfs/log/YaST2

Anyway, I still don't see the issue in my script. And he never told us the output of

  mokutil --sb-state

And as Takashi told before there is no need to sign the kernel modules on TW. We do this only when installing the openSUSE Leap 15.2 packages.
So if this is TW --> INVALID. Otherwise please provide the output for the mokutil command.

(In reply to Stefan Dirsch from comment #30)
>   mokutil --sb-state

See comment 5

> hexdump /sys/firmware/efi/vars/SecureBoot-*/data
> 0000000 0001

Thanks. So apparently this means SB is enabled, right? For whatever reason it's expected by everyone to know the content of such efi variables bitwise instead of using the tools, which were written to avoid this inconvenience...

(In reply to Stefan Dirsch from comment #32)
> Thanks. So apparently this means SB is enabled, right? For whatever reason
> it's expected by everyone to know the content of such efi variables bitwise
> instead of using the tools, which were written to avoid this inconvenience...

My bad ... I wasn't aware of "mokutil --sb-state".

Hehe. 

But now I'm wondering what's left here. Secureboot is apparently enabled, but on a TW system (at least it's reported against TW), so kernel modules have not been signed during installation of the package - by intention because not needed with Kernels on TW. Therefore no public key needs to be added and is not copied to the system.

So if you see a nvidia driver issue here, I would expect to see the same issue without secureboot. Or your issue is completely unrelated to the nvidia driver ...

(In reply to Martin Wilck from comment #27)
> (In reply to Tripple Moon from comment #25)
> > Not able to install, because i have no idea where the above downloaded
> > packages are stored on a suse system.
> 
> Understandable, it's cryptic. I've created bug 1175592. Sorry, I should have
> made this more explicit for you. You know, you act like a highly experienced
> user here on bugzilla, but at the same time you lack knowledge about things
> that would need no explanation for experienced *openSUSE* users. That has
> lead to wrong assumptions on my side, sorry again.
I am indeed an experienced Linux user, but a total noob when it comes to openSUSE.
I had made that clear in various other threads but forgot to explicitly mention it in this issue, sorry about that my mistake. :)

> > - DKMS for kernel modules.
> >   Which eliminates custom modules in a distribution-independent fashion.
> >   Eliminates signing these automatically for SecureBoot on a per-install
> > basis.
> 
> I'm curious how DKMS would achieve that. I haven't used DKMS for at least a
> decade, IMO it's broken technology and vastly inferior to other approaches
> like kernel module packages. I've done a quick search and basically found
> that this works if module signature checking is globally disabled
> (https://wiki.ubuntu.com/UEFI/SecureBoot/DKMS). But I may be overlooking
> something of course.
DKMS nowerdays is *the way* for kernel module signing when using either binary modules or compiled on the machine from source.
It's used on many distributions, see: https://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support

> > - The following hook directories:
> >   /etc/kernel/postinst.d
> >   /etc/kernel/postrm.d
> >   /etc/initramfs/post-update.d
> >   Which eliminates standards used in the Linux community to create kernel
> > and ramdisks.
> 
> These are *not* standard paths outside of the Debian/Ubuntu universe.
Although the directory names i mentioned could be debian-based specific the method/functionality is not though...

(In reply to Martin Wilck from comment #29)
> (In reply to Andrei Borzenkov from comment #28)
> > 7. Paths on @/var subvolume do not begin with /var.
> 
> => 6. :-)
> 
> Kudos!
Seems we both missed that indeed, wow +1
But i can assure you even with correct path the results were same while in LEAP.

(In reply to Stefan Dirsch from comment #34)
> But now I'm wondering what's left here. Secureboot is apparently enabled,
> but on a TW system (at least it's reported against TW), so kernel modules
> have not been signed during installation of the package - by intention
> because not needed with Kernels on TW. Therefore no public key needs to be
> added and is not copied to the system.
I reported it against TW but explicitly marked it as originally being found in LEAP, see issue title fe.
And it was known that TW does no kernel locking see the first line where i i start with this i a reply to :)


(In reply to Stefan Dirsch from comment #35)
> So if you see a nvidia driver issue here, I would expect to see the same
> issue without secureboot. Or your issue is completely unrelated to the
> nvidia driver ...
The problem started with the certificate not being installed in the system, making it impossible to enroll the cert into the MokList to start with.
In my case i have another problem that is related to enrolling certs which is separate from the issue with the nVidia-driver, see: https://bugzilla.opensuse.org/show_bug.cgi?id=1175325
Although both are related to each other they are independent from each other...

But anyway as stated i have dropped openSUSE since my last reply, and am using Manjaro (Arch linux) at moment.
So i'm unable to provide more feedback anylonger.
So it's up to you guys to close this issue or keep it open to fix the issue with the nVidia driver on openSUSE with the info i was able to provide for time being...

I won't be following this issue anylonger due to me switching away from openSUSE.

(In reply to Tripple Moon from comment #36)

> > > - DKMS for kernel modules.
> > >   Which eliminates custom modules in a distribution-independent fashion.
> > >   Eliminates signing these automatically for SecureBoot on a per-install
> > > basis.
> > 
> > I'm curious how DKMS would achieve that. I haven't used DKMS for at least a
> > decade, IMO it's broken technology and vastly inferior to other approaches
> > like kernel module packages. I've done a quick search and basically found
> > that this works if module signature checking is globally disabled
> > (https://wiki.ubuntu.com/UEFI/SecureBoot/DKMS). But I may be overlooking
> > something of course.
> DKMS nowerdays is *the way* for kernel module signing when using either
> binary modules or compiled on the machine from source.
> It's used on many distributions, see:
> https://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support

It's also available on openSUSE, as you know. But you didn't answer my question, how would it automate import of signatures into the UEFI key db? I can't see anything, except that dkms allows the compiled modules to be signed with some configurable script. Is that the ground-breaking technology you're alluding to?

That said, compiling kernel modules from source on the target system is not "the way" for any modern Linux distro.

> > > - The following hook directories:
> > >   /etc/kernel/postinst.d
> > >   /etc/kernel/postrm.d
> > >   /etc/initramfs/post-update.d
> > >   Which eliminates standards used in the Linux community to create kernel
> > > and ramdisks.
> > 
> > These are *not* standard paths outside of the Debian/Ubuntu universe.
> Although the directory names i mentioned could be debian-based specific the
> method/functionality is not though...

I would say it is. openSUSE is an rpm-based distro using dracut. This is a different heritage. SUSE has had a feature request process for many years. apparently so far nobody has seriously requested freely user-configurable post-scripts for kernel installation/removal and initramfs generation.

Good luck with Manjaro.

(In reply to Martin Wilck from comment #37)
> (In reply to Tripple Moon from comment #36)
> 
> > DKMS nowerdays is *the way* for kernel module signing when using either
> > binary modules or compiled on the machine from source.
> > It's used on many distributions, see:
> > https://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support
> 
> It's also available on openSUSE, as you know. But you didn't answer my
> question, how would it automate import of signatures into the UEFI key db? I
> can't see anything, except that dkms allows the compiled modules to be
> signed with some configurable script. Is that the ground-breaking technology
> you're alluding to?
You might interpret it as ground-breaking i didn't, but that doesn't matter really.
It's a key step needed to use signed kernel modules, because it allows to automatically sign the kernel modules on the machine with a local key using hooks.
Same as mokutil+shim is currently being used to try to enroll those certs into the UEFI SecureBoot chain.

> That said, compiling kernel modules from source on the target system is not
> "the way" for any modern Linux distro.
We disagree here, which is fine with me.

Besides a few hitches openSUSE looked nice, but didn't deliver enough distro-independed tweaking for my personal taste, so take care and i hope openSUSE will improve more in that regard in the future.

Ok. The issue isn't reproducable for us and the reporter can't provide feedback any longer. Good luck on your journey through the Linux distribution world. ;-)