Moving from hdd to ssd with rEFInd - EFI, not UEFI

Message

depontius · Post by **depontius** » Sun Sep 06, 2020 11:30 pm

I'm moving from hdd to ssd, and since I really don't understand EFI booting very well, I'm not sure how to proceed. Perhaps I should have stuck with the legacy BIOS option years ago when I installed, but I figured I should really learn the new way, but once it worked I just started using it.

I'm using rEFInd, which I installed before it was in portage, so I did it either manually or using their script. As mentioned in the title, this is just EFI, not UEFI. Thank @diety for small simplifications. I also have both /boot and /boot/efi partitions, which in retrospect may be an unnecessary complication. But it's what I've got and it works, so I'm hesitant to touch it.

I have a two files, "/boot/refind_linux.conf" and /boot/efi/EFI/refind/refind.conf" that are identical, and basically point to the UUID of my boot partition. At one point I was planning on simply leaving the hdd in place, using it only for /boot and /boot/efi, using the ssd for the rest of the system. But I'm also moving cases, and may not have room for two hdds in the new case. Plus I'd just like to get it down to one drive, if I can.

My plan would be to repartition the ssd just like the hdd, rsync all of the contents over, partition by partition, except using mkswap to make the new swap partition. Then edit the configuration files on the new ssd /boot and /boot/efi/EFI/refind to point the UUID to the new ssd root, then mark the new /boot/efi partition bootable. After that I would unplug the hdd, reboot, and hope.

Some things about this method strike me as not being a good idea. Any advice?

Tony0945 · Post by **Tony0945** » Mon Sep 07, 2020 12:26 am

Code: Select all

 # locate refind.conf |grep boot
/boot/refind.conf.bak
/boot/efi/EFI/refind/refind.conf
/boot/efi/EFI/refind/refind.conf-sample

and on my second rEFInd box

Code: Select all

~ $ locate refind.conf
/boot/efi/EFI/refind/refind.conf
/boot/efi/EFI/refind/refind.conf-sample

I also had two refind.conf files that caused boot problems. On the first box I renamed /boot/refind.conf to /boot/refind.bak
On the second box, I just deleted it. my problem was two menus being offered.

You definitely don't need a separate /boot. When moving to a new drive, I would definitely not create one. YMMV
rEFInd doesn't care.

And I think you should install via the ebuild and running "refind-install" that will be created from the ebuild. But I think your method should work.

I think you should try it and if it doesn't work, then boot your bootable medium (be sure it's in EFI mode) and emerge the latest version.
Both my systems are SSD (external SATA, not NVME). In a few weeks I should know about NVME (building a new box).

Here's my server's /etc/fstab (stripped of comments)

Code: Select all

LABEL=CT250MX_EFI	/boot/efi	vfat		auto,noatime	1 2
LABEL=CT250MX_PART2	/		ext4		defaults,noatime  0 1
LABEL=WD5001_PART2	/video		ext4		nofail,auto,relatime  0 3
LABEL=DATA		/data		ext4		nofail,auto,relatime  0 4
LABEL=10TBbackup	/mnt/backup	ext4		noauto,auto,user           0 0
/dev/sr0		/mnt/cdrom	auto		noauto,user,ro	0 0
tmpfs		    /var/tmp/portage    tmpfs       nofail,noatime,nr_inodes=1M,size=20G    0 0

And here is my workstation's:

Code: Select all

 $ grep -v ^# /etc/fstab 


LABEL=CT500MX_EFI	/boot/efi	 vfat	relatime	1 2
LABEL=CT500MX_PART2	/		 ext4	relatime	0 1
LABEL=SAGE_VIDEO	/video		 ext4	auto,relatime	0 1
/dev/sr0		/mnt/cdrom	 auto	user,noauto,nofail	0 0
/dev/shm                /var/tmp/portage tmpfs noatime,nodev,nosuid   0 0
devpts			/dev/pts	 devpts	    rw,notime,gid=5,mode=620,ptmxmode=000 0 0

LABEL=P1-1TB		/mnt/freegentoo	 ext4		relatime,noauto  0 1
LABEL=P2-1TB		/mnt/custom	 ext4		relatime,noauto  0 1
LABEL=P3-1TB            /home/tony/.VirtualBox	ext4	relatime,auto	0 1



//trantor/video	        /mnt/samba-trantor	cifs	vers=1.0,users,user=guest,password=none,rw   0 0
//trantor/data          /mnt/trantor-data       cifs    auto,vers=1.0,users,user=guest,password=none,rw   0 0

I use partition labels rather than UUID. easier to read and harder to type wrong.
Notice that I have only two partitions on the SSD's, the efi partition vfat and the root partition. rEFInd will find your kernels just fine on the root partition as long as it's a supported file system (ext4 definitely is). I have nothing on the fat EFI partitions but rEFIND So I make them small.
1G on my first system following advice that apparently I wanted the kernels there. And 100M on the second and it's only 2% full despite holding four kernels. If you make it too small (100M is probably a lower bound) the BIOS may have a problem.

You are supposed to run efibootmgr to set the default boot in the BIOS, but I found my MSI BIOS easier to use. Again, your mileage may vary. Lot's of things depend on how good your BIOS is, according to the website.

I also found rodsmith@rodsbooks.com very approachable and helpful. But lets see if we can get through this on the forum so others can learn and leave stumpers for the program creator. If you do go to him, leave a tip on his webpage. It's not needed, but I bought him lunch just be a gentleman. I don't need one nor do I have a tip box. I'm free of course.[/code]

EDIT Oh, you don't need a fallback EFI either unless you are dual booting. no need for a fallback if you only have one boot loader.
I had followed advice to copy the rEFInd .efi to the fallback .efi Bad advice, it just gave boot problems.
But your install medium MUST be EFI. If you boot in legacy BIOS mode, the install will fail.
I used GParted from the old sysrescuecd to create my partitions and filesystems and I think to label them. So I'm a weenie for using a GUI program. use whatever you are comfortable with.

depontius · Post by **depontius** » Mon Sep 07, 2020 1:02 am

That's interesting to see. So the critical partition for booting is now "/boot/efi", which I guess makes sense from what I've seen today. I saw it before, but never really make sense of it. Once I had the system booting I breathed a sigh of relief and just started using it. I also remember that I had a heck of a lot of trouble getting it to boot for the first time. I forget the exact "formula" I used, but it was quite counter-intuitive. Perhaps a function of 2013-era (or earlier?) EFI BIOS.

I have the multiple copies of *.conf*, but being timid I think I'm just going to keep them all in sync.

There is another reason for all of this. I have a brand-new motherboard, CPU, NVME, etc down in the basement, and it's food-chain time. This motherboard goes to my wife, her motherboard becomes a new server, and my new motherboard goes into the case the current server is in right now. But my wife also likes small, slimline cases, and I've had an ssd sitting in this thing for months waiting for me to get around to the migration. The new case forces this migration.

The new motherboard will no doubt get an EFI install, and I'm going to pay more attention as I do it, and hopefully EFI booting is more settled now.

Thanks for the help. I will certainly keep this thread informed as I go along my merry way.

Tony0945 · Post by **Tony0945** » Mon Sep 07, 2020 1:57 am

OK! I'll report back too on my NVME and Ryzen 3900 adventure. Together we will muddle through.

Tony0945 · Post by **Tony0945** » Mon Sep 07, 2020 2:53 am

depontius wrote:That's interesting to see. So the critical partition for booting is now "/boot/efi",

I think that's just a convention. You could call it /efi or /mnt/efi or /mymotherinlaw. The boot system doesn't know about the Linux names. It just searches the first partition on the drive, which must be vfat, partition for files ending in .efi

The Doctor · Post by **The Doctor** » Mon Sep 07, 2020 3:25 am

Firmware will always look for kernel called /efi/boot/bootx64.efi in the vfat partition. I'd put a kernel there that can boot the computer. It should be as simple as taking a working kernel and using a built in command line. It should also be configured to boot in EFI mode naturally, but I think you already have to do that. That kernel will work even if rEFInd gets borked somehow.

You can modify the firmware to use any file in the vfat partition but the above is the standard that is guaranteed as far as I know. The way rEFInd works is that it modifies the EFI firmware to look at its kernel and uses that small operating system to load your linux (or other) kernel and start the boot process.

Goverp · Post by **Goverp** » Mon Sep 07, 2020 7:56 am

Tony0945 wrote:OK! I'll report back too on my NVME and Ryzen 3900 adventure. Together we will muddle through.

FWIW, my similar machine uses Grub, and I found it much easier to setup than rEFInd. I just installed Grub, generated grub.cfg, and edited the result down to what I'd have typed for a manual configuration in legacy Grub days (i.e. using /boot/vmlinuz and /boot/vmlinuz.old), using grub-config to get the syntax right.

I'll post my new glitzy "one .cfg fits all" configuration when I'm back at that machine.

Anon-E-moose · Post by **Anon-E-moose** » Mon Sep 07, 2020 9:35 am

The only constraints on efi partitions, AFAIK, are formatted fat32 with flags boot and esp, as far as the name, I don't think it matters.

On the efi partition, he does want to see an EFI directory and possibly a BOOT directory. When I mount the EFI parition on my running system, I mount on the old /boot mount point.

I looked at refind and it appeared to be more complex than I needed, as I just wanted a simple EFI boot, I vaguely remembered that Kay Sievers (yeah I know

) had written a efi boot loader called gummiboot. Simple, curses style graphics, simple text files describe where/what, so I found a copy of the last working ebuild and the tarball, compiled it and that's what I use. Unfortunately the days of simple cmd line graphics went bye-bye when systemd absorbed gummiboot and renamed it, now it's another ball of crap tied to systemd.

Code: Select all

$ find /boot -type f -print
/boot/EFI/gummiboot/gummibootx64.efi
/boot/Boot/BOOTX64.EFI
/boot/current/vmlinuz
/boot/current/System.map
/boot/admin/System-gentoo.map
/boot/admin/gentoo
/boot/admin/gentoo-config
/boot/admin/image.squashfs
/boot/admin/gentoo.igz
/boot/loader/entries/admin.conf
/boot/loader/entries/gentoo.conf
/boot/loader/entries/gentoo-5.5.conf
/boot/loader/entries/gentoo-last.conf
/boot/loader/entries/gentoo-single.conf
/boot/loader/loader.conf
/boot/livecd
/boot/last/System.map
/boot/last/vmlinuz
/boot/gentoo-5.5/System.map
/boot/gentoo-5.5/vmlinuz

Code: Select all

Model: Unknown (unknown)
Disk /dev/nvme0n1: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  2149MB  2147MB  fat32        EFI      boot, esp
 2      2149MB  500GB   498GB   btrfs        root-n1

depontius · Post by **depontius** » Mon Sep 07, 2020 10:52 am

This is all quite interesting, and probably stuff I should have learned back in 2013 when I first installed this system.

So I can see "/boot/efi" getting found by the EFI BIOS, because it's a partition and has the "boot" and "efi" flags. In my "refind.conf" file I see a UUID pointer to my root filesystem in what looks like a kernel command line. That's good too, and if this was as far as it went, I would see how the system could start.

In the system I'm running now, my kernels sit in a "/boot" partition, separate from root. I don't see how the heck rEFInd can find my kernels. Does it know how to read /etc/fstab?

Anon-E-moose · Post by **Anon-E-moose** » Mon Sep 07, 2020 11:37 am

Not sure if gentoo has a wiki page (I briefly looked and it wasn't obvious if they have it)

https://wiki.archlinux.org/index.php/REFInd

As far as whether refind reads filesystems, I would say yes, given the use flags

Code: Select all

$ eq u refind
...
 - - btrfs    : Builds the EFI binary btrfs filesystem driver
 - - doc      : Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of
                globally
 + - ext2     : Builds the EFI binary ext2 filesystem driver
 + - ext4     : Builds the EFI binary ext4 filesystem driver
 - - hfs      : Builds the EFI binary hfs filesystem driver
 + - iso9660  : Builds the EFI binary iso9660 filesystem driver
 - - ntfs     : Builds the EFI binary ntfs filesystem driver
 - - reiserfs : Builds the EFI binary reiserfs filesystem driver

depontius · Post by **depontius** » Mon Sep 07, 2020 11:53 am

My rEFInd installation was manual, predating the ebuild. Once I'm done with the musical motherboards and cases, I'll be installing my new system from scratch, and hopefully it will be with more understanding of EFI boot than last time. Assuming I'm successful I'll reinstall rEFInd on what will by then be my wife's computer with the ebuild.

depontius · Post by **depontius** » Mon Sep 07, 2020 1:33 pm

I just realized that I probably have to reinstall rEFInd in order to move to ssd. I'm planning on using f2fs for the new ssd, and it has seen a LOT of work in the past seven years. I don't know how old f2fs is or if a 2013-era rEFInd supports is, but chances are that that support is stale, at this point.

I see now that the case has 2 3.5 bays, so I can install both hdd and ssd, and do this migration later.

Anon-E-moose · Post by **Anon-E-moose** » Mon Sep 07, 2020 2:05 pm

I'm not sure refind will work with a f2fs filesystem, as least the same way it does with other filesystems.

When I built my new machine I mounted the sda drive from the old one machine, did all my copying and just left it (unmounted) but live if needed, since it's an ssd and I'm not using it I don't worry about drive failure on it, just costs a few m-watts of power.

Tony0945 · Post by **Tony0945** » Mon Sep 07, 2020 2:45 pm

rEFInd searches all the partitions that it can find on the disks and has a driver for. It looks for Linux kernels, Windows/MAcOS booters. I have no idea how. I've never looked at the code.
The refind.conf has overrides to tell it what to search for and which partitions to not search for. There are explanations in the sample file.
Here is a working config with the comments stripped out.

Code: Select all

timeout 5

showtools shell, gdisk, memtest, about, reboot, exit, firmware

scanfor internal,external,optical,manual biosexternal

dont_scan_volumes LABEL="SAGE_VIDEO"  LABEL="P1-1TB" LABEL="P2-1TB" LABEL="P3-1TB"

fold_linux_kernels false

default_selection 1

menuentry Linux {
    icon EFI/refind/icons/os_linux.png
    volume 904404F8-B481-440C-A1E3-11A5A954E601
    loader bzImage-3.3.0-rc7
    initrd initrd-3.3.0.img
    options "ro root=UUID=5f96cafa-e0a7-4057-b18f-fa709db5b837"
    disabled
}

menuentry "Arch Linux" {
    icon     /EFI/refind/icons/os_arch.png
    volume   "Arch Linux"
    loader   /boot/vmlinuz-linux
    initrd   /boot/initramfs-linux.img
    options  "root=PARTUUID=5028fa50-0079-4c40-b240-abfaf28693ea rw add_efi_memmap"
    submenuentry "Boot using fallback initramfs" {
        initrd /boot/initramfs-linux-fallback.img
    }
    submenuentry "Boot to terminal" {
        add_options "systemd.unit=multi-user.target"
    }
    disabled
}

menuentry Ubuntu {
    loader /EFI/ubuntu/grubx64.efi
    icon /EFI/refind/icons/os_linux.png
    disabled
}

menuentry "ELILO" {
    loader \EFI\elilo\elilo.efi
    disabled
}

menuentry "Windows 7" {
    loader \EFI\Microsoft\Boot\bootmgfw.efi
    disabled
}

menuentry "Windows via shell script" {
    icon \EFI\refind\icons\os_win.png
    loader \EFI\tools\shell.efi
    options "fs0:\EFI\tools\launch_windows.nsh"
    disabled
}

menuentry "My macOS" {
    icon \EFI\refind\icons\os_mac.png
    volume "macOS boot"
    loader \System\Library\CoreServices\boot.efi
    disabled
}

Those menu entries are from the standard installation and are disabled. One would have to change them to enable them. I didn't bother.

"default_selection 1" The kernels it found are listed in date sequence. With "default_selection 1" the latest kernel is the default. You never have to edit a menu again, so it is MUCH EASIER TO USE than grub.

Tony0945 · Post by **Tony0945** » Mon Sep 07, 2020 2:59 pm

depontius wrote:In the system I'm running now, my kernels sit in a "/boot" partition, separate from root. I don't see how the heck rEFInd can find my kernels. Does it know how to read /etc/fstab?

It searches ALL the partitions that it can find and read. That's why I have the "don't scan volumes" line. The partitions listed there (by LABEL, It could also be by PARTUUID and maybe more) have kernels for projects. They are not meant for the build box. I don't want rEFInd offering them for boot. The server system has backups for the workstations. I don't want them offered on the server also. If YOUR system doesn't have stray kernels, the default search everything will be OK. It seems to work very fast.[/code]

Could post the results of "grep -v ^# `locate refind.conf` "? or just pastebin the whole file?

Since it's searching every partition, it doesn't matter if they are on a separate partition or not. The booting kernel has to find ROOT either by kernel default or kernel command line. I always had an embedded command line even with grub-legacy. Your system is booting now with your older rEFInd. How does it find ROOT? You don't use rEFInd to boot grub do you?

Tony0945 · Post by **Tony0945** » Mon Sep 07, 2020 3:12 pm

The Doctor wrote:Firmware will always look for kernel called /efi/boot/bootx64.efi in the vfat partition. I'd put a kernel there that can boot the computer.

Code: Select all

tony@MSI ~ $ find /boot/efi -name *.efi
/boot/efi/EFI/refind/refind_x64.efi
/boot/efi/EFI/refind/drivers_x64/ext4_x64.efi

bootx64.efi was what was giving me the double boot. It's GONE! First I renamed it to bootx64.efi.old, then I rebooted, making sure I had a resuecd in the DVD drive. Problems solved. So I just deleted it. Working fine.

Tony0945 · Post by **Tony0945** » Mon Sep 07, 2020 3:37 pm

Anon-E-moose wrote:I'm not sure refind will work with a f2fs filesystem, as least the same way it does with other filesystems.

When I built my new machine I mounted the sda drive from the old one machine, did all my copying and just left it (unmounted) but live if needed, since it's an ssd and I'm not using it I don't worry about drive failure on it, just costs a few m-watts of power.

Selecting an EFI Driver
I don't see h2fs listed there. So, depontius should either keep his separate boot with a supported filesystem like ext4 or btrfs or contact Rod Smith and ask him about f2fs support. The first course is the easiest. As long as the kernel in /boot supports f2fs it should work.
Personally, I'll stick with ext4 until the majority has moved to something else. I started with reiserfs and kept it until most everyone had moved from ext2 to ext3 then I moved to ext3. ditto with ext4. I don't want some unknown bug to suddenly wipe my disk.

Learned something new. I learned a modern use for separate boot partition.

BTW, the default menu is shown here: https://www.rodsbooks.com/refind/ With more than one kernel you see multiple Tux pengyins.
However, when I updated to the latest ebuild (you have to run refind-install afterward), I now have a string of Gentoo "G" icons. Don't know if Rod smith did that or our proxy maintainer, Stéphane Veyret, who might be a good resource also.

Goverp · Post by **Goverp** » Tue Sep 08, 2020 8:20 am

Tony0945 wrote:It searches ALL the partitions that it can find and read. That's why I have the "don't scan volumes" line. The partitions listed there (by LABEL, It could also be by PARTUUID and maybe more) have kernels for projects. They are not meant for the build box. I don't want rEFInd offering them for boot. The server system has backups for the workstations. I don't want them offered on the server also. If YOUR system doesn't have stray kernels, the default search everything will be OK. It seems to work very fast.
...

FWIW I installed rEFInd manually (I didn't like the look of its installer) and never got around to making a refind.conf; it works fine without one, albeit with one small message complaining about its absence.

Anon-E-moose · Post by **Anon-E-moose** » Tue Sep 08, 2020 9:10 am

https://www.rodsbooks.com/refind/linux.html Nice explanation of what refind does. Scroll down to "EFI Stub Loader Support Technical Details", with some examples of setup further down in the quoted (below) stuff.

rEFInd supports semi-automatic Linux EFI stub loader detection. This feature works as part of the standard boot loader scan operation, but it extends it as follows:

rEFInd looks for boot loaders whose names include the strings bzImage, kernel, or vmlinuz. For instance, bzImage-4.15.0.efi or vmlinuz-5.4.0 would match, and trigger subsequent steps in this procedure. The scan_all_linux_kernels option in refind.conf controls the scanning for kernels whose names do not end in .efi; if this option is set to false, kernel filenames must end in .efi to be picked up by rEFInd. This option is set to true by default, but you can change it if you don't want to scan all Linux kernels.

If a file's name ends in .efi.signed, any other file with an otherwise-identical name that lacks this extension is excluded. This peculiar rule exists because old versions of Ubuntu deliver two copies of every kernel, one with and one without this extension. The one with the extension is signed with a Secure Boot key; the one without it is not so signed. Thus, if both files are present, the one without the key won't boot on a computer with Secure Boot active, and either will boot if Secure Boot is inactive. Thus, rEFInd excludes the redundant (unsigned) file in order to help keep the list of boot options manageable.
....

Tony0945 · Post by **Tony0945** » Tue Sep 08, 2020 1:56 pm

Goverp wrote:FWIW I installed rEFInd manually (I didn't like the look of its installer) and never got around to making a refind.conf; it works fine without one, albeit with one small message complaining about its absence.

The default refind.conf is all commented out except for the manual stanzas which are disabled by default anyway.
Take a look at the confih I posted above. Wouldn't you like to at least drop the timeout from 20 seconds? Unless you never reboot remotely. If you only turn it on or reboot it when sitting in front, I suppose it doesn't matter if the timeout is 20 years. Also I told it to not look for PXE boot. That's not obvious because it's a configuration by absence. The default does look for it. It's in my BIOS and I can't delete it from the BIOS. But I can tell rEFInd to ignore it. IMHO, rEFInd is THE boot engine for EFI. Grub is for BIOS boot, with it's constant editing. How many people on this forum have rebuilt their kernel and forgotten to update grub? How many have made a typographical error in editing and think they have a kernel error because it won't boot?

A one line refind.conf changing the timeout would get rid of your boot error messages. Perhaps even "touch refind.conf".

Ant P. · Post by **Ant P.** » Tue Sep 08, 2020 2:54 pm

Anon-E-moose wrote:The only constraints on efi partitions, AFAIK, are formatted fat32 with flags boot and esp, as far as the name, I don't think it matters.

Technically EFI is allowed to support any filesystems it wants, it's just that all x86 mainboard makers are as lazy as possible when it comes to firmware and do the bare minimum that gets windows to boot, which happens to be fat32.

Tony0945 · Post by **Tony0945** » Tue Sep 08, 2020 3:49 pm

Ant P. wrote:
Anon-E-moose wrote:The only constraints on efi partitions, AFAIK, are formatted fat32 with flags boot and esp, as far as the name, I don't think it matters.
Technically EFI is allowed to support any filesystems it wants, it's just that all x86 mainboard makers are as lazy as possible when it comes to firmware and do the bare minimum that gets windows to boot, which happens to be fat32.

Ah! So it's not part of the spec, just commercial practice.

depontius · Post by **depontius** » Tue Sep 08, 2020 4:07 pm

Reality smacked me in the head yesterday evening, so my plans have changed a bit.

I didn't describe it earlier, but this is part of a big computer-part food-chain event. I have a new motherboard/cpu/etc, but the case I want to install it in is currently housing my server. The original plan was to put my motherboard in a new case and give it to my wife. Then take her motherboard, using a spare case, and build a new server. Then decommission the current server and use the case for my new components.

Except that my current motherboard isn't micro-atx, which I'd thought it was. She needs a slimline case, and that effectively means micro-atx, especially for the new one I bought for her. So the food-chain plan went kerflooey.

Except then I looked at my now-old motherboard and realized that it has 8 SATA ports, and the case has plenty of drive bays. So I put my now-old system back together and will re-purpose that as the new server. I've also pulled half of the 32G of memory. I can bump my wife from 8G to 16G, and give her the ssd. The new server will still have 16G, which is twice what the current server has. Improvement all around, and I suspect that the ssd will be what she notices most.

But this also means that her upgrade will wait until last, instead of being first. By the time I get to her I'll have done a new EFI install on my new machine, and should be a bit more familiar.

Goverp · Post by **Goverp** » Wed Sep 09, 2020 7:19 pm

Tony0945 wrote:.... Grub is for BIOS boot, with it's constant editing. How many people on this forum have rebuilt their kernel and forgotten to update grub? How many have made a typographical error in editing and think they have a kernel error because it won't boot? ...

I've put my grub.cfg on one of my Gentoo wiki pages.
Once installed, you need never update GRUB (apart from package updates, of course).
The page includes information on how to test changes to grub menus before installing them.