Boot from NVMe disk help

Background story.
I have 2 SATA SSDs on my desktop. The 1st has the /boot and /root (as LVM), MBR partitioned the second is my /home (no partitions, the whole disk is an LVM PV/VG/LV)

I got a new NVMe installed on a PCIe adapter and the Motherboards recognize it, so, I want to use this as /boot, /root disk
What I want to do now is move the /boot and /root to the NVMe in order to free the SATA disk for other uses.
As far as I understand, in order to boot from the NVMe, I need GPT partition tables and UEFI boot.
Since I **don’t **want to re-install the OS, I was thinking the following:

  1. Create a GPT partition table on the NVMe
  2. Create a FAT32 /boot and somehow move the necessary files in it.
  3. Create the LVM but don’t move anything yet.
  4. Install boot loader in the /boot of the NVMe and reboot the machine (This should work since the /etc/fstab uses UUIDs :slight_smile: )
  5. If everything goes right, pvmove the /root LVM and enjoy the NVMe drive.

This is not the first time I move things between disks, for me is a second nature, so please don’t tell me how to do the trivial actions. What I need to know is how I will create the /boot with the necessary EFI options and if I need to do something special in order to boot in EFI mode (in terms of Grub2, Yast etc) as well as if you see any missing step in the above list.
Thanks in advance.

Don’t confuse /boot/ with /boot/efi/. /boot/ is just the same as always, a native partition/filesystem where kernels, initrds and various Grub files, including grub.cfg, go. With UEFI, they’re still there. The files you need to have on the new VFAT ESP partition on /boot/efi/ are not a part of your current installation.

I expect you’ll need to boot rescue media in UEFI mode, chroot into the installed system, put the new ESP into /etc/fstab, install grub2-x86_64-efi and its deps, “install bootloader” in UEFI mode, and ultimately, disable CSM booting.

I have migrated an MBR installation’s filesystem to a UEFI PC before, but the target PC was already configured to multiboot UEFI using TW’s Grub. I didn’t actually have to do much of anything to make the migration work, because of using the only UEFI entry in NVRAM, TW’s. I don’t mount the ESP for the migrated installation, and don’t have any of Grub or any other bootloader installed on it either.

A lot of acronyms :slight_smile:

OK, grub2-x86_64-efi seems like my starting point then.
Let’s see how it can help me.

I am bit confused.
On a RHEL 8 server, we have /boot and /boot/efi as 2 different partitions.
However, it seems that this is not necessary correct.
Can I create only the /boot/efi as a FAT32 partition and install everything there?

Or the /boot is still needed?

In order to boot from NVMe you need BIOS capable of booting from NVMe. Have you verified that your system actually supports it?

What is “everything”? The whole operating system?

You seem to be a bit confused. when this is my misunderstanding, sorry.

On /boot/efi the EFI partition is mounted to give access to it from inside your running Linux installation. Thus, yes, it is and should be a separate file system that is situated on the EFI partition of your boot disk.

/boot does not need to be on a separate file system by definition. It might be needed because e.g. your / file system is of a type that can not be accessed by your bootloader, or the bootloader can not access /boot because it is on some volume (RAID, Volume Manager). This is not normally the case in openSUSE (Btrfs can be understood by GRUB, I assume LVM can also because you use it like this). I know some Linux distributions create a separate file system for /boot by default. Thus you may have it, or may not have it. And when you have it, it may be on s separate partition, or on a LV (maybe more possibilities).

I do not understand what you mean with “Can I create only the /boot/efi as a FAT32 partition and install everything there”. What do you mean with “everything” here

Also, in your first post here, I read something strange: “The 1st has the /boot and /root”. It is a bad idea to put /root on a separate file system. As it is the home directory of root, it should always be there and thus, already a long time ago, the home directory of root was moved to /root, to be sure that when /home is separate and for some reason can not be mounted, root will still be able to login.

Hi all,

Sorry to interfere. But why would UEFI be required to boot an NVME disk? Is it due to the PCIe adapter? Am I missiing something? I Have just installed an Asus Prime X570-P booting from the NVME disk, a M.2 Seagate Barracuda Q5 ZP500. I took some efforts to make sure /not/ to use UEFI nor secure boot. Legacy boot from MBR works like a charme. /boot/ is there as BTRFS subvolume.

In order to boot from NVMe you need BIOS capable of booting from NVMe. Have you verified that your system actually supports it?

I’d guess that’s the more important issue.

Boot method doesn’t matter, support does and with that support it’s likely to be UEFI boot… I have a PCIe card with an NVME, system is old and doesn’t support it, so I boot from a SSD;

sda           8:0    0 232.9G  0 disk 
├─sda1        8:1    0   260M  0 part /boot/efi
├─sda2        8:2    0   768M  0 part /boot
├─sda3        8:3    0   230G  0 part /stuff
└─sda4        8:4    0   1.9G  0 part [SWAP]
nvme0n1     259:0    0 232.9G  0 disk 
├─nvme0n1p1 259:1    0    40G  0 part /var
└─nvme0n1p2 259:2    0 192.9G  0 part /data

UEFI boot is a far simpler solution than legacy boot IMHO…

OK, got it. Thanks Malcolm.

It is not required as such, but vendors usually do not implement support for legacy BIOS today. If your NVMe drive comes with option ROM that implements legacy BIOS boot protocol, then you do not need UEFI. Or you can modify BIOS and add one of available option ROMs (google is your friend here).

NVMe is part of (recent enough) UEFI specification so it is simply more likely to be supported by UEFI systems out of the box.

OK, interesting answers!
Let me clarify a few points in my initial posts.

  1. /root: No, I am not talking about /root directory, sorry, I meant “/” and I typed /root :slight_smile:
  2. I cannot find information if my motherboard supports booting from NVMe installed in a PCIe slot. But based on the fact that the Storage information shown in the UEFI page is only for the SATA ports and the NVMe disk is found under the NVME page without any option to configure **and **the fact that the NVMe disk is not shown in the boot order, but it’s shown in the BBS order makes me think that I cannot boot with it in Legacy mode, but I can boot from UEFI.
  3. The disk is an WD Blue SN550 and I cannot find information about option ROM.

No, what I mean with “Can I create only the /boot/efi as a FAT32 partition and install everything there?” is “Can I install all the necessary for grub files under just /boot/efi”, not the whole OS!

Same device here;

01:00.0 Non-Volatile memory controller: Sandisk Corp WD Blue SN500 / PC SN520 NVMe SSD (rev 01)

If it boots, then should just make sure the disk is gpt and not dos, create a small partition (for /boot/efi) ~260M and type ef00 and format to vfat. Then complete your install.

Meaning I have to use UEFI :slight_smile:
At least the work I done today as well as the documentation I wrote will not be useless.

OK, then you may want the separate /boot on a SATA disk… I also had to add the following boot option for my system: nvme_core.default_ps_max_latency_us=0

IMO the place to start is by booting your machine directly into the BIOS/UEFI setup.
In there, you can typically view any storage media which are recognized.

Because your NVME is mounted in a PCI-E card, it becomes important what that card is…
Sometimes these cards are recognized by the BIOS, sometimes not until later using OS drivers.

If your NVME is recognized on bootup, then you should be able to simply install using the Install ISO image burned to a USB dongle or optical disk like usual… You shouldn’t have to prepare your NVME and the installer should find your NVME like any other disk.

If you motherboard supported NVME natively, this would not have been an issue.