lsblk on -current installer shows partition with 1K, not 131.9G that was partitioned
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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:
Code:
Partition Size Partition Type
/dev/nvmen1p1 50M EFI
/dev/nvmen1p2 1G Swap
/dev/nvmen1p3 100G Linux
/dev/nvmen1p4 131.9G Linux
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):
Code:
NAME MAJ:MIN RM SIZE RO TYPE
nvme0n1 259:0 0 232.9G 0 disk
nvme0n1p1 259:5 0 50M 0 part
nvme0n1p2 259:6 0 1G 0 part
nvme0n1p3 259:7 0 100G 0 part
nvme0n1p4 259:8 0 1K 0 part
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...
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:
Code:
/dev/ sda2
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
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.
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.
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).
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:
Code:
# If the kernel does not support EFI, then we shouldn't be trying to mount an
# EFI partition. If we do, probably the only device found with an EFI structure
# will be the installer, which we don't want added to /etc/fstab.
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.
Last edited by Didier Spaier; 05-27-2019 at 10:14 AM.
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
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):
Code:
Disk /dev/nvme0n1: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Samsung SSD 970 EVO Plus 250GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5b4e67f2
Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 2048 104447 102400 50M ef EFI (FAT-12/16/32)
/dev/nvme0n1p2 104448 2201599 2097152 1G 82 Linux swap
/dev/nvme0n1p3 2201600 211916799 209715200 100G 83 Linux
/dev/nvme0n1p4 211916800 488397167 276480368 131.9G 83 Linux
Quote:
Originally Posted by Didier Spaier
PS and OT: I see this comment in SeTEFI:
Code:
# If the kernel does not support EFI, then we shouldn't be trying to mount an
# EFI partition. If we do, probably the only device found with an EFI structure
# will be the installer, which we don't want added to /etc/fstab.
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.
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.
Disk /dev/nvme0n1: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Samsung SSD 970 EVO Plus 250GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5b4e67f2
Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 2048 104447 102400 50M ef EFI (FAT-12/16/32)
/dev/nvme0n1p2 104448 2201599 2097152 1G 82 Linux swap
/dev/nvme0n1p3 2201600 211916799 209715200 100G 83 Linux
/dev/nvme0n1p4 211916800 488397167 276480368 131.9G 83 Linux
This output looks good, which doesn't give a clue why the output of lsblk in your first post didn't.
Quote:
But in a case like you mention, would the user really need an entry in the fstab?
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).
Last edited by Didier Spaier; 05-28-2019 at 04:10 AM.
This output looks good, which doesn't give a clue why the output of lsblk in your first post didn't.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.