Debian/Refracta UEFI installation to new drive

[Hedon James]

I looked at rEFInd as a potential solution, but was afraid of opening another can of worms, and I had enough "new" tickets open.  I also considered a UEFI/BIOS "hybrid" called CSM (compatibility support module) that allows UEFI systems to boot in legacy BIOS mode.  But I'm also upgrading my Backup Drive to a 4TB internal, and I needed a GPT format for that size drive.  Or at least I think I needed UEFI/GPT for that...  Even if I didn't, figured I just needed to bite the bullet and get it all sorted out sooner rather than later.

 

I'm relieved that's behind me (knock on wood), as it's my main work machine and it can't be down for any length of time.  So I only have Friday night and Saturday to get it installed, knowing I need most of Sunday to complete signing into accounts with new machine/browser, backups, autostarts, etc...

 

Not looking forward to the next time, although maybe all this UEFI stuff will be sorted out by then.  In 5 years, I'll try to "upgrade Debian 10" in place.  And if that fails, this machine will be about 10-15 years old, and perhaps due for an upgrade.  I'd like a Ryzen7 or 9, but can't justify it when the old hardware is still pretty D*** good.  Current specs:

jim@Asus-SS:~$ inxi
CPU: Quad Core Intel Core i7-4770 (-MT MCP-) speed/min/max: 1168/800/3900 MHz Kernel: 4.19.0-8-amd64 x86_64 Up: 2h 35m
Mem: 2382.4/15727.3 MiB (15.1%) Storage: 5.70 TiB (12.5% used) Procs: 244 Shell: bash 5.0.3 inxi: 3.0.32

 

[sunrat]

Sounds like you had fun. Interesting exercise but too taxing for me. I recently had to use REFInd and I'm convinced it's made of magic beans. It allows you to boot an installed system which has no boot loader and then all you need to do, providing you have an ESP already, is

grub-install

update-grub

I also had to change fstab to reflect a new swap UUID. It was different as I was reinstalling a cloned Debian to a different drive.

 

Debian allows you to copy a list of installed packages from an installed system to a new one and I worked out the easiest way to do this. It's not documented anywhere but worked well.

First get a list of packages from the source system and remove the ones which have been uninstalled:

dpkg --get-selections |awk '!/deinstall/' >package-selections

Then install on the new system:

apt install $(cat package-selections | awk '{print $1}')

Obviously you need to run the install from the directory with the "package-selections" file, or give its full path. You could also move the awk command in the install bit to pipe in the first command. Same same but different.

[raymac46]

Well my adventures with UEFI date back about 6 years when I first was playing with Linux on my then new desktop. As I recall I was eager at the time to try UEFI out and GRUB was still a little funky when it came to EFI booting. So I used rEFInd and that was great.

When I installed LM on an SSD I seem to recall it went with a legacy msdos format. Since I was then reformatting my HDD (1TB) I saw no need to keep it GPT and just went back to legacy. The motherboard doesn't care.

[abarbarian]

20 hours ago, sunrat said:

Sounds like you had fun. Interesting exercise but too taxing for me. I recently had to use REFInd and I'm convinced it's made of magic beans. It allows you to boot an installed system which has no boot loader

 

You would have to be running an os with a kernel older than 3.3.0 as an EFI stub loader has been included since. So you do not need any other stuff like Grub, Syslinux or Elilo or any other loader.

 

[abarbarian]

On 2/23/2020 at 3:39 PM, securitybreach said:

Great job. I didn't bother to mention your grub-install line as that is what most of the tutorials tell you to do anyway. I had always used that when installing archlinux on machines.

 

grub-install  --target=x86_64-efi  --efi-directory=/boot/efi  --bootloader-id=grub_uefi  --recheck

 

Glad that you finally got it resolved.

 

 

 

 

 

Why on earth are you messing around with Grub ?

All that extra work an all them extra files and folders seems ataqd old hat and  a tad anti KISS to me.

[Hedon James]

22 hours ago, sunrat said:

Sounds like you had fun. Interesting exercise but too taxing for me. I recently had to use REFInd and I'm convinced it's made of magic beans. It allows you to boot an installed system which has no boot loader and then all you need to do...

 

I'm interested in learning more about this rEFInd.  The only thing I know....or I THINK I know....is that it seems to be a standalone program that is an "umbrella" bootloader, preventing OSes from over-writing each others' bootloaders and "losing" partitiitons or entire OSes because their bootloader was overwritten.

 

Tell me more?  or link me?

[sunrat]

It's just a 2MB iso image you write to USB or CD, then boot with it and it finds kernels on the system and enables booting directly to them.

http://www.rodsbooks.com/refind/

[abarbarian]

On 2/24/2020 at 7:59 PM, Hedon James said:

 

I'm interested in learning more about this rEFInd.  The only thing I know....or I THINK I know....is that it seems to be a standalone program that is an "umbrella" bootloader, preventing OSes from over-writing each others' bootloaders and "losing" partitiitons or entire OSes because their bootloader was overwritten.

 

Tell me more?  or link me?

 

As I understand it.

 

At start up from the bios the pc looks for a "boot manager"  whose job it is to look for possible "boot loaders" whose job it is to boot the system.

 

The rEFind program looks for boot loaders and shows them on the screen, that is all it does until you make a choice of which boot loader to use then it tells the boot loader to proceed.

 

On a single os pc rEFind would usually give you a main choice, your standard normal use initramfs. Then it usually has several other options like fallback initramfs.

 

On my dual boot set up rEFind shows me my Arch and my Windows boot loaders. If I have a live so on a stick inserted like MX-19 on boot up then rEFind shows me Arch,Windows and MX-19 along with all their secondary options.

 

So rEFind simply scans folders and files it is given access to for ".efi" files as they are the "boot loaders".

 

My dual boot shows that I have in the Windows folder three .efi files,

 

bootmgfw.efi, bootmgr.efi ,  and ,memtest.efi

 

for Arch there is simply refind_x64.efi, all of these .efi files have the ability to boot the pc. They could exist anywhere on the pc as long as their path is know in the rEFind .config file.There are two of these, a simple to set (the one I use) and a more elaborate one which I have only researched a little.

 

. I like that rEFind finds and shows all the os's available at boot with no extra work needed for usb or externaly mounted hdd/ssd's etc. Also the more elaborate .config is pretty easy to navigate and set up allowing you to easily choose which icons to use for instance. The standard showing on the screen is pretty nice and I could see with a tiny tweak here and there it would be very neat indeed.  All in all as a new user I found it much easier to use than Grub.

 

Hope that helps a tad.

 

Further info

 

https://www.rodsbooks.com/efi-bootloaders/fallback.html

"

What's the Problem?

"As described in EFI Boot Principles, the EFI boot process relies on both EFI boot loaders on the ESP and pointers to those boot loaders in the computer's NVRAM. Unfortunately, many circumstances can break the link between these two components—some EFIs have bugs, or the NVRAM entries can become damaged or lost; some EFIs deliberately delete invalid NVRAM entries, which can cause them to disappear if you deliberately (but temporarily) unplug a hard disk; you might intentionally or accidentally move a boot loader file; and so on. Such common occurrences can render a computer unbootable and necessitate using a recovery disk to restore bootability by re-creating the NVRAM entry with a tool such as efibootmgr, as described in EFI Boot Loader Installation. Such a repair can be beyond the abilities of the average user, or at least, can require following (not to mention first locating!) technical instructions that the user may find challenging.

Windows is not greatly affected by this problem. Because Windows is the 800-pound gorilla of the OS world, many EFIs are designed to look for the Windows boot loader (EFI/Microsoft/Boot/bootmgfw.efi) if nothing else is available. Windows also installs a copy of this boot loader in the fallback position of EFI/BOOT/bootx64.efi (or similar names for other architectures). Thus, Windows tends to keep booting even if its NVRAM entry is lost. Linux distributions, though, are another matter; if their NVRAM entries are lost, they tend to stop booting—or perhaps the computer will begin booting straight to Windows, which can be as frustrating to users."

 

https://superuser.com/questions/1261860/difference-between-bootmgr-efi-and-bootmgfw-efi

 

"bootmgr.efi the Windows boot manager on systems with BIOS firmware. This file will be loaded as part of the BIOS boot process - typically the boot device is set in the BIOS. Assuming the boot device is a hard disk type device then the Master Boot Record is loaded > the Active Partition is identified in the Partition Table > the Partition Boot Record (PBR) on the Active Partition is loaded > code in the PBR loads bootmgr > bootmgr loads the BCD file.

 

bootmgfw.efi - the Windows boot manager on systems with UEFI firmware. This file is loaded directly from the Windows Boot Manager entry in the Firmware Boot Menu stored in NVRAM. Typical boot process is Firmware Boot Manager > \EFI\Microsoft\boot\bootmgfw.efi on the EFI System Partition is loaded via the Windows Boot Manager entry > bootmgfw.efi loads the BCD file (path to BCD file - \EFI\Microsoft\boot\BCD)."

 

I do have a "bootx64.efi" but did not mention it as it might have caused a nit of confusion into a straightforward affair. The "refind_x64.efi" is the one for my Arch os though.

 

 

Edited February 28, 2020 by abarbarian

[Hedon James]

26 minutes ago, abarbarian said:

Hope that helps a tad.

 

WOW!!!  A LOT of useful information there.  Much of it over my head, for now, but always looking for new learnings.  That DOES help a tad!  Thanks AB!

[sunrat]

I read all that and still don't understand it. REFInd found and booted my newly restored (from the original no longer connected drive) Debian system on a brand new drive even though there was no entry in ESP as that was fresh from a new Win 10 install. If it was finding it via NVRAM entries, why didn't it find the other 3 Linux systems that existed as multiboot before I changed the system drive?

[abarbarian]

On 2/25/2020 at 10:01 PM, sunrat said:

I read all that and still don't understand it. REFInd found and booted my newly restored (from the original no longer connected drive) Debian system on a brand new drive even though there was no entry in ESP as that was fresh from a new Win 10 install. If it was finding it via NVRAM entries, why didn't it find the other 3 Linux systems that existed as multiboot before I changed the system drive?

 

No idea why it did not find any of your other os's and can not offer any thoughts as to why. I find rEFind much less confusing than Grub though which is why I stick with it.