How to get NVMe working on MBP 13,1 about mbp-2016-linux

[Dunedan]

Booting a live or installation media, enabling the NVMe workaround and then installing it to disk is definitely the right approach. I installed Debian the same way on my MBP.

Regarding the black screen all I can suggest is:

• Check that intremap=nosid is properly set as kernel boot parameter as described in https://github.com/Dunedan/mbp-2016-linux#booting
• Try booting with nomodeset as kernel boot parameter to disable kernel based modesetting. This should give you readable output of what's going on.
• If you get output but no proper complete boot process without an obvious error message, try it multiple times. It might work after a few times trying to boot.
• Installing a recent kernel (4.10 or newer) can help. Previous versions had some problems with graphical output during boot.

[christophgysin]

You will need to apply the NVMe workaround also in the installed system, before attempting to mount the rootfs. I just installed archlinux and added a hook to mkinitcpio that applies the NVM workaround:

$ cat /lib/initcpio/hooks/mbp-nvme
#!/usr/bin/ash

run_hook() {
    modprobe nvme
    echo 106b 2003 > /sys/bus/pci/drivers/nvme/new_id
}

$ cat /lib/initcpio/install/mbp-nvme
#!/bin/bash

build() {
    add_module nvme
    add_runscript
}

$ sudo mkinitcpio -p linux

I don't use ubuntu, so I'm not familiar how to apply this there.

[Dunedan]

Good news regarding NVMe: Starting from Linux 4.11 all these workarounds to get it working, won't be neccessary anymore. 😄

[tudorbarascu]

@Dunedan Did you install Linux on the Apple SSD or are you booting from external storage?
The reason I'm asking this is because I want to do it these days and I'm searching for potential issues.
Thanks a lot!

[christophgysin]

I'm not Dunedan, but I booted linux-4.10 from a USB installation media, manually applied the NVMe workaround, installed to the Apple SSD, set up the workaround above in the initrd to allow booting 4.10 off the SSD.

When 4.11 is released and available by your distro, the initrd hook becomes unnecessary. When your installation media contains 4.11, it should work out of the box.

[tudorbarascu]

@christophgysin Thanks. I installed it.
However, I've noticed a rare bug. Sometimes, at boot time the root partition cannot be mounted and I'm stuck into the intramfs shell. I'm trying to mount manually but I'm getting some async error.
When @Dunedan added the patch, looking at the file I noticed some ifs that may have a connection to what I'm encountering, e.g:

	/*
	 * Temporary fix for the Apple controller found in the MacBook8,1 and
	 * some MacBook7,1 to avoid controller resets and data loss.
	 */
	if (pdev->vendor == PCI_VENDOR_ID_APPLE && pdev->device == 0x2001) {
		dev->q_depth = 2;
		dev_warn(dev->dev, "detected Apple NVMe controller, set "
			"queue depth=%u to work around controller resets\n",
			dev->q_depth);
	}

I plan on looking at that and maybe create a patch if that's the culprit.

Has anyone else encountered this?

[christophgysin]

Yes, I've seen that too.

[Dunedan]

Me too. I have that pretty regularly nowadays actually. Haven't had that problem 1-2 months ago, which lead me to the conclusion that it's not related to that workaround for the other MacBooks, but maybe it is anyway.

One thing to note: For me it happens only during boot. Once access to the NVMe controller works it'll continue to work the whole time the MBP stays on. A wild idea I had this morning is that it could be related to not issuing the proper vendor specific command on shutdown, Apple apparently sends (cb22/macbook12-spi-driver#2 (comment)).

In any case keep in mind that the quoted kernel source is just a workaround and no proper solution.

[tudorbarascu]

@Dunedan I did the fix and it seems to work, It's the same workaround, but it seems to work as I restarted 10 times already and it doesn't appear anymore.

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 26a5fd0..e78c8ae 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -1618,7 +1618,7 @@ static int nvme_pci_enable(struct nvme_dev *dev)
         * Temporary fix for the Apple controller found in the MacBook8,1 and
         * some MacBook7,1 to avoid controller resets and data loss.
         */
-       if (pdev->vendor == PCI_VENDOR_ID_APPLE && pdev->device == 0x2001) {
+       if (pdev->vendor == PCI_VENDOR_ID_APPLE && (pdev->device == 0x2001 || pdev->device == 0x2003)) {
                dev->q_depth = 2;
                dev_warn(dev->dev, "detected Apple NVMe controller, set "
                        "queue depth=%u to work around controller resets\n",

Hopefully it won't appear anymore.

[tudorbarascu]

Unfortunately, it has appeared. It seems I had a lucky streak those 10 times.

[ManWithCamera]

This post contains a link to download a script called isorespin.sh which can modify an Ubuntu/Mint ISO file and update the kernel to 4.11: http://linuxiumcomau.blogspot.com/2017/04/creating-personalized-ubuntu-mint-and.html?m=1

It makes it easy to resolve the issue of not being able to see the NVMe SSD. Now I just need to figure out how to get the built-in keyboard and track pad working...

[Dunedan]

@tudorbarascu Regarding the issue with the NVMe controller not working every boot, I have no solution, but at least some new insights. The patch from #1 (comment) makes the problem way, way worse. I don't know how and why, but I thought it's information worth sharing. Without the patch it only happens rarely, but with it it happened most of the time for me. Was a real pain in the ass to get it properly booted with it.

[peterychuang]

I'm wondering if there's any progress on this NVMe problem on boot (and I guess suspend/resume problem is perhaps the same issue?).

[Dunedan]

To document the link to the Bugzilla case you opened here as well: https://bugzilla.kernel.org/show_bug.cgi?id=196503

[peterychuang]

Thanks @Dunedan.

I've just upgraded to systemd 234 on Arch Linux earlier today, and since then this problem has got worse somehow. In fact, none of my attempts to boot was successful when the initramfs was built with systemd hooks. I'm not entirely sure why.

[Dunedan]

I'm running systemd 234 since a few days as well, but I saw no change in the behavior.

[peterychuang]

It's probably a systemd problem, and has nothing to do with whether NVMe initialises correctly at boot.

[jgmbenoit]

Hi everyone,

On 28/07/17 01:16, Peter Y. Chuang wrote: It's probably a systemd problem <https://bugs.archlinux.org/task/54825>, and has nothing to do with whether NVMe initialises correctly at boot.

Have you given a try on system V or OpenRC system ? hth,Jerome

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIFYLOkSXzbIf2cxsCVl1FZZPHFapaiGks5sSP4igaJpZM4M6cIT>.

-- Jerome BENOIT, Ph.D. | jgmbenoit-at+rezozer*dot_net http://www.rezozer.net/

[peterychuang]

@Dunedan what seems strange to me, now that I've got around the systemd problem (and playing with linux-next at the moment), is that the delay in finding my encrypted partition is very consistent: exactly 1 minute. I'm having 100% boot success rate, but most of the time I have to wait for exactly a minute before I can enter my passphrase.

[Dunedan]

I up to one of your previous comments didn't even bother to wait. Once I encountered a timeout I'd simply reboot under the assumption that it wouldn't work otherwise. Based on your comments I tried out leaving it after the timeout occurs and indeed, I then just have to wait another 30 or 60 seconds until it works. I'll continue to observe if that's always the case.

[peterychuang]

Output of dmesg | grep nvme when there's a one-minute delay

[    1.897927] nvme nvme0: pci function 0000:01:00.0
[    2.115140]  nvme0n1: p1 p2
[   32.373664] nvme nvme0: I/O 88 QID 1 timeout, completion polled
[   62.320322] nvme nvme0: I/O 3 QID 0 timeout, completion polled

Perhaps something to do with this, but not sure what that means.

[roadrunner2]

@peterychuang Btw., which model do you have? I thought you had mentioned you had a 13,3 somewhere, but can't find it right now. The reason I'm asking is that my 13,3 has a Samsung controller, so if you have the Apple controller, then my assumption about the controller being model related is wrong, and it may be disk size related instead.

[peterychuang]

@roadrunner2 mine is 14,1, which has the Apple controller.

Edit:

Speaking of disk size, you reminded me of something quite weird. This is the first laptop with NVMe I have, so I don't know how it's supposed to work, but is it normal to have lsblk looking like this?

NAME                                       MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
nvme0n1                                    259:0    0   113G  0 disk  
├─nvme0n1p1                                259:1    0   500M  0 part  /boot
└─nvme0n1p2                                259:2    0 112.5G  0 part  
  └─luks-469a7520-db5c-41d2-830c-83821cc410ba
                                           254:0    0 112.5G  0 crypt 
    ├─vol-swap                             254:1    0     8G  0 lvm   [SWAP]
    └─vol-root                             254:2    0 104.5G  0 lvm   /
nvme0n2                                    259:3    0     8K  0 disk  

What's that 8K nvme0n2 thing?

[roadrunner2]

@peterychuang Interesting: it looks like you have a second nvme namespace - no idea what that's doing there, though - I don't see that on my system. Not sure if anything in /sys/class/nvme/nvme0/nvme0n2/ would shed any more light on it.

[peterychuang]

@roadrunner2 nvme0n2 is present in 13,1, 13,2, and 14,1. Most probably in 14,2 too.

[peterychuang]

I just want to point out that when it drops to emergency shell after timing out, I can still boot into the machine by mounting the root partition to /new_root manually then exiting the shell:

cryptsetup luksOpen /dev/nvme0n1p2 arch
mount /dev/mapper/vol-root /new_root
exit

I haven't tried this enough times to say this works 100% of the time though.

[l1k]

@roadrunner2: About that second nvme namespace: Linux 4.13 has support for the Alpine Ridge Thunderbolt controller built into 2016+ MacBook Pros and exposes the EEPROM on each controller as an nvmem device. And @peterychuang mentions above that he's playing with linux-next, so he's already got all the 4.13 material and then some. I suspect that's where the second nvme namespace is coming from. If this theory is correct there should be a third one on models with two Thunderbolt controllers.

[Dunedan]

@l1k: I just had a look on my MacBookPro13,2 which has two Thunderbolt controllers, but I only got the same second namespace as @peterychuang and no third one with Linux 4.13.0-rc1.

[peterychuang]

@l1k I've just gone back to the stock kernel of Arch, which is 4.12.4 at the moment. The second namespace is present there too.

[Dunedan]

Ok, /dev/nvme0n2 definitely belongs to the SSD. At least if we can trust nvme-cli:

root@mbp:~$ nvme list
Node             SN                   Model                                    Namespace Usage                      Format           FW Rev  
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1     C02649400XFXXXXXX    APPLE SSD AP0512J                        1         500,28  GB / 500,28  GB      4 KiB +  0 B   14.17.01
/dev/nvme0n2     C02649400XFXXXXXX    APPLE SSD AP0512J                        2           8,19  kB /   8,19  kB      4 KiB +  0 B   14.17.01
root@mbp:~$ nvme list-ns --namespace-id=1 /dev/nvme0
[   0]:0x747ae15
[   2]:0x747ae15
[   4]:0x747ae15
[  30]:0x706e4261
[  31]:0x50241
[  32]:0xc0000
[  96]:0x1
root@mbp:~$ nvme list-ns --namespace-id=2 /dev/nvme0
[   0]:0x2
[   2]:0x2
[   4]:0x2
[  30]:0x706e4261
[  31]:0x50241
[  32]:0xc0000
[  96]:0x6

Maybe the second namespace is the EEPROM of the SSD?

What's also interesting is the SMART-log:

root@mbp:~$ nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0
temperature                         : 40 C
available_spare                     : 86%
available_spare_threshold           : 2%
percentage_used                     : 0%
data_units_read                     : 14.963.057
data_units_written                  : 11.077.822
host_read_commands                  : 50.869.020
host_write_commands                 : 171.605.283
controller_busy_time                : 0
power_cycles                        : 1.087
power_on_hours                      : 1.173
unsafe_shutdowns                    : 413
media_errors                        : 0
num_err_log_entries                 : 0
Warning Temperature Time            : 0
Critical Composite Temperature Time : 0

Notice the unsafe shutdowns in there? That's probably the sum of all shutdowns of this MacBook Pro so far.

[roadrunner2]

@l1k AFAIK, NVMEM (Non Volatile Memory subsystem) and NVMe (NVM Express) are not related to each other, despite the very similar names. So I would not expect to see nvmem devices show up under nvme.

On 4.13 I indeed see that the thunderbolt module is using the nvmem_core module, though I don't see any devices or drivers under /sys/bus/nvmem/ (and needless to say, the thunderbolt device doesn't show up under nvme).

[l1k]

@roadrunner2 @peterychuang: Oops then I was mistaken, sorry for the noise. :)

[peterychuang]

I've many unsafe_shutdowns too because of all the forced powering down after failed boots.

I am pretty new in the kernel stuff, so I may be completely wrong. The dmesg output for when the disk fails to "start up" properly--e.g.: nvme nvme0: I/O 88 QID 1 timeout, completion polled--most probably comes from this commit. Which means this is about missing interrupts, I guess?

I'm just poking around, and this is perhaps totally irrelevant, but my DSDT has the following chunk:

Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
{
    If ((NVME == One))
    {
        Local0 = Package (0x06)
            {
                "deep-idle", 
                One, 
                "use-msi", 
                One, 
                "nvme-LPSR-during-S3-S4", 
                One
            }
    }
    ElseIf ((NVME == 0x02))
    {
        Local0 = Package (0x04)
            {
                "use-msi", 
                One, 
                "ssd-off-in-S4", 
                One
            }
    }

    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
    Return (Local0)
}

[peterychuang]

It appears the NVMe problem at boot has gone on stock Arch Linux kernel (4.15.1). Can anyone confirm this?

[christophgysin]

Indeed, I haven't seen this anymore with 4.15.2 (haven't tried 4.15.1).

[Dunedan]

Just to be clear: When talking about "the NVMe problem", you're talking about the occasional NVMe timeouts during boot?

[peterychuang]

@Dunedan Correct.

[Dunedan]

I still see this issue with 4.15.2 (self-compiled kernel and running Debian).
I also dug through the recent changes in the NVMe implementation in the Linux kernel and didn't find anything in there which would explain a sudden disappearing of the problem. So if this problem is really gone for you, it might be related to something else than the kernel.

[christophgysin]

I haven't seen the issue yet with tens of boots of 4.15.2-ARCH. With older arch kernels and my self-compiled 4.14 it happened almost every single boot. So something cerainly must have changed in the kernel.

[peterychuang]

I haven't had any problem for about three days now since 4.15.1. I'm not sure what NVMe changes in the kernel could be responsible for this either. If it wasn't the kernel, I am guessing perhaps firmware update might have helped? Have you upgraded to High Sierra 10.13.3?

[christophgysin]

I haven't upgraded to High Sierra, and I can still reproduce the problem by booting older kernels.

[roadrunner2]

I might be good to compare kernel configs too (preferably same major version, e.g. 4.15).

[peterychuang]

This is what the config looks like on the latest Arch Linux's stock kernel:

#
# NVME Support
#
CONFIG_NVME_CORE=y
CONFIG_BLK_DEV_NVME=y
CONFIG_NVME_MULTIPATH=y
CONFIG_NVME_FABRICS=m
CONFIG_NVME_RDMA=m
CONFIG_NVME_FC=m
CONFIG_NVME_TARGET=m
CONFIG_NVME_TARGET_LOOP=m
CONFIG_NVME_TARGET_RDMA=m
CONFIG_NVME_TARGET_FC=m
CONFIG_NVME_TARGET_FCLOOP=m

CONFIG_NVME_MULTIPATH wasn't present on 4.14. Also, CONFIG_NVME_TARGET_FCLOOP was not set on Arch's 4.14.y kernels.

[Dunedan]

So, while I still had that problem with Linux 4.15 since upgrading to 4.16rc1 and installing macOS 10.13.3 I haven't seen this issue again, so I tend to believe it's now gone for good. Would be good though to know what caused it to disappear.

[peterychuang]

I just had my first problem at boot since more than a month ago, so perhaps you are right that it hasn't been completely solved in 4.15.y. I don't really have time to mess with the mainline or next kernel these days, so I'll wait until 4.16 is officially out to see how that goes.

[Dunedan]

After another two months without a single time this problem appeared again for me, I'm closing this issue now.

If somebody encounters this problem again, please check if the latest macOS updates are installed. If yes, feel free to reopen this issue.

[mtoohey31]

Hello! I'm experiencing what I think is this problem again on distros running Linux kernels 4.18 and newer. I would be grateful for any support/suggestions that anyone has.

nvme list shows nothing, and dmesg | grep nvme shows
[1.171649] nvme nvme0: pci function 0000:04:00.0
[1.176950] nvme nvme0: detected Apple NVMe controller, set queue depth=2 to work around controller resets
[1.205005] nvme nvme0: IO queues not created

Let me know if there's any other information that's needed.

[Dunedan]

@Ninja73737 Your issue seems to be a new different one than the one discussed in here, so please open a separate Github issue for it.

[leifliddy]

someone posted a bugreport for the macbook8,1 (2015 12-inch), running kernel 5.2
https://bugzilla.kernel.org/show_bug.cgi?id=205835

[    1.542064] nvme nvme0: pci function 0000:03:00.0
[    1.542436] nvme nvme0: detected Apple NVMe controller, set queue depth=2 to work around controller resets
[    1.543340] nvme nvme0: IO queues not created

[mtoohey31]

@leifliddy Thanks for letting me know, I'll keep an eye on that!

[leifliddy]

I wonder if that patch is actually causing the issue.
http://lists.infradead.org/pipermail/linux-nvme/2015-December/003387.html

Four years is a long time for a temporary patch. Perhaps the underlying issue has already been fixed.

nvme is normally compiled as a module right?

CONFIG_NVME_CORE=m
CONFIG_BLK_DEV_NVME=m

Can't we just remove that patch and rebuild the nvme module and see if that works.
I'll try that tomorrow....

BTW, I have a macbook9,1 with a slightly updated nvme controller :2003 vs :2001 (which is not affected by that patch)
..and it works fine.

01:00.0 0180: 106b:2003 (rev 12)
	Subsystem: 106b:2003
	Kernel driver in use: nvme
	Kernel modules: nvme

01:00.0 Mass storage controller: Apple Inc. S3X NVMe Controller (rev 12)

#dmesg

[    2.981274] nvme nvme0: pci function 0000:01:00.0
[    3.197338] nvme nvme0: 1/0/0 default/read/poll queues
[    3.200118]  nvme0n1: p1 p2 p3 p4 p5
[   20.749441] Adding 8195068k swap on /dev/nvme0n1p4.  Priority:-2 extents:1 across:8195068k SSFS
[   22.455723] EXT4-fs (nvme0n1p3): mounted filesystem with ordered data mode. Opts: (null)

[AquaMCU]

Hi. I am the one reporting that issue on the kernel bugtracker.
Here is the kernel version:
Linux ubuntu-budgie 5.3.0-18-generic #19-Ubuntu SMP Tue Oct 8 20:14:06 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
And the Kernel config
CONFIG_NVME_CORE=m
CONFIG_BLK_DEV_NVME=m
CONFIG_NVME_MULTIPATH=y
CONFIG_NVME_FABRICS=m
CONFIG_NVME_RDMA=m
CONFIG_NVME_FC=m
CONFIG_NVME_TCP=m
CONFIG_NVME_TARGET=m
CONFIG_NVME_TARGET_LOOP=m
CONFIG_NVME_TARGET_RDMA=m
CONFIG_NVME_TARGET_FC=m

CONFIG_NVME_TARGET_FCLOOP is not set

CONFIG_NVME_TARGET_TCP=m

end of NVME Support

[leifliddy]

AqauMCU sent me his dmesg log

[    1.006039] nvme nvme0: pci function 0000:03:00.0
[    1.006405] nvme nvme0: detected Apple NVMe controller, set queue depth=2 to work around controller resets
[    1.007350] nvme nvme0: IO queues not created
...
[  103.866495] 0000:00:15.5: ttyS4 at MMIO 0xc1819000 (irq = 21, base_baud = 2764800) is a 16550A
[  103.866556] serial serial0-0: controller busy
[  103.866559] serial serial0-0: failure adding ACPI serdev device. status -16
[  103.866561] serial serial0: tty port ttyS4 registered
....
[  104.774723] irq 21: nobody cared (try booting with the "irqpoll" option)
[  104.774728] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.3.0-24-generic #26-Ubuntu
[  104.774729] Hardware name: Apple Inc. MacBook8,1/Mac-BE0E8AC46FE800CC, BIOS MB81.88Z.0164.B25.1702161608 02/16/2017
[  104.774729] Call Trace:
[  104.774731]  <IRQ>
[  104.774736]  dump_stack+0x63/0x8a
[  104.774740]  __report_bad_irq+0x3a/0xaf
[  104.774742]  note_interrupt.cold+0xb/0x61
[  104.774744]  handle_irq_event_percpu+0x73/0x80
[  104.774746]  handle_irq_event+0x3b/0x5a
[  104.774748]  handle_fasteoi_irq+0x9c/0x150
[  104.774751]  handle_irq+0x20/0x30
[  104.774753]  do_IRQ+0x50/0xe0
[  104.774756]  common_interrupt+0xf/0xf
[  104.774756]  </IRQ>
...
[  104.774788] [<00000000b4b77e32>] ssp_int [spi_pxa2xx_platform]
[  104.774789] Disabling IRQ #21
[  104.836489] applespi spi-APP000D:00: SPI transfer timed out
[  104.836616] applespi spi-APP000D:00: Error reading from device: -110
[  104.836625] spi_master spi0: failed to transfer one message from queue

looks like this is an IRQ assignment issue...

which is detailed here:
cb22/macbook12-spi-driver#71

the possible solutions listed (macbook 8,1) are to:

1. add these modules to the initramfs image
   applespi
   spi_pxa2xx_platform
   spi_pxa2xx_pci

2. boot with 'irqfixup' kernel parameter

3. boot with 'irqpoll' kernel parameter

[Dunedan]

Guys, please. You're currently discussing a separate topic than this issue is about, so please also open a separate one.

[leifliddy]

That's exactly what I was trying to do by highlighting the fact that there's another thread discussing the exact issue that both Ninja73737 and AqauMCU are experiencing.
Since I didn't explicitly state it....
Guys, let's move this discussion to:
cb22/macbook12-spi-driver#71

[npx001]

i know here is not the place but wanted to help
about apple ssd with device id 0x2001 - did not create IO queues

edit kernel/drivers/nvme/host/pci.c and modify
static const struct pci_device_id nvme_id_table[] = {
......
replce { PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2001) },
with { PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2001),
add .driver_data = NVME_QUIRK_SINGLE_VECTOR },

tested with kernel 5.4.5 and works so far
hope it helps someone
thanks

[andy-shev]

i know here is not the place but wanted to help
about apple ssd with device id 0x2001 - did not create IO queues
...
tested with kernel 5.4.5 and works so far
hope it helps someone

Are you going to submit this upstream?

[npx001]

Are you going to submit this upstream?

no idea yet,
but will be nice if more users confirm
this patch work for them before
submitting anything

[leifliddy]

@npx001 I'm just curious. What macbook model do you have?

[andy-shev]

Here we are:
https://gist.github.com/andy-shev/469aef8dfcd8f5605cb8992cf5958769

File: mac-nvme-0x2001-disk-image.bin

Simple dd if=mac-nvme-0x2001-disk-image.bin of=/dev/sdX bs=1M && sync, where /dev/sdX is a USB stick (or any other tool for non-UNIX OSes that imitates dd, like rawrite or zillion of GUI variants).

Hi,

sorry if this is the very wrong place and time, but I have encountered an issue when installing POP!_OS 20.10 (dual-booting along a macOS APFS partition) on my MacBookPro13,1 to which this thread seems relevant. The installer.log reads

[INFO distinst:crates/disks/src/config/disk.rs:164] obtaining disk information from /dev/sda
[INFO distinst:crates/disks/src/serial.rs:14] obtaining serial model from /dev/sda
[INFO distinst:crates/disk-ops/src/parted.rs:31] opening disk at /dev/sda
[INFO distinst:crates/disks/src/config/partitions/mod.rs:112] obtaining partition information from /dev/sda1
[INFO distinst:crates/disks/src/config/disk.rs:164] obtaining disk information from /dev/nvme0n1
[INFO distinst:crates/disks/src/serial.rs:14] obtaining serial model from /dev/nvme0n1
[INFO distinst:crates/disk-ops/src/parted.rs:31] opening disk at /dev/nvme0n1
[INFO distinst:crates/disks/src/config/partitions/mod.rs:112] obtaining partition information from /dev/nvme0n1p1
[INFO distinst:crates/disks/src/config/partitions/mod.rs:112] obtaining partition information from /dev/nvme0n1p2
[INFO distinst:crates/disks/src/config/partitions/mod.rs:112] obtaining partition information from /dev/nvme0n1p3
[INFO distinst:crates/disks/src/config/disk.rs:164] obtaining disk information from /dev/nvme0n2
[INFO distinst:crates/disks/src/serial.rs:14] obtaining serial model from /dev/nvme0n2
[INFO distinst:crates/disk-ops/src/parted.rs:31] opening disk at /dev/nvme0n2
[INFO distinst:crates/disk-ops/src/parted.rs:37] unable to open disk; creating new table on it
[INFO distinst:ffi/src/disk.rs:452] unable to probe devices: failed to create new partition table on "/dev/nvme0n2": Invalid argument (os error 22)
[ERROR distinst:ffi/src/lib.rs:48] libdistinst: pointer in FFI is null
[ERROR distinst:ffi/src/lib.rs:48] libdistinst: pointer in FFI is null
[ERROR distinst:ffi/src/lib.rs:48] libdistinst: pointer in FFI is null
[ERROR distinst:ffi/src/lib.rs:48] libdistinst: pointer in FFI is null
[INFO distinst:crates/disks/src/config/disk.rs:164] obtaining disk information from /dev/sda
[INFO distinst:crates/disks/src/serial.rs:14] obtaining serial model from /dev/sda
[INFO distinst:crates/disk-ops/src/parted.rs:31] opening disk at /dev/sda
[INFO distinst:crates/disks/src/config/partitions/mod.rs:112] obtaining partition information from /dev/sda1
[INFO distinst:crates/disks/src/config/disk.rs:164] obtaining disk information from /dev/nvme0n1
[INFO distinst:crates/disks/src/serial.rs:14] obtaining serial model from /dev/nvme0n1
[INFO distinst:crates/disk-ops/src/parted.rs:31] opening disk at /dev/nvme0n1
[INFO distinst:crates/disks/src/config/partitions/mod.rs:112] obtaining partition information from /dev/nvme0n1p1
[INFO distinst:crates/disks/src/config/partitions/mod.rs:112] obtaining partition information from /dev/nvme0n1p2
[INFO distinst:crates/disks/src/config/partitions/mod.rs:112] obtaining partition information from /dev/nvme0n1p3
[INFO distinst:crates/disks/src/config/disk.rs:164] obtaining disk information from /dev/nvme0n2
[INFO distinst:crates/disks/src/serial.rs:14] obtaining serial model from /dev/nvme0n2
[INFO distinst:crates/disk-ops/src/parted.rs:31] opening disk at /dev/nvme0n2
[INFO distinst:crates/disk-ops/src/parted.rs:37] unable to open disk; creating new table on it
[INFO distinst:ffi/src/disk.rs:452] unable to probe devices: failed to create new partition table on "/dev/nvme0n2": Invalid argument (os error 22)
[ERROR distinst:ffi/src/lib.rs:48] libdistinst: pointer in FFI is null
[ERROR distinst:ffi/src/lib.rs:48] libdistinst: pointer in FFI is null
[ERROR distinst:ffi/src/lib.rs:48] libdistinst: pointer in FFI is null
[ERROR distinst:ffi/src/lib.rs:48] libdistinst: pointer in FFI is null

Could someone help me and tell me if this thread is right place to look for answers or point me in another direction? Thank you very much.