Grub does not work after migrate existing Arch Linux to a new disk

wenbushi · 2022-06-22 07:05:17

Hi folks. I am trying to migrate my existing Arch Linux to a new NVME disk. I followed the "top to bottom" way in Migrate installation to new hardware and did these steps:

Boot into a live installation environment with a USB drive.
Partition the new NVME disk into a 500M EFI and a 930G (of type Linux x64 root) parts.
Mount old and new root partitions, run (I forgot to exclude directories like /dev /proc in this step)
```
rsync -qaHAXS OLD_ROOT NEW_ROOT
```
Mount old and new boot partitions, run
```
rsync -qaHAXS OLD_BOOT NEW_BOOT
```
Mount new root partition to /mnt and new boot partition to /mnt/boot, run
```
arch-chroot /mnt
```
Update /etc/fstab.

Update grub by

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

Reboot and select grub2.

Expect: the new NVME partitions should be mounted to / and /boot.
Actual: the old partitions are mounted to / and /boot.

I also tried to reinstall linux package after arch-chroot to the new root, but it didn't work either. Any help is appreciated, thank you!

Last edited by wenbushi (2022-06-22 07:06:34)

Roken · 2022-06-22 08:21:03

cat /etc/fstab
sudo blkid
sudo fdisk -l

and post the output back.

wenbushi · 2022-06-22 09:12:18

The fstab of new root:

cat /etc/fstab

#
# /etc/fstab: static file system information
#
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/nvme0n1p2 LABEL=Linux\134x20NVME
UUID=219d4f68-3c93-48e2-af1b-0af55061008b / ext4 rw,relatime 0 1
# /dev/nvme0n1p1 LABEL=EFI
UUID=A8FB-A5CA /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 2
# old root partition
# UUID=7838f7f4-3bbb-4384-b0ef-636549fd53f2 / ext4 rw,relatime,data=ordered 0 1
# old boot partition
# UUID=0E39-C908 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 2

These commands are running in the old system (/dev/sdb1 and /dev/sdb2 currently):

sudo blkid

/dev/nvme0n1p1: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="A8FB-A5CA" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="38029c7c-4a3b-c74a-b62e-4f54781631d4"
/dev/nvme0n1p2: LABEL="Linux NVME" UUID="219d4f68-3c93-48e2-af1b-0af55061008b" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b33cb674-932d-9d44-8233-6e599a20d597"
/dev/sdb2: UUID="7838f7f4-3bbb-4384-b0ef-636549fd53f2" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="20b9e4aa-8216-4bc7-8a3b-2fd13f9790f8"
/dev/sdb1: UUID="0E39-C908" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="55f70977-f0af-4aa9-a42a-2a1e555c4c61"
/dev/sda2: UUID="336c8327-8e83-4506-800a-d797c8c934fd" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b8042866-14b5-0d4f-a4d4-665d83a6c735"
/dev/sda1: UUID="0b68cb3f-a5a5-4601-bf2c-9ad1f608d44e" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="5c0a126e-8af0-4b6f-8711-8f02d3e68b59"

sudo fdisk -l

Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: ST2000DM001-1ER1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 62547139-A955-4A6B-ADB0-60FF9F27E5E9
Device Start End Sectors Size Type
/dev/sda1 2048 1000000000 999997953 476.8G Linux filesystem
/dev/sda2 1000001536 3907029134 2907027599 1.4T Linux filesystem
Disk /dev/sdb: 111.79 GiB, 120034123776 bytes, 234441648 sectors
Disk model: Samsung SSD 750
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: gpt
Disk identifier: 41222F29-82D3-4488-A796-7385AAC7DAC6
Device Start End Sectors Size Type
/dev/sdb1 2048 530000 527953 257.8M EFI System
/dev/sdb2 530432 234441614 233911183 111.5G Linux filesystem
Disk /dev/nvme0n1: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 970 EVO Plus 1TB
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: gpt
Disk identifier: 9994359E-1702-8841-BA70-8EA5C73EDE92
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 1026047 1024000 500M EFI System
/dev/nvme0n1p2 1026048 1953523711 1952497664 931G Linux root (x86-64)

mukl · 2022-06-22 09:14:14

Seems like the wrong root partition is passed to the kernel.

Check the "root=" parameter in GRUB_CMDLINE_LINUX_DEFAULT in your grub.cfg.

Hint: Umount or even unplug your old root before you run grub-mkconfig inside arch-chroot.

wenbushi · 2022-06-22 09:14:33

I checked the output of efibootmgr. Seems the new Grub does not work (named Grub2) and fallback to use the old grub (named grub).

➜ ~ efibootmgr
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0004,0002,0001,0003,0000
Boot0000* Windows Boot Manager
Boot0001* Hard Drive
Boot0002* grub
Boot0003* UEFI: hp v250w 1100, Partition 1
Boot0004* GRUB2

wenbushi · 2022-06-22 09:29:44

mukl wrote:

Seems like the wrong root partition is passed to the kernel.
Check the "root=" parameter in GRUB_CMDLINE_LINUX_DEFAULT in your grub.cfg.
Hint: Umount or even unplug your old root before you run grub-mkconfig inside arch-chroot.

I didn't pass root parameter explicitly. These are first lines of my /etc/default/grub:

# GRUB boot loader configuration
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="random.trust_cpu=on loglevel=3 quiet"
GRUB_CMDLINE_LINUX=""

This is main part of my /boot/grub/grub.cfg file:

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Arch Linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-219d4f68-3c93-48e2-af1b-0af55061008b' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod fat
search --no-floppy --fs-uuid --set=root A8FB-A5CA
echo 'Loading Linux linux ...'
linux /vmlinuz-linux root=UUID=219d4f68-3c93-48e2-af1b-0af55061008b rw random.trust_cpu=on loglevel=3 quiet
echo 'Loading initial ramdisk ...'
initrd /intel-ucode.img /initramfs-linux.img
}
submenu 'Advanced options for Arch Linux' $menuentry_id_option 'gnulinux-advanced-219d4f68-3c93-48e2-af1b-0af55061008b' {
menuentry 'Arch Linux, with Linux linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-advanced-219d4f68-3c93-48e2-af1b-0af55061008b' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod fat
search --no-floppy --fs-uuid --set=root A8FB-A5CA
echo 'Loading Linux linux ...'
linux /vmlinuz-linux root=UUID=219d4f68-3c93-48e2-af1b-0af55061008b rw random.trust_cpu=on loglevel=3 quiet
echo 'Loading initial ramdisk ...'
initrd /intel-ucode.img /initramfs-linux.img
}
menuentry 'Arch Linux, with Linux linux (fallback initramfs)' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-fallback-219d4f68-3c93-48e2-af1b-0af55061008b' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod fat
search --no-floppy --fs-uuid --set=root A8FB-A5CA
echo 'Loading Linux linux ...'
linux /vmlinuz-linux root=UUID=219d4f68-3c93-48e2-af1b-0af55061008b rw random.trust_cpu=on loglevel=3 quiet
echo 'Loading initial ramdisk ...'
initrd /intel-ucode.img /initramfs-linux-fallback.img
}
}
### END /etc/grub.d/10_linux ###

Wild Penguin · 2022-06-22 09:46:34

Your grub.cfg is configured correctly at leas as I can see it. To me it seems like the problem is with your UEFI BIOS, which for some reason is booting the old GRUB (with it's own grub.cfg). Maybe it thinks the GRUB2 installation is corrupted for some reason? Make sure you have the right EFI partition mounted at /boot when you install grub.

Which motherboard you have? You could try to go to it's BIOS boot menu and select the correct grub installation from there for a manual boot.

Alternatively, you could load the correct configuration file from grub command line (this is a handy procedure in many situations, so it is worthwhile to learn). Something like configfile (hd0,gpt1)/EFI/grub/grub.cfg should work (from the top of my head; grub command line has some tab-autocompletion).

After you've successfully booted into the new root, delete all grub instances with efibootmgr and re-install to make sure you have only one (unless you want to have several). Beware you are making the system unbootable in principle - in case the new grub installation is wrong, you need to have some back up way of booting (a USB stick, any, which has grub with the needed filesystem modules should work).

Last edited by Wild Penguin (2022-06-22 09:47:49)

wenbushi · 2022-06-22 16:36:18

Wild Penguin wrote:

Your grub.cfg is configured correctly at leas as I can see it. To me it seems like the problem is with your UEFI BIOS, which for some reason is booting the old GRUB (with it's own grub.cfg).

You're absolutely right. In the old grub command line, I can manually load GRUB2's config file and everything works fine. I can boot into the new root system. But for unknown reasons the UEFI BIOS cannot recognize GRUB2, even when I manually select to boot with GRUB2. Seems like the partition is invalid or corrupted to the UEFI BIOS. Here is the layout of my /boot partition:

/boot
├── EFI
│ └── grub
│ └── grubx64.efi
├── grub
│ ├── fonts
│ │ └── unicode.pf2
│ ├── grub.cfg
│ ├── grub.cfg.bak
│ ├── grub.cfg.example
│ ├── grubenv
│ ├── locale
│ │ └── ...
│ ├── themes
│ │ └── ...
│ └── x86_64-efi
│ ├── acpi.mod
│ ├── ...
│ └── zfs.mod
├── initramfs-linux-fallback.img
├── initramfs-linux.img
├── intel-ucode.img
└── vmlinuz-linux

Wild Penguin wrote:

Which motherboard you have?

It's an old Gigabyte B150M-D3H-CF.

wenbushi · 2022-06-22 16:46:36

I replaced the old grub config with new grub config. Now I can boot into the new disk. Apparently my GRUB2 installation is not correct. But I don't know what is wrong..

wenbushi · 2022-06-23 00:42:18

Is it possible that the UEFI Bios misses the NVME driver so it cannot recognize the partition?

Wild Penguin · 2022-06-26 12:16:26

wenbushi wrote:

Is it possible that the UEFI Bios misses the NVME driver so it cannot recognize the partition?

Yes. OPs motherboard (or laptop?) is an important piece of information not yet mentioned. Motherboards need to specifically support NVMe booting. Not all do, especially those made before very recent years, and I would check for even recent motherboards. The manual should state this (or, failing that, Google).

Arch Linux

#1 2022-06-22 07:05:17

Grub does not work after migrate existing Arch Linux to a new disk

#2 2022-06-22 08:21:03

Re: Grub does not work after migrate existing Arch Linux to a new disk

#3 2022-06-22 09:12:18

Re: Grub does not work after migrate existing Arch Linux to a new disk

#4 2022-06-22 09:14:14

Re: Grub does not work after migrate existing Arch Linux to a new disk

#5 2022-06-22 09:14:33

Re: Grub does not work after migrate existing Arch Linux to a new disk

#6 2022-06-22 09:29:44

Re: Grub does not work after migrate existing Arch Linux to a new disk

#7 2022-06-22 09:46:34

Re: Grub does not work after migrate existing Arch Linux to a new disk

#8 2022-06-22 16:36:18

Re: Grub does not work after migrate existing Arch Linux to a new disk

#9 2022-06-22 16:46:36

Re: Grub does not work after migrate existing Arch Linux to a new disk

#10 2022-06-23 00:42:18

Re: Grub does not work after migrate existing Arch Linux to a new disk

#11 2022-06-26 12:16:26

Re: Grub does not work after migrate existing Arch Linux to a new disk

Board footer