The installer failed to create a partition table on INTEL SSDPEKNW010T8

I was trying to install EndeavourOS Sway from the Apollo 22_1 iso when I got the following error: “The installer failed to create a partition table on INTEL SSDPEKNW010T8.”

The disk was clean previously with:

sfdisk --wipe=always /dev/nvme0n1

and everything looked fine from the various CLI utilities showing a gpt having /dev/nvme0n1p1 of 512M EFI and /dev/nvme0n1p2 of 953.4G for a 1 TB device. However, I got the error after installing from the Apollo 22_1 iso written to USB and attempting to install Sway. I’m attatching the term bin for clarity.

There seem to be some conditions in the current generation of linux kernel that cause this nvme to disappear from the system entirely as I’ve seen this happen with numerous other linux installers regardless of arch, debian, or fedora lineage.

Is it possible that the disk is wearing out?
Can you run other operating systems on it?

Did you try an alternate method of booting on the live ISO and use gparted first to create a new GPT partition on the drive. Then close gparted and run the installer using erase disc with swap file and ext4 or other choice.

Thanks for your respoonse.

I’m not sure what you mean when you say, “an alternate method of booting”?

Yes, I did use gparted and various CLI tools to create a new GPT partition previously. The behavior starts with the installer not being able to see the nvme at all. lspci and lshw can generally see it, fdisk and sfdisk vary.

I’ve been able to install manjaro on this device. Other distros have typically seen boot problems with this device which seem to be related to the NVidia kernel and its relationship to sway. Really recent kernels seem to be addressing this. When I saw recent kernels, I mean in the last week or so. Non-proprietary kernels vary with respect to the behavior of the nvme. It’s difficult to see a pattern to what the nvme visibility is, but it occurs across a diverse set of distro derivatives, thus my intuition about the kernel.

Thanks for your response.

Possible, but all the hardware diagnostics finish without errors. Willing to try any suggestion here.

Yes, Windows ran with blue screens that were never resolved, even after installing the latest BIOS and OS stacks from Asus several times over several months.

Manjaro runs fine. The 5.15 and 5.16 minimal as 3/27/2022 from github seem to work without issue:

I didn’t mean an alternate method of booting. I just wondered if you used an alternate method of creating a new Partition on the drive as you stated you cleaned the disk with a dd command. Just wondered if you tried other methods of creating the partitions. But i didn’t realize also that it doesn’t see the disk. Does Bios have (RST) Intel Rapid Storage and raid setting? It needs to be set to AHCI not Raid. So RST needs to be disabled and set to AHCI.

Do you have the same problem if you only run gparted to create the partition table?