lsblk on -current installer shows partition with 1K, not 131.9G that was partitioned
 

I'm running into an issue on the -current isntaller from 23 MAY (there's been updates, but it doesn't seem like they'd affect this and I didn't feel like redownloading the iso and dd'ing back to the usb drive).

To back up, I'm upgrading my HTPC to a Ryzen 3 2200G (and gifting my old system to my father-in-law). It is all new hardware, consisting of a Ryzen 3 2200G (APU -- CPU & GPU on the chip), 2x8GB RAM, MSI B450i motherboard, and a Samsung 970 EVO Plus 250GB NVMe drive.

I grabbed the latest (at the time) slackware-current iso from Alien Bob and dd'ed it to a stick. Then I found out the motherboard Amazon sent me was toast, so I did an advanced swap with them and that came in today (second one worked flawlessly). I put everything together and fired up the installer. I partitioned the device using fdisk initially, but switched to cfdisk, in case fdisk was the culprit (I get the same issue using either partitioner). I created the first 3 partitions using set sizes and the last one using the remaining space. They are as follows:

Both fdisk and cfdisk see the same partition layout and I've verified the partition types are as listed. But when lsblk is ran, I get the following output (minus the USB drive, since I'm manually typing this):

I'm going to continue with installation and see what happens, but I have no problem scrapping things and trying again (or updating my thumbdrive if it's possible some of the updates that happened on 25 MAY might make a difference). This can also let us know if it is a limitation of the busybox lsblk (which is what I'm assuming is being used) or some other glitch.

Any suggestions I should try? I'm curious if when I format the 4th partition what is going to happen...

And I have updates... albeit confusing updates.

So, once the installer finished, it went to the post-setup portion. It prompted me to skip lilo install since it detected EFI. I did that. I finished all the prompts and rebooted, only to find out that my motherboard didn't recognize my install. Then I realized that it never actually prompted me to install elilo.

So, I boot the installer back up, remount my swap and root partition and then go through the setup again. When I was adding the drives, it detected my EFI partition and asked if I wanted to format it (again... since it did this the first time). I agree. Later on it prompts me to skip lilo install, but then never prompts me to install elilo. I exit out of the installer and chroot into my root partition and try and run eliloconfig. It stated my EFI partition wasn't mounted. So I try mounting it and find it isn't formatted (or is formatted incorrectly). I run mkfs.vfat -F32 /dev/nvmen1p1 and successfully mount the EFI partition and am able to run eliloconfig. I now reboot and my motherboard sees the EFI install and I can boot off it. Awesome... I thought.

So, I get into Slackware and start going though my normal tweaking. Lo and behold, when I look at the fstab, I'm seeing some interesting things. The most interesting being that the installer had chosen the EFI partition off the USB drive rather than the partition on my NVMe drive. And even then, the entry lists the device with extra spaces in between the /dev/ and the device name:

I'm thinking the installer maybe prioritizes USB over NVMe when selecting EFI partitions? But I still have no idea what happened with my /home partition.

The installer also had not been able to format my /home partition (nvme0n1p4) and the entry in the fstab for it had the "type" blanked out. Once I formatted it manually and added the filesystem type in the fstab, everything worked fine.

I do have no problem wiping this and starting over if there's any diagnostics that should be run...

lsblk on -current installer shows partition with 1K, not 131.9G that was partitioned
 

Shouldn't you be using gdisk or cgdisk instead? I'd be using GPT partitions on hardware that new.

lsblk on -current installer shows partition with 1K, not 131.9G that was partitioned
 

To clarify my earlier post, fdisk/cfdisk can only make MBR partitions, which is the decades old standard that has several shortcomings. GPT partitions are the new standard and most likely what you want to use here.

fdisk and cfdisk have supported GPT since util-linux 2.23 (-current includes 2.33 and 14.2 included 2.27).

But after doing some research, it seems fdisk may default to MBR rather than GPT. To switch to GPT, you need to hit "g" first, which wipes the partition tables and will make all future ones GPT based. fdisk does not provide the ability to convert existing partitions from MBR to GPT, although, I believe gdisk does support that. I didn't do any of that, so I have since confirmed that my partitions are MBR.

Once I finish building my htpc software, I'll probably copy the packages to my desktop, wipe, and try again with GPT partitions to see if that makes any difference. However, considering my use doesn't run into any limits of MBR (less than 2TB and 4 primary partitions), I don't know if this would be the cause or not. I did find some sites that state that UEFI booting is not possible with MBR, but it seems to be working fine on my system. It is definitely booting UEFI since I didn't install lilo (/etc/lilo.conf doesn't even exist) and my motherboard sees it as a UEFI install. fdisk lists it as a dos partition table (MBR) and gdisk shows only MBR and no GPT.

But this won't happen until the morning because compiling kodi is taking its time, and it is getting close to 2AM.

I was unaware of that. Thanks for pointing it out!
I think that's only true if you intend to use inferior operating systems.

Under Linux, it should be fine... But I'd still use GPT wherever possible, especially on an NVMe drive.

I intended to, it was just an oversight on my part.

But it still feels like GPT vs MBR wouldn't affect my current issue unless the installer specifically checks for GPT EFI devices (and no clue why lsblk still only showed 1K for the 4th partition).

A few things:

• The installer prefers an EFI partition on the same drive as the target / partition it it exists, as shown in SeTEFI (attached, cf lines 34 through 44) which also shows that indeed the installer does not care for the partition table type or label (i.e., dos or gpt) when looking for EFI partitions.
• lsblk in the installer is a full featured binary, not a link to BusyBox.
• The output of lsblk in your first post is indeed weird as the sum of the sizes of the partition is not close to the size of the disk
• It would be interesting to know where each partition begin and ends, to check its size. For that you can type from the installer:
  Code:

  ---

  fdisk -l /dev/nvme0n1

  ---

PS and OT: I see this comment in SeTEFI:I disagree: The user could want to be able to boot the installed system in EFI mode, even if the machine booted in Legacy mode at time of installation, or move the drive where the system is installed on another machine, which will boot in EFI mode. And it is easy to exclude a partition on the same drive as the installer. Only my opinion, of course.

I did realize after the first post that lsblk was its own binary and not a link to busybox.

fdisk -l output is below (I haven't switched to GPT yet... other things happened today):

But in a case like you mention, would the user really need an entry in the fstab? But it seemed that whatever this section does to try and exclude the installer EFI from being added to the fstab didn't function correctly. I'm also wondering if maybe it formatted the installer partition instead of just failing to format the EFI partition on the NVMe drive.

Thanks for the points you brought up (and thanks to rkelson for making me realize I wasn't running GPT partitions). I still plan on wiping and reinstalling with a GPT partition table to see if there's any change in what happens.

(duplicate post)

This output looks good, which doesn't give a clue why the output of lsblk in your first post didn't.

No if the user intends to boot in legacy mode only. But having it wouldn't hurt. And a user who wants a clean /etc/fstab can still comment out the corresponding line if the drive is intended to stay in a machine which will boot only in Legacy mode (assuming that an EFI exists before running setup even in this case).

Yeah, I had wiped the paritions and recreated them with both fdisk and cfdisk and I always let the programs do their own math (I'd tell it to start at the default and then use +50M, +1G, +100G and then the default for the end of the last partition). Once I wipe it and try again, I'll have to try with both MBR and GPT partitions and fdisk/cfdisk/gdisk/etc partitioning programs to see if I can replicate the issue with lsblk.

The weird thing is lsblk recognizes everything properly now. I just had to manually format my /home partition, since the installer didn't detect it properly (due to lsblk not being able to detect it).

I'm still stumped on how I ended up with the USB drive'ss EFI partition in fstab and why the installer was unable to format my EFI partition (but that may be why it didn't prompt me to install elilo, even though it did prompt me to skip lilo -- I assume the latter was due to having EFI related stuff in /proc/ or /sys/ and the former due to it not having a properly formated EFI partition).

Hopefully I can find some reproducible instances so we can get down to the bottom of this.