[SOLVED] How to move / from existing MBR boot to new NVME w/UEFI?

drankinatty · 2026-09-27 22:53:58

I have an existing server where the motherboard/processor died, so I've installed a new one that provides M.2 and UEFI-only boot from the NVME as well as legacy boot. The BIOS will use UEFI + legacy at the same time, meaning it will boot either depending on the specified boot order.

Currently I'm simply legacy booting the system using grub on the original spinning drives (arrays), but I want to move / to the NVME and boot from there while retaining the remainder as-is (e.g. /home and a 3T /data array will be mounted under the new /) I am using swap on the NVME, as it doubles the amount available (shown in partition layout below).

I posted a thread on arch-general regarding mount points for the ESP to determine where best to place it, either /efi (my choice) or /boot or /boot/efi. I think I have that sorted out and will simply mount the ESP at /efi. The system is up and running on the existing drives, the NVME is installed, partitioned with the ESP created and I'm at the point where I need to move the existing / to the new NVME (leaving the original / untouched) and boot the system from the NVME. I've got a few areas where I'm unclear on what I need to do.

My problem is I've been chasing my tail trying to figure out where the files that populate the ESP will come from. I've been through the wikis for Migrate install to new hardware [1], the Installation Guide [2] and various other of the UEFI pages listed and they basically say "Adding UEFI boot entries into the new mainboard NVRAM" and then give links to a list of bootloaders. From that I gather that installing the bootloader will populate the ESP (?), but I am somewhat confused because you should be able to boot UEFI without the bootloader via the NVME firmware entries, but nowhere is there a discussion on how to populate the ESP without having the bootloader do it? (the reason I'm confused is my Arch desktop does just that, there was no grub or other bootloader and I simply created a firmware entry with efibootmgr which is used at boot)

From this confusion, I've sussed out what I think is my approach for moving / to the new NVME. The procedure I've come up with is:

Partition the NVME as desired
Boot the Arch Install to allow copy of old / to / on NVME (I was just going to cp -a)
Update new /etc/fstab entries
arch-chroot the new / on the NVME (do I mount the ESP to /efi before or after this step?)
create the new /boot directory and /efi mount point and mount ESP to /efi (unless that should be done before chroot)
use grub to install the EFI bootloader (which should populate the ESP file in /efi)
remake initramfs on the new / (but I'm unclear on what extra modules are needed, currently the only extra hooks I have are mdadm for the arrays?)
at this point I should be able to reboot, swap the BIOS boot order to make the NVME/UEFI primary and the GPT/MBR secondary?

Why I'm trying to make sure I have this right before I take the system down is this is a production server, and I'd rather have a solid plan before I take the box down to minimize downtime (I do have a backup server I can route traffic to if it all goes south, but I'd like to avoid that if possible)

Here is the current partition setup including the existing drives and new NVME partitions:

major minor  #blocks  name

   8        0  976762584 sda
   8        1          1 sda1
   8        5     512000 sda5
   8        6   52428800 sda6
   8        7  921161728 sda7
   8        8    2117632 sda8
   8       16  976762584 sdb
   8       17          1 sdb1
   8       21     512000 sdb5
   8       22   52428800 sdb6
   8       23  921161728 sdb7
   8       24    2117632 sdb8
   8       32 2930266584 sdc
   8       48 2930266584 sdd

                NVME where I want to move /

 259        0  250059096 nvme0n1
 259        1    1048576 nvme0n1p1    /efi    - EFI_system_partition
 259        2    4194304 nvme0n1p2    /swap   - current
 259        3  243766272 nvme0n1p3    /

                Existing system (minus swap)

   9        4 2930135488 md4          /data
   9        0     511680 md0          /boot
   9        3    2115584 md3          /swap   - unused
   9        2  921030656 md2          /home
   9        1   52396032 md1          /

The NVME partition detail is:

# fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 238.47 GiB, 256060514304 bytes, 62514774 sectors
Disk model: WDC PC SN520 SDAPNUW-256G-1006
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 703D73B5-29E6-4878-988B-7DD677F5277D

Device           Start      End  Sectors   Size Type
/dev/nvme0n1p1     256   262399   262144     1G EFI System
/dev/nvme0n1p2  262400  1310975  1048576     4G Linux swap
/dev/nvme0n1p3 1310976 62252543 60941568 232.5G Linux root (x86-64)

So my question is, does this make sense? Am I missing or misunderstanding anything in the summary procedure I have planned? Is the order of arch-chroot and creation of /boot , /efi and mount of ESP correct or do I need to do part or all of that pre-chroot? Finally, am I thinking correctly that the install of the bootloader with grub, as set out in Grub 2.1 Installation [3] will populate the ESP with the files needed for boot?

I apologize for the long question, but if it was just a simple, short question, I can usually find the answer in the wiki. This actually seems like a really easy thing to do, but not having done it, the devil is always in the details. Those details being to make sure I get the ESP populated and the new initramfs generated to allow the system to boot. Any help on where I've messed up in the summary of steps above and clarity on when I need to create the new /boot directory and /efi mount point would be greatly appreciated.

[1] Archwiki - Migrate install to new hardware
https://wiki.archlinux.org/title/Migrat … w_hardware

[2] Installation Guide - 1.11 Mount the file systems
https://wiki.archlinux.org/title/Installation_guide

[3] Archwiki - GRUB
https://wiki.archlinux.org/title/GRUB#Installation

Last edited by drankinatty (Today 00:13:04)

headkase · 2026-09-27 23:52:15

I do not believe that you can boot both MBR and UEFI from the same physical drive. The reason so is the partitioning method. UEFI partitions and MBR partitions are not the same thing at all, and a system in CSM mode to boot in MBR cannot understand the UEFI partitions. I may be wrong, but I don't think that MBR bootstraps can understand UEFI drive layouts.

Edit: and I may have misunderstood. The ESP partition is recognized by UEFI by its partition type, and NVRAM boot entries in the system mainboard indicate which drive to boot from, and those entries are made by a utility like systemd-boot, and the initial ramdisks/UKI's are made by mkinitcpio (and requires your ESP to be mounted because the entries will be written there). You may have to create boot entries for systemd-boot or one of the alternatives, but that depends on which one you choose and how you configure it.

Last edited by headkase (2026-09-28 00:07:36)

drankinatty · 2026-09-28 02:19:44

Thanks headkase,

Yes, the system will boot either fine, the initial difficultly is when booted MBR/legacy, there isn't a way to fully set up the new NVME / due to there being no UEFI/efivars, etc. So that is what requires the arch-install iso to boot UEFI and then I can set up the new NVME.

So the system is the same system, just a new drive added for moving / to and changing from legacy boot to UEFI to utilize the new drive. I should probably also just convert the original install to UEFI as well. I don't see ever needing to put the drives back in a box that only boots MBR (though I do have a old 4U and 2U servers that are MBR only). That's for another day.

I think I have my head wrapped around what needs to happen, I just wish this wasn't on an active server so I could just dork with it if needed, but the goal is the make sure I have my head wrapped around the upgrade right beforehand.

At this point, absent someone weighing in and say "Stop dummy, you've got it wrong!", I'll probably just plan on giving it a go tomorrow evening. Since I'm not modifying the running system, worst case is my transfer to NVME doesn't work and I just boot the original system until I work out what went wrong. I'll report back either way.

cryptearth · 2026-09-28 05:56:29

well - sorry to be that one "stop!" guy - but at least for the replication from the old drive to the new one you should use something more sophisticated than just regular cp command - as not just the data itself but also the filesystem permissions are important
that said: is the filesystem the same? as in: from ext4 to ext4? or do you plan to copy between two different FS? if so: which?

as for the switch itself: as long as you have an up-to-date system only the actual boot is what differs: loading the kernel and initrd and start it - and as soon as the initrd takes over it should boot the system just fine (although you do have to check things like fstab and set the new uuid and regenerate initrd)

as for what populates the esp: it depends on how you boot - but it the end on a uefi system it needs at least any valid uefi binary - which could be anything from a dedicated bootloader like grub to the kernel itself using efi-stub or even a uki - all that has to be fullfilled is that the uefi has to be able to access it

as for /boot/efi - THAT one is explicit discouraged for several reasons - so either use /efi for a stand-alone esp - or /boot if you want everything on the esp
you could also go for something like XBOOTLDR: that's a 3 partition setup: 1 partition for /efi contain the bootloader - 1 partiiton for /boot contain kernel and initrd - and 1 partition for / - but: either xbootldr has to be also fat32 or you have to bring along efi filesystem drivers to make a xbootldr with a different FS like ext4 accessible

frostschutz · 2026-09-28 06:14:13

GPT has MBR fallback so hybrid setups are possible. Requires another partition to be made (bios_grub partition for core.img) or grub-install --force to embed core.img in unpartitioned space as it was done with MBR partitions.

If you want to install grub for UEFI but it was booted in MBR mode, you might be able to make it work with the --removable flag, which does not require a boot entry to be made.

In the end for such a hybrid setup, grub is installed multiple times (--target=i386-pc [--force], --target=x86_64-efi [--removable]) to support just about all boot modes.

It's a bit different if you also want Secure Boot.

In theory you can switch MBR to EFI in a single reboot, no additional downtime, just have to get everything right the first time... still better to have a live system ready and do it step by step. Or replicate the situation and practice on an unrelated machine.

-thc · 2026-09-28 06:51:15

Since I have done transitions like that multiple times now: If you have a virtualization platform at hand (which supports virtual BIOS/MBR and virtual UEFI) use that to test your procedure with a small Test-VM. I've done that and I always missed something important.

Preface: In theory the boot method and the partitioning method should be independent - but not in all cases (Windoze EFI requires GPT). I had a Linux server running BIOS/MBR/GRUB booting on a GPT drive for some time. I highly recommend GPT partitioning the NVMe drive.

Preface 2: Most of the procedure is dependent on your actual boot manager - your desktop may be using another one or using the EFI STUB method - the Linux kernel itself is a bootable EFI executable.

Preface 3: The UEFI firmware first looks into the "EFI boot manager" table in the NVRAM and picks the first entry in the current boot order. This entry points to a file on the EFI partition that gets executed.

I spot at least 2 problems in your procedure.

Step 2: You can simply copy most "root" partitions of existing installations (that includes Windoze) because in my experience most OSes system partitions are "oblivious" to the underlying boot method. But there maybe files that the EFI boot mechanism uses that are not there yet - in your case "efibootmgr" - which "grub-install --target=x86_64-efi" needs.

Step 5: The "/boot" directory gets populated by installing/upgrading the Linux kernel package, the ucode package and the GRUB package. It gets modified by updating the GRUB configuration and rebuilding the Initial RAM disk. I recommend copying this directory too.

Step 6: "grub-install --target=x86_64-efi ..." writes the files to the ESP but updates the NVRAM "EFI boot manager" too.

Last edited by -thc (2026-09-28 06:53:23)

drankinatty · 2026-09-28 21:59:58

That you all very much!

All disks are GPT and all filesystems are ext4, so no inconsistency between the NVME and spinning drives. The exiting / is 50G, the new / is roughly 200G. I'm not copying "partitions", just the contents -- which is why I was waiting to boot the arch install iso so that no existing partitions are mounted. Then, not clearly explained, I would simply mount the old / (say /mnt/old) and new / (say /mnt/new) and then cp -a /mnt/old/* /mnt/new (and cp -a /mnt/old/.* /mnt/new if any hidden files are present). There is no selinux, so no extended attributes at play.

I also have efibootmgr on the existing system. The --removable option for grub install looks promising, but I had read, and I don't know where, that you had to have booted UEFI to run the grub install and have grub then pick up the efi files needed. If --removable works around that, I may be able to set up the NVME (except for copying the content of /) from the current running install.

I know after the copy of old/new the EFI files will be missing, which is what prompted the part of the procedure to arch-chroot the new / after the copy is complete to then run the grub-install and update initrd -- since the arch-install iso will boot in UEFI mode, that should allow grub-install to access efibootmgr as needed and populate the NVRAM.

It wouldn't bother me to simply use the kernel EFI STUB, which is how my desktop boots, but since I already have grub, I may as well go ahead an use what's there.

Good point on /boot. I was unclear about that. I had planned to simply create a new /boot directory on the NVME, but was unclear whether I needed to copy from the existing /boot. The explanation of the files populated by the kernel install clears that up, so I do need to copy the contents of old /boot to new before updating the bootloader with grub-install and then remaking the initramfs.

This has given me quite a bit of help, and removed a lot of the uncertainty I had in the procedure. I'll report back with the good, the bad and the ugly...

drankinatty · 2026-10-01 04:16:33

Well....

It all worked until it didn't. Meaning, on boot it said there was a missing efi_uga.mod file (I wrote it down), and then it simply booted from the md1 array (spinning disk). From what I can tell from the drive contents, everything worked, but I must have missed copying one file somewhere. Here is what I did:

boot arch install - uefi
swapon /dev/nvme0n1p2
mkdir /mno (mount point for old / to copy from)
mount /dev/md1 /mno
mount /dev/nvme0n1p3 /mnt
cp -a /mno/* /mnt (confirm all 50G copied, confirm earlier created /efi present in /mnt/efi, and /boot earlier copied to /mnt/boot present)
mount /dev/nvme0n1p2 /mnt/efi (mount the ESP at /mnt/efi)
arch-chroot -S /mnt
mkinitcpio -P (all finished successfully, no errors)
grub-install --target=x86_64-efi --efi-directory=/efi --removable --bootloader-id=GRUB (all finished successfully, no errors)
exit chroot / reboot

Checking the /boot directory I have:

# ls -al boot/grub/
drwxr-xr-x 7 root root  4096 Sep 30 22:30 .
drwxr-xr-x 4 root root  4096 Sep 30 22:28 ..
drwxr-xr-x 2 root root  4096 Aug 21  2015 fonts
drwxr-xr-x 2 root root 12288 Aug 21  2015 i386-pc
drwxr-xr-x 2 root root  4096 Sep 30 22:30 locale
drwxr-xr-x 3 root root  4096 Aug 21  2015 themes
drwxr-xr-x 2 root root 16384 Sep 30 22:30 x86_64-efi
-rw------- 1 root root  6994 Sep 13 11:29 grub.cfg
-rw------- 1 root root  5366 Aug 21  2015 grub.cfg.example
-rw-r--r-- 1 root root  1024 Aug 21  2015 grubenv

# ls -al boot/grub/x86_64-efi/
total 4728
drwxr-xr-x 2 root root  16384 Sep 30 22:30 .
drwxr-xr-x 7 root root   4096 Sep 30 22:30 ..
-rw-r--r-- 1 root root  17280 Sep 30 22:30 acpi.mod
-rw-r--r-- 1 root root   1832 Sep 30 22:30 adler32.mod
-rw-r--r-- 1 root root   8520 Sep 30 22:30 affs.mod
...
  NOTE: there is no efi_uga.mod file in this directory
...
-rw-r--r-- 1 root root  11120 Sep 30 22:30 zfsinfo.mod
-rw-r--r-- 1 root root  80480 Sep 30 22:30 zstd.mod
-rw-r--r-- 1 root root   4008 Sep 30 22:30 zstdio.mod

Checking that the /efi directory was populated I have:

# ls -al efi
total 12
drwxr-xr-x  3 root  root  4096 Dec 31  1969 .
drwxr-xr-x 18 david david 4096 Sep 30 22:24 ..
drwxr-xr-x  3 root  root  4096 Sep 30 22:30 EFI

and in EFI I have:

# ls -al efi/EFI/
total 12
drwxr-xr-x 3 root root 4096 Sep 30 22:30 .
drwxr-xr-x 3 root root 4096 Dec 31  1969 ..
drwxr-xr-x 2 root root 4096 Sep 30 22:30 BOOT

# ls -al efi/EFI/BOOT/
total 172
drwxr-xr-x 2 root root   4096 Sep 30 22:30 .
drwxr-xr-x 3 root root   4096 Sep 30 22:30 ..
-rwxr-xr-x 1 root root 167936 Sep 30 22:30 BOOTX64.EFI

So, at least from my non-UEFI initiated view, it looks like everything got copied where it was supposed to by the mkinitcpio build and the grub-install, I'm just still confused if I needed to copy something manually from /boot to /efi to complete the process. The efivars firmware is now part of the system. I've temporarily mounted the new / partitoin under /home/data2 for examining the layout. Looking at the drive layout with df I see:

# df -h
Filesystem      Size  Used Avail Use% Mounted on
dev              16G     0   16G   0% /dev
run              16G  2.5M   16G   1% /run
efivarfs        256K   26K  226K  11% /sys/firmware/efi/efivars
/dev/md1         50G   36G   14G  73% /
tmpfs            16G  1.1M   16G   1% /dev/shm
none            1.0M     0  1.0M   0% /run/credentials/systemd-journald.service
tmpfs            16G  1.4M   16G   1% /tmp
/dev/md0        468M  164M  292M  36% /boot
/dev/md2        865G  620G  245G  72% /home
/dev/md4        2.7T  1.1T  1.6T  41% /home/data
tmpfs           3.2G   28K  3.2G   1% /run/user/620
tmpfs           3.2G   20K  3.2G   1% /run/user/1000
/dev/nvme0n1p3  228G   36G  192G  16% /home/data2
/dev/nvme0n1p1 1022M  176K 1022M   1% /home/data2/efi

When I look at efibootmgr, I do not recognize any of the entries -- could this be the missing part of the process? I thought grub-install would fix this? But the only entry that looks close would be the current boot entry Boot0004, but that's not the / UUID:

efibootmgr
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0004,0001,0002
Boot0001* Hard Drive    BBS(HD,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,0200)0000474f00004e4fc500000001000000850 <snip>
Boot0002* CD/DVD Drive  BBS(CDROM,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,0300)0000474f00004e4fc900000001000000 <snip>
oot0004* UEFI OS       HD(1,GPT,43ed8c03-d059-4cdf-a06b-af6fc6c2161c,0x100,0x40000)/\EFI\BOOT\BOOTX64.EFI0000424f

and the UUIDs on this system are:

$ l /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 200 Sep 30 23:29 .
drwxr-xr-x 8 root root 160 Sep 30 23:28 ..
lrwxrwxrwx 1 root root  15 Sep 30 23:29 01219db4-dd17-47d2-b418-6b30b14dee79 -> ../../nvme0n1p2
lrwxrwxrwx 1 root root  15 Sep 30 23:29 2B87-58DD -> ../../nvme0n1p1
lrwxrwxrwx 1 root root   9 Sep 30 23:28 3c0d11b5-c637-4def-a6e0-f48a4a17e71a -> ../../md0
lrwxrwxrwx 1 root root   9 Sep 30 23:28 402a70c8-b51b-41a0-aa887c8dd6fd -> ../../md2
lrwxrwxrwx 1 root root   9 Sep 30 23:28 515ef9dc-769f-4548-9a08-3a92fa83d86b -> ../../md1
lrwxrwxrwx 1 root root  15 Sep 30 23:29 60240838-dbe4-41e4-8929-848df485bbef -> ../../nvme0n1p3
lrwxrwxrwx 1 root root   9 Sep 30 23:28 8920ca3f-f253-4011-9c9e-a6be513527e0 -> ../../md3
lrwxrwxrwx 1 root root   9 Sep 30 23:28 92e8d924-fc14-4adc-8754-7f4da0507c32 -> ../../md4

The efivars are Greek to me. Maybe leftover from the previous owner of the motherboard? I have no clue what is supposed to be in them, but this is what I find when I look with ls:

$ ls /sys/firmware/efi/efivars/
AMITSESetup-c811fa38-42c8-4579-a9bb-60e94eddfb34
AmiEntryS3Addr-074e1e48-8132-47a1-8c2c-3f14ad9a66dc
Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0004-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
CACHE-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
CpuSetupVolatileData-b08f97ff-e6e8-4193-a997-5e9e9b0adb32
CpuSmm-90d93e09-4e91-4b3d-8c77-c82ff10e3c81
DefaultBootOrder-45cf35f6-0d6e-4d04-856a-0370a5b16f53
DefaultLegacyDevOrder-3c4ead08-45ae-4315-8d15-a60eaa8caf69
DeploymentModeNv-97e8965f-c761-4f48-b6e4-9ffa9cb2a2d6
EPCBIOS-c60aa7f6-e8d6-4956-8ba1-fe26298f5e87
Ep-73dad563-8f27-42af-918f-8651eb0a93ef
ErrOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
FBSelect-3fae9ba1-a3f1-42eb-b6f2-b616ea57db9d
FPDT_Volatile-01368881-c4ad-4b1d-b631-d57a8ec8db6b
FixedBoot-de8ab926-efda-4c23-bbc4-98fd29aa0069
GSEHWInfo-8a989680-e651-4c51-a2af-3cdb1a4ab5b0
HiiDB-1b838190-4625-4ead-abc9-cd5e6af18fe0
IntUcode-eda41d22-7729-5b91-b3ee-ba619921cefa
KEKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c
LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
LegacyDevOrder-a56074db-65fe-45f7-bd21-2d2bdd8e9652
LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
LoaderInfo-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
LoaderTpm2ActivePcrBanks-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
M2DeviceData-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
M2GenieStatus-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
MFlashVersionVariable-fd6b0489-d401-40c2-98b1-b1300b048711
MaximumTableSize-4b3082a3-80c6-4d7e-9cd0-583917265df1
MeSetupStorage-5432122d-d034-49d2-a6de-65a829eb4c74
MemoryOverwriteRequestControl-e20939be-32d4-41be-a150-897f85d49829
MemoryOverwriteRequestControlLock-bb983ccf-151d-40e1-a07b-4a17be168292
MonotonicCounter-01368881-c4ad-4b1d-b631-d57a8ec8db6b
MsiOcCpuMemInfo-4ba187df-3bad-41b2-b73b-3d3dc1cc6387
MsiOcDataInNVRAM-7c405766-3e31-41cc-24e1-ee63e27d9912
MsiOcMemPatchID-78876464-9753-a77a-7607-652533891231
MsiOcMemSpdCheckSum-78876464-9753-a77a-7607-652533891231
MsiOcMemSpdData-78876464-9753-a77a-7607-652533891231
MsiOcMemSpdXMPInfo-78876464-9753-a77a-7607-652533891231
NetworkStackVar-d1405d16-7afc-4695-bb12-41459d3695a2
NewOptionPolicy-69ecc1be-a981-446d-8eb6-af0e53d06ce8
OA3MSDMvariable-01368881-c4ad-4b1d-b631-d57a8ec8db6b
OEMDATA-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
OcInfoPassToSetup-6c3c33b6-2e40-42bc-84e6-8c510e7e9ebf
OldLegacyDevOrder-a56074db-65fe-45f7-bd21-2d2bdd8e9652
OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c
OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
PCIM2Data-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
PKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
PNP0303_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031
PNP0F03_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031
PS2DETECT-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
PcieSataModVar-5e9a565f-cdc0-413b-ad13-1fe8713ffdcd
PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
ProFileAutoSaveInfo-515b6cdf-bbe7-4509-83cc-d725903d522a
RstOptaneConfig-4da4f952-2516-4d06-8975-65036403a8c7
SOFTWAREGUARDSTATUS-9cb2e73f-7325-40f4-a484-659bb344c3cd
SdioDevConfiguration-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
SecureBootSetup-7b59104a-c00d-4158-87ff-f04d6396a915
SetUpdateCountVar-81c76078-bfde-4368-9790-570914c01a65
Setup-80e1202e-2697-4264-9cc9-80762c3e5863
Setup-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
SignatureSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
SmbiosEntryPointTable-4b3082a3-80c6-4d7e-9cd0-583917265df1
SmbiosScratchBuffer-4b3082a3-80c6-4d7e-9cd0-583917265df1
StdDefaults-4599d26f-1a11-49b8-b91f-858745cff824
Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
UsbSupport-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
VendorKeys-8be4df61-93ca-11d2-aa0d-00e098032b8c
WriteOnceStatus-4b3082a3-80c6-4d7e-9cd0-583917265df1
dbDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
dbxDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
msiDispatcherImageList-26817ae9-ca17-80d5-ab93-2f682e69efa9
msiOcProFileStringCount-857fbb9e-8a3b-97ce-ae58-2515e09922bb

Anybody see where I missed a step above that is leading to the mysterious efi_uga.mod ... error when trying to boot UEFI? Is that something I need to include in the initramfs since my graphics are an old Nvidia GTX 460 using the nvidia-390xx-utils driver (AUR)? Is that possibly something being looked for in the efivars? More importantly, how do I fix it? Do I also need to create an EFISTUB entry with efibootmgr? We have now reached the end of my current UEFI knowledge. In the interim, I'll see if I can find more in the UEFI wiki.

Last edited by drankinatty (2026-10-01 04:54:47)

-thc · 2026-10-01 05:35:57

Since I never had that specific scenario (old root still present in the system) a fair amount of guesswork on my part is involved.

Step 10 created only "/EFI/BOOT/BOOTX64.EFI" and no new entry into the firmware's "EFI Boot Manager" - that's what the flag "removable" does.

Your system (switched to EFI) now boots boot order number "Boot0004" - which points to the drive uuid (not partition uuid) and the newly created "BOOTX64.EFI".

This EFI executable somehow seems to load the old "grub.cfg" from the old "/boot" which still contains loading of "efi_uga.mod". This module is not present in my grub installation at all.

Try the following: Boot into a system state with "arch-chroot" like your step 8. "efibootmgr" has to be available in the chroot.

grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB /dev/nvme0n1
grub-mkconfig -o /boot/grub/grub.cfg

Last edited by -thc (2026-10-01 06:08:42)

frostschutz · 2026-10-01 06:35:12

efi_uga was in grub 2.14 but is no longer present in grub 2.16, apparently it was dropped

so it seems you can get this efi_uga error if you're trying to load a grub.cfg generated by grub 2.14 with grub 2.16

drankinatty · 2026-10-01 07:04:00

Ahah! You guys may be life savers!

I'll have to wait until the RAID scrub finishes in the morning and then do a quick cp -ua of the old / to new to pickup any mail and the cron-monthly updates that ran tonight.

The grub.cfg is from 9/13 generated when the 7.2.7 kernel was installed? And, yes, I thought about running grub-install with and without --removable to make sure the firmware was updated, but reading the GRUB page it recommended --removable for MSI motherboard (which this one is). But I still should have done both.

I'll remake the grub.cfg file and make sure the efi_uga.mod request is gone. I was actually surprised how far I got, and it looked really close to working except for that efi_uga.mod error. I'll have to go re-read the GRUB page, I could have sworn it said adding the device (e.g. /dev/nvme0n1) would be ignored for efi installs, but I'll double-check.

This has been a good learning experience so far, even though I'm still completely ignorant of the interplay between the efivars, the firmware entry and the grub-install supposedly making manually updating either unnecessary, but that confusion will slowly lift.

Will report back tomorrow after the raid scrub and the busy part of the day is done.

-thc · 2026-10-01 18:13:30

drankinatty wrote:

The grub.cfg is from 9/13 generated when the 7.2.7 kernel was installed?

Nope - most likely are some other changes are to blame. It shows however that you didn't install grub 2.16 yet.

drankinatty wrote:

but reading the GRUB page it recommended --removable for MSI motherboard (which this one is). But I still should have done both.

That's true. Well - if the MSI board only works via BOOTX64.EFI - so be it.

drankinatty wrote:

I'll have to go re-read the GRUB page, I could have sworn it said adding the device (e.g. /dev/nvme0n1) would be ignored for efi installs, but I'll double-check.

True. But in your case: Does GRUB assume the device containing "/efi" is also containing "/boot"? I keep it for clarity .

drankinatty wrote:

This has been a good learning experience so far, even though I'm still completely ignorant of the interplay between the efivars, the firmware entry and the grub-install supposedly making manually updating either unnecessary, but that confusion will slowly lift.

The UEFI firmware stores nearly all of it's specific configuration in efivars. The "EFI Boot Manager" entries are stored in efivars of the same name ("Boot000X..."), their order in "BootOrder-...", the Secure Boot keys in "db...", "dbx...", "KEK..." and "PK...". Bootloader entries are in "Loader..." and so on...

"grub-install" writes a new EFI executable in the EFI partition and calls "efibootmgr" to create a new "Boot000X..." entry and change the boot order.

drankinatty · 2026-10-01 23:15:57

Chuckling - smacks self for not seeing the forest for the trees, and being a bit overwhelmed by the move. The only issue was I forgot grub-mkconfig -o /boot/grub/grub.cfg before running grub-install in the chroot.

So, in hopes this helps someone else looking to move a root partitions from a harddrive to NVME, the procedure I followed, updated with grub-mkconfig was:

boot arch install - uefi
swapon /dev/nvme0n1p2
mkdir /mno (mount point for old / to copy from)
mount -o ro /dev/md1 /mno
mount /dev/nvme0n1p3 /mnt
cp -a /mno/* /mnt (confirm all 50G copied, confirm earlier created /efi present in /mnt/efi, and /boot earlier copied to /mnt/boot present)
umount /mno
mount /dev/nvme0n1p2 /mnt/efi (mount the ESP at /mnt/efi)
(make needed changes to /mnt/etc/fstab)
arch-chroot -S /mnt
mkinitcpio -P (all finished successfully, no errors)
grub-mkconfig -o /boot/grub/grub.cfg
grub-install --target=x86_64-efi --efi-directory=/efi --removable --bootloader-id=GRUB (all finished successfully, no errors)
note: remove --removable to update UEFI firmware (MSI boards recommended --removable, I did both)
exit chroot / reboot

Booted perfectly, from the "Arch Linux" default entry in the freshly configured and installed bootloader. Regenerating grub.cfg removed the efi_uga.mod entry. We did have grub 2:2.16-1 installed, I guess grub-mkconfig had not been run since it was installed. (I do read the pacman messages - but since I don't use any "new" features, I didn't manually regenerate the config after the last update).

The move of / with cp -a worked fine with 3 exceptions. This is a fairly full server (httpd, php, postgresql, mariadb, postfix, dovecot, samba, etc..) and out of all services, only httpd, samba (smb) and mariadb failed to start. The only problem with all 3 was when the contents for / was copied, no state-directories were copied for /run/httpd, run/mysqld and /run/samba. Really strange, but I guess since the old / was mounted from the installer while no services were running, those didn't exist? I thought they should have been recreated when the services started, but they weren't. Creating them (setting ownership) and restarting the services, solved the issue.

Sure enough, I just mounted the old / to check what was in /run when the drive wasn't in use, and it is indeed empty.

# mount -o ro /dev/md1 /home/data2
# l /home/data2/run
total 8
drwxr-xr-x  2 root root 4096 Aug 21  2015 .
dr-xr-xr-x 17 root root 4096 Sep 28 21:03 ..

That brings up the question of why didn't httpd, mariadb and samba recreate their state-directories when the system booted? Could anything with the system service files not have been copied correctly? Those services were started, they just failed due to not having a directory under /run?? That's one I have to solve.

Solved! - my fault. Somewhere in the setup and mount of the NVME, the / partition became owned by me "david:david", so whatever the unsafe cannocical path transition does with /run, it seems to have been what prevented the services from creating their individual state directories and caused the services to fail to start (makes sense given the sensitive nature of data in the state directories, that also means those were the only 3 smart enough to check...). So after tonight's pacman -Syu and update to the 7.2.8 kernel, I saw the unsafe path transition warnings and reset the ownership on / to root. dkms Nvidia 390xx driver build worked like a champ (much quicker) and the virtualbox modules rebuilt fine. On reboot, all services happily started, so I'll mark that mystery as solved due to the ownership mixup.

All and all -- success! Up and running with / on the new NVME booting with UEFI:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
dev              16G     0   16G   0% /dev
run              16G  2.5M   16G   1% /run
efivarfs        256K   26K  226K  11% /sys/firmware/efi/efivars
/dev/nvme0n1p3  228G   36G  192G  16% /
tmpfs            16G  1.1M   16G   1% /dev/shm
none            1.0M     0  1.0M   0% /run/credentials/systemd-journald.service
tmpfs            16G  1.9M   16G   1% /tmp
/dev/md2        865G  620G  245G  72% /home
/dev/md4        2.7T  1.1T  1.6T  41% /home/data
tmpfs           3.2G   28K  3.2G   1% /run/user/620
tmpfs           3.2G   20K  3.2G   1% /run/user/1000

Great learning experience, but I've still got a long way to go to feel comfortable with UEFI. Thanks to all for your help! The ability work through issues like this with community help is the difference between success and failure in many instances.

I'll leave this open for another day or so before marking it solved in case there is further discussion on fine tuning this approach.

Last edited by drankinatty (Yesterday 03:17:28)

Arch Linux

#1 2026-09-27 22:53:58

[SOLVED] How to move / from existing MBR boot to new NVME w/UEFI?

#2 2026-09-27 23:52:15

Re: [SOLVED] How to move / from existing MBR boot to new NVME w/UEFI?

#3 2026-09-28 02:19:44

Re: [SOLVED] How to move / from existing MBR boot to new NVME w/UEFI?

#4 2026-09-28 05:56:29

Re: [SOLVED] How to move / from existing MBR boot to new NVME w/UEFI?

#5 2026-09-28 06:14:13

Re: [SOLVED] How to move / from existing MBR boot to new NVME w/UEFI?

#6 2026-09-28 06:51:15

Re: [SOLVED] How to move / from existing MBR boot to new NVME w/UEFI?

#7 2026-09-28 21:59:58

Re: [SOLVED] How to move / from existing MBR boot to new NVME w/UEFI?

#8 2026-10-01 04:16:33

Re: [SOLVED] How to move / from existing MBR boot to new NVME w/UEFI?

#9 2026-10-01 05:35:57

Re: [SOLVED] How to move / from existing MBR boot to new NVME w/UEFI?

#10 2026-10-01 06:35:12

Re: [SOLVED] How to move / from existing MBR boot to new NVME w/UEFI?

#11 2026-10-01 07:04:00

Re: [SOLVED] How to move / from existing MBR boot to new NVME w/UEFI?

#12 2026-10-01 18:13:30

Re: [SOLVED] How to move / from existing MBR boot to new NVME w/UEFI?

#13 2026-10-01 23:15:57

Re: [SOLVED] How to move / from existing MBR boot to new NVME w/UEFI?

Board footer