Planning to make an external nvme SSD my backup PC

English Open Chat
21

Interesting. I had never heard of zram before. Am I correct it uses some of /(root) space as opposed to taking up any /home user space?

I confess I don’t understand is your suggestion of the efi partition being 2~4GB (I use 4GB) for the move to grub-bls or systemd-boot. It could be (and probably is a) brilliant idea - but I simply fail to grasp the benefit.

Speaking of swap drive and EFI partition, it has me thinking of partitioning on the nvme SSD that is to be used in an external nvme SSD enclosure. How should I partition it? The same as normal?

In a 1 TB external SSD devoted to LEAP-15.6, I was nominally thinking of :

  • a small TBD EFI size (I was thinking 250MB to 500MB before I read your post),
  • 40 GB in /root,
  • 4 GB in /swap (but no more given your zram suggestion ) and
  • the remainder in /home. However given its an external SSD, maybe I can do this better.

I am pretty confident that my wife will be ‘happy’ to be able to keep the full 256 GB for Windows-10 in this old Lenovo X1 Carbon generation 4 laptop’s SSD

I suspect I will benefit from reading up on the suggested GNU/Linux partitioning for Linux on an external nvme. I am also thinking of ext4 file system, but again, i need to read up on that.

After returning from dinner, I went ahead and ordered the SSD, ordered the enclosure, and also ordered a longer USB cable:

  • ORICO M2PV-C3 nvme SSD (USB3.1 Gen2 10 Gbps)
  • SAMSUNG 990 EVO Plus NVME SSD 1TB - the “plus” is purported to have less issues than the “pro”
  • UGREEN cable (I want a cable between laptop and enclosure longer than the 15cm that comes with the enclosure). I ended up ordering a 50cm cable (I could not find a 30m cable that had the connector configuration i wanted)

Total cost combined for all three times: ~$114.33 US$ or ~98.38-euro. That is not expensive and in part given that price, I thought maybe its time for me to stop wasting my time deliberating , and over thinking, and to simply proceed. Hopefully I am not ‘jumping’ the gun.

My main concern is the Samsung SSD may be a fake (some of the suppliers in South East Asia can be nebulous), but there is a good return policy on it which Lazada will support, so as soon as I obtain the SSD I need to test it reasonably thoroughly, and if I assess it a fake then immediately return.

I also vaguely recall there may be a website where one can enter some number from the SSD packaging, on to a Samsung website, and that will let one know if it is a fake. Something else for me to check into.

22

@oldcpu it uses system ram… it’s been around since 2012 in openSUSE :wink:
https://build.opensuse.org/projects/openSUSE:Factory/packages/systemd-zram-service/files/systemd-zram-service.spec?expand=1

and also zram-generator https://build.opensuse.org/projects/openSUSE:Factory/packages/zram-generator/files/zram-generator.spec?expand=1

For that boot changes, kernels and loaders are saved here, so need more space.

23

Thanks.

I just now read up on zram and trim.

Looks like openSUSE enables trim by default when there is an nvme in one’s laptop, as I ran some commands and i note trim is enabled on my newer Lenovo X1 carbon generation-9. But I never did anything to enable it - so I assume enabled by default.

I confess < gulp > I never heard of zram, and it is just one more reason I should re-install openSUSE on this Leonvo X1 carbon generation 9.

This Lenovo X1 carbon gen-9 (my primary PC ) has a 16 GB /swap (which is almost “criminal” by me in setting up some years back, given the /(root) at 25 GB that is too small) , so when I repartition this laptop’s SSD (in a month or two AFTER I get the external bootable nvme SSD up and running) I will remove the swap and increase the /(root) to~50 GB (this Lenovo has a 1 TB nvme SSD).

I will wait until the external SSD is up and running so that I have a backup Lenovo X1 carbon gen-4 laptop available while working on cleaning up my primary Lenovo X1 carbon gen-9 laptop.

24

Ok - I researched this idea a bit.

I am very used to ~250 MB to ~500 MB max for /efi, so the suggestion 2GB to 4GB took me by surprise.

You noted “grub-bls” or “systemd-boot”. … < sigh > me being the ‘old dog’ I definitely need to try and learn these new tricks, as opposed to being the ‘old dog who can’t learn new tricks’. :astonished:

My understanding now after some research follows.

Reference ‘systemd-boot’. I read it may be a more simple UEFI boot manager that also needs to store kernel/initrd files in the EFI partition.

Reference BLS: I read “BLS” is “BootLoader Spec”. Traditionally GRUB2 stores its config in /boot/grub2/grub.cfg, but BLS (currently used by Fedora ? ) stores kernel boot entries as individual files in the EFI partition (/boot/loader/entries).

If later SUSE GmbH or even myself becomes interested in exploring ideas (unlikely for me but one never knows) and decides to adopt BLS or systemd-boot, a small EFI partition (~500 MB) might quickly fill up quickly with:
:black_small_square: Multiple kernel versions.
:black_small_square: Initramfs copies.
:black_small_square: Bootloader redundancy (for recovery

Hence both systemd-boot and BLS require more space in the EFI partition.

Possibly even systemd-boot and BLS are under consideration by the SUSEGmbH team for a future version of openSUSE LEAP ?? I don’t know. But I do like to be prepared.

I am thinking for an external, 2 TB nvme SSD, that 2 GB EFI partition should be adequate. After reading about BLS and system-d-boot I was originally thinking maybe only 1 GB but who knows, after typing this, maybe I will in the future want to put a dual boot (?) on this nvme which means the EFI needs more space - so maybe 2 GB EFI.

Hence having the partitioning planned now for the future is likely a good idea.

I am shaking my head at myself - the GNU/Linux world is passing me by and I feel very much out of date.

25

@oldcpu don’t forget the switch from Apparmor to SELinux and of course demise of YaST in favor of Cockpit, Myrlyn etc… oh and the Agama installer…

26

All this is reason I hope it’s never required to use any bootloader that depends on a non-native file system any more than what UEFI specs demanded over a decade ago. Additional reasons include:

  1. 1-all my systems are multi- multiboot (a dozen or more installations per disk in most computers, mostly a lot more). Sticking to the already in use bootloaders is reason enough, avoiding further administrative complication. VMs here are limited to those for OS/2 to run DOS apps.
  2. limiting the use of a shared partition as happens with Grub as exclusive Gnu/Linux bootloader is eminently sensible.
  3. at least in theory, BLS hosting of a mixture of kernels, initrds and other boot files from multiple operating systems on one filesystem is a recipe for confusion, in addition to determination of space adequacy.
  4. No symlinks on FAT!!! All bootloader stanzas I actually use employ nice, short, humanly memorable symlinks; e.g. simply vmlinuz, initrd-prv2, and/or vmlinuz61238; no reason for remembering where any arch or buildIDstring or dots or dashes and/or whichever belong among filenames. /boot/grub2/custom or /etc/grub.d/* need attention only when an operating system is added or removed, or its kernel cmdline has reason to be modified.
  5. at troubleshooting times, kernel and initrd can be copied to and used by any random filesystem for use by a special test-only bootloader stanza. Example use case, where hosting kernel/initrd on other filesystem reduced boot times from exorbitant (double digit minutes) to normal (seconds or less).
27

@mrmazda your the exception rather than the rule :wink: as Spock said, the needs of the many out way the needs of a few… I’m still trying to get to one desktop and a laptop… one day soon hopefully once I get the Dell workstation up to speed.

1 Like
28

Spock didn’t always get everything right. ISTR something about Gnu/Linux offering an advantage over alternatives in the form of choices otherwise not available. Are we Linux users now favoring monoliths over having options?

29

@mrmazda many users are focused on security/privacy these days and want the likes of TPM, SELinux, Secure Boot etc, newer hardware only likes UEFI boot, there has to be a compromise somewhere.

30

I’m fine with UEFI booting where the ESP hosts one or a few files that do not customarily need changing along with every OS update involving kernels/initrds or the support files that initrds require.

I would likely have a considerably different stance were newer bootloaders not depending on a decades old filesystem originally designed for an 8 bit OS, and minimally evolved since. I do get the need for extra security in mobile envronments, but not why they seem to be able to dictate same behavior when mobility plays no part in a particular environment.

31

@mrmazda in this case I’m just suggesting that @oldcpu prepares to the future :wink:

I’m still using grub, but;

nvme0n1     259:0    0 953.9G  0 disk  
├─nvme0n1p1 259:1    0     4G  0 part  /boot/efi
└─nvme0n1p2 259:2    0 949.9G  0 part  /

tree /boot/efi

/boot/efi
└── EFI
    └── opensuse
        └── grubx64.efi

3 directories, 1 file

Compared to another Tumbleweed setup

zram0       252:0    0  15.3G  0 disk [SWAP]
nvme0n1     259:0    0 953.9G  0 disk 
├─nvme0n1p1 259:1    0     4G  0 part /boot/efi
└─nvme0n1p2 259:2    0 949.9G  0 part /

tree /boot/efi
/boot/efi
├── EFI
│   ├── BOOT
│   │   ├── BOOTX64.EFI
│   │   ├── MokManager.efi
│   │   └── fallback.efi
│   └── systemd
│       ├── MokManager.efi
│       ├── boot.csv
│       ├── grub.efi
│       ├── installed_by_sdbootutil
│       └── shim.efi
├── loader
│   ├── entries
│   │   ├── opensuse-tumbleweed-6.15.4-1-default-1.conf
│   │   ├── opensuse-tumbleweed-6.15.5-1-default-1.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc5-1.gbad2c39-default-1.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc5-2.g2396b44-default-1.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-1.g3743c47-default-1.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-1.g3743c47-default-79.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-2.gcdcdcc9-default-1.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-2.gcdcdcc9-default-79.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-2.gcdcdcc9-default-80.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-2.gcdcdcc9-default-81.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-2.gcdcdcc9-default-82.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-2.gcdcdcc9-default-83.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-3.g493c219-default-1.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-3.g493c219-default-79.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-3.g493c219-default-80.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-3.g493c219-default-81.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-3.g493c219-default-82.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-3.g493c219-default-83.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-3.g493c219-default-84.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-3.g493c219-default-85.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-3.g493c219-default-86.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-3.g493c219-default-87.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-4.g490e080-default-1.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-4.g490e080-default-82.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-4.g490e080-default-83.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-4.g490e080-default-84.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-4.g490e080-default-85.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-4.g490e080-default-86.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-4.g490e080-default-87.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-4.g490e080-default-88.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-5.gb9ba39a-default-1.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-5.gb9ba39a-default-86.conf
│   │   ├── opensuse-tumbleweed-6.16.0-rc6-5.gb9ba39a-default-87.conf
│   │   └── opensuse-tumbleweed-6.16.0-rc6-5.gb9ba39a-default-88.conf
│   ├── entries.srel
│   ├── loader.conf
│   └── random-seed
└── opensuse-tumbleweed
    ├── 6.15.4-1-default
    │   ├── initrd-4d81e28ebd19b2bcffb45bd08b4ca3e690c31e20
    │   └── linux-c11bcda2cde58ad6ed2ff9c94995baf76aea3680
    ├── 6.15.5-1-default
    │   ├── initrd-0b728b0f67d1e866f3c06e942b8010c20a6f4b42
    │   └── linux-6ce52d0f484a5ed8a7600c306fd820b971ab145e
    ├── 6.16.0-rc5-1.gbad2c39-default
    │   ├── initrd-280bbe3185aa832c7e27f8b743e29b7c59dca210
    │   └── linux-11705b7768d44a69bc817fb8a7caf493a1875c54
    ├── 6.16.0-rc5-2.g2396b44-default
    │   ├── initrd-7b6a2b16a63a3ad12c880e169dc6e1f89d69b958
    │   └── linux-2ad065b7595145662a3ed5997b3a5e97933a8fdc
    ├── 6.16.0-rc6-1.g3743c47-default
    │   ├── initrd-97a96085f902e2bd1f011d58c45afb098292c9fa
    │   └── linux-add94190465871d6e03f016476cfb62f0b317676
    ├── 6.16.0-rc6-2.gcdcdcc9-default
    │   ├── initrd-378630182c90ac85ae3f4e5ee5ecc74b1ffd6636
    │   ├── initrd-e9c02d9332abe9e538578aa46817635229d8be44
    │   └── linux-c5346a449ef249afca6a3f0e15af42e73b05d946
    ├── 6.16.0-rc6-3.g493c219-default
    │   ├── initrd-0f319a1156f8a23f0d6c3566f8da36e883466d41
    │   ├── initrd-1edf059e795040c87b48bdb9d4a0de8463a88532
    │   └── linux-6de300a1cb7963ac663b51829d45cbb5c50c9a1c
    ├── 6.16.0-rc6-4.g490e080-default
    │   ├── initrd-a26fcb254b2a4ad92645339b7978aeffd71902cb
    │   └── linux-1ddf662e7ce50a747164c026514685f029b6ab02
    └── 6.16.0-rc6-5.gb9ba39a-default
        ├── initrd-677baf27f1aeafbd5c19dcadbfd02f15fa4310aa
        └── linux-1d295f8beac31620a34018c163f1aba94b2fe5f1

16 directories, 65 files

du -sh /boot/efi
453M	/boot/efi
32

Still true. You can create your own distro with EFI on reiserfs, ext2 for root and so on.
@malcolmlewis is using a proper quote which applies. Don’t dismiss that like this, please.

33

Thinking more about zram … I decided to check my current main PC, a Lenovo X1 Carbon generation-9, which I am now coming to the opinion, has wasted space with 16 GB assigned to /swap on its 1 TB nvme SSD drive.

I checked when running ffmpeg, creating a vector file that checks changes from frame to frame in a video, and saves such to file (for use in subsequent video processing) - where this is one of the more cpu/gpu intensive things I do on this laptop:

oldcpu@lenovo:~> free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi       4.8Gi       7.1Gi       549Mi       4.4Gi        10Gi
Swap:           16Gi          0B        16Gi
oldcpu@lenovo:~>

and then I checked running ffmpeg, this time creating a new video from the old, using the vector file to stabilize the content and have a smoother video:

oldcpu@lenovo:~> free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi       5.2Gi       6.5Gi       756Mi       4.7Gi        10Gi
Swap:           16Gi          0B        16Gi
oldcpu@lenovo:~>

Which pretty much confirms … swap is not used. So unless hibernation is of a major importance (and I can’t recall the last time I used hibernation on my laptops) I do not need a separate swap partition, and instead I should go with zram.

So I am asking myself, when should I sort my partitioning on my laptop PCs?

I plan to do some global traveling (Asia / North America) in Oct/Nov this year. And LEAP-16.0 release is planned for October. I don’t want to do anything to my primary laptop, without having my backup plan in place (ie my wife’s old laptop together with an external boot nvme SSD in place).

The hardware I ordered should arrive in a few days, and likely I will play around with such for a few weeks before I am happy with it. So it will be August or early September before I am happy with the backup. But I want time to also plan my upcoming travel (flights, car rentals, train booking, hotel bookings, planning some entertainment that requires booking in advance) for my Oct/Nov travels.

So possibly for my main laptop PC I will wait until late November, and then in November wipe everything off of my main laptop (Lenovo X1 carbon gen-9) and as part of a LEAP-16.0 install, assign the partition space in a more ‘up to date’ manner, given considerations in regards to /swap (not needed) and this laptop’s EFI (its too small).

… and in the meantime, BEFORE then, maybe starting ONE week from now, with my wife’s older Lenovo X1 carbon generation-4 and the external nvme SSD enclosure (with SSD inside) as a backup PC, I can explore and play a bit with what I have learned in this thread.

34

@oldcpu and that’s another change with secure boot and kernel lockdown, no hibernation, just suspend to ram… :wink: Whn you get a moment as root user run fwupdmgr security to see…

35

Stopping the grumbling is indeed the hard part. Don’t worry about “putting new hardware in a old laptop that could fail any day”. If the laptop fails move the new SSD to a working laptop, desktop or mini-pc. I am moving components since a decade.

1 Like
36

Wow ! That is an interesting report. I decided to change nothing at first, but i may rerun that later and change one or two things. I ran it on my primary laptop computer, a Lenovo X1 Carbon Generation 9.

oldcpu@lenovo:~> sudo fwupdmgr security
[sudo] password for root: 
Host Security ID: HSI:0! (v1.9.10)

HSI-1
✔ BIOS firmware updates:         Enabled
✔ MEI key manifest:              Valid
✔ csme manufacturing mode:       Locked
✔ csme override:                 Locked
✔ csme v0:15.0.50.2633:          Valid
✔ Platform debugging:            Disabled
✔ SPI write:                     Disabled
✔ SPI lock:                      Enabled
✔ SPI BIOS region:               Locked
✔ Supported CPU:                 Invalid
✔ UEFI bootservice variables:    Locked
✔ UEFI platform key:             Valid
✘ TPM v2.0:                      Not found

HSI-2
✔ BIOS rollback protection:      Enabled
✔ Intel BootGuard ACM protected: Valid
✔ Intel BootGuard:               Enabled
✔ Intel BootGuard OTP fuse:      Valid
✔ Intel BootGuard verified boot: Valid
✔ Intel GDS mitigation:          Enabled
✔ IOMMU:                         Enabled
✔ Platform debugging:            Locked

HSI-3
✔ Intel BootGuard error policy:  Valid
✔ Intel CET Enabled:             Enabled
✔ Pre-boot DMA protection:       Enabled
✘ Suspend-to-idle:               Disabled
✘ Suspend-to-ram:                Enabled

HSI-4
✔ Intel SMAP:                    Enabled
✘ Encrypted RAM:                 Not supported

Runtime Suffix -!
✔ fwupd plugins:                 Untainted
✔ Linux kernel:                  Untainted
✘ Intel CET Active:              Unknown
✘ Linux kernel lockdown:         Disabled
✘ Linux swap:                    Unencrypted
✘ UEFI secure boot:              Disabled

This system has a low HSI security level.
 » https://fwupd.github.io/hsi.html#low-security-level

This system has HSI runtime issues.
 » https://fwupd.github.io/hsi.html#hsi-runtime-suffix

╔══════════════════════════════════════════════════════════════════════════════╗
║ Configuration Change Suggested: UEFI Secure Boot                             ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ UEFI Secure Boot prevents malicious software from being loaded when the      ║
║ device starts.                                                               ║
║                                                                              ║
║ This tool can change the BIOS setting 'com.thinklmi.SecureBoot' from         ║
║ 'Disable' to 'Enable' automatically, but it will only be active after        ║
║ restarting the computer.                                                     ║
║                                                                              ║
║ You should ensure you are comfortable restoring the setting from the system  ║
║ firmware setup, as this change may cause the system to not boot into Linux   ║
║ or cause other system instability.                                           ║
╚══════════════════════════════════════════════════════════════════════════════╝
Perform operation? [y|N]: N
╔══════════════════════════════════════════════════════════════════════════════╗
║ Configuration Change Suggested: Suspend To Idle                              ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ Suspend to Idle allows the device to quickly go to sleep in order to save    ║
║ power. While the device has been suspended, its memory could be physically   ║
║ removed and its information accessed.                                        ║
║                                                                              ║
║ This tool can change the BIOS setting 'com.thinklmi.SleepState' from         ║
║ 'Linux' to 'Windows10' automatically, but it will only be active after       ║
║ restarting the computer.                                                     ║
║                                                                              ║
║ You should ensure you are comfortable restoring the setting from the system  ║
║ firmware setup, as this change may cause the system to not boot into Linux   ║
║ or cause other system instability.                                           ║
╚══════════════════════════════════════════════════════════════════════════════╝
Perform operation? [y|N]: N
Upload these anonymous results to the Linux Vendor Firmware Service to help other users? [y|N]: N
Ask again next time? [Y|n]: Y
oldcpu@lenovo:~>

So I have low HSI security and HSI runtime issues. … hmm…

37

Indeed ! You are 100% correct.

Stopping the grumbling is indeed the hard part. But such is married life. lol !!

I can’t complain thou, because in the end I obtained agreement to both buy the nvme SSD and buy an (albeit inexpensive slow USB-3.1 gen1) external SSD enclosure.

I can still technically put the new 1TB SSD in the old Lenovo X1 Carbon gen-4 at sometime in the future (as I will have the 1TB SSD in my possession) and plus I will have an SSD external enclosure which might come in handy in the future.

And also now, when traveling, in addition to taking with me my primary Lenovo X1 carbon, I can take with me the external SSD enclosure that will have openSUSE LEAP-15.6 on it, as such an external SSD enclosure should be very light weight. It can be seen as a sort of mobile backup.

I am curious to see, after such is setup on the external SSD, if will it run on more than just the Lenovo X1 carbon-gen-4 that I will use to configure it initially.

This may ultimately work out for the better. First and foremost my wife is happy with this approach. Secondly in the future I still have the technical option to put the 1TB SSD in the old Lenovo-X1 carbon gen-4, and thirdly, I have an extra electronic ‘toy’ (the external SSD enclosure) to add to my list of (practical) ‘toys’.

lol !

.

38

Thinking about this, I took a look at some of the upgrades planned for Leap-16.0.

… if I read such correctly, this is a major change.

It has me thinking now, to avoid a major shock in November if and when I go to totally change the partitions on my primary Lenovo X1 Carbon laptop to LEAP-16.0, that I should give thought to installing the LEAP-16.0 beta on my old desktop PC (which has spare empty partitions I could put LEAP-16.0 in).

Years back I used to always test the Beta versions, but as I grew older, I developed interest in other technical areas, and also I came away with the feeling that my testing did not add anything to the overall effort to get the Beta versions to work.

But now when I consider my plan (which I have not yet mentioned) to ultimately dispose of my old desktop PC, and only use my laptop(s), that to avoid shock and learn more before November this year, that I should install LEAP-16.0 beta on my desktop in a spare partition.

Again - when i read the extent of the changes coming in LEAP-16.0 , assuming I read such correctly, this will be a very big change, requiring a different view in regard to many aspects of LEAP. Possibly the biggest change since I started using openSUSE decades ago.

I see this as another piece of my update puzzle with the external nvme SSD enclosure as a backup, where i will preserve LEAP-15.6 while I try to figure out LEAP-16.0.

39

To avoid a possible waste of time, on that “old” PC, do:

# /lib64/ld-linux-x86-64.so.2 --help | tail -11
This program interpreter self-identifies as: /lib64/ld-linux-x86-64.so.2

Shared library search path:
  (libraries located via /etc/ld.so.cache)
  /lib64 (system search path)
  /usr/lib64 (system search path)

Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)
#

You need to see at least one (supported, searched) in your output to have support for 16’s minimum CPU requirement.

40

There are other ways to check (less typing too :slightly_smiling_face: )

https://en.opensuse.org/X86-64_microarchitecture_levels#Checking_your_CPU_for_compatibility_with_x86-64-v2