I have several questions on UEFI versus Legacy boot, but I'll ask them one at a time.

I have been staging an webserver application on an old Legacy booting computer (Slackware 15.0) for a customer. When done, I need to take this to the customer's site and install it on their hardware. Their computer will be UEFI.

How do I do this? Do I first have to run a "dummy" installation of Slackware creating the EF00 EFI Partition, then running through the whole install until it asks me if I want to install elilo, then restoring my 'Legacy boot' root partition to the new computer? Is there a simpler way?

Basically, these are two different questions:

1. How to switch between legacy boot and UEFI boot
2. How to restore a reference installation the best way

If you have an old legacy installation the risk is high that it has an old MBR DOS-style partition table. To boot with UEFI you will need a GPT partition table to create your EFI partition.

I can't say for sure if it works with every BIOS, but to my surprise I have found at least one BIOS capable of booting with legacy boot (lilo) with a GPT partition table. On the other hand, during the years, I have also seen BIOSes refusing to boot unless a partition was marked as "active" (a feature of DOS/MBR partition tables) so that BIOS would probably not be able to boot a GPT partition table.

But, if you are lucky, you might be able to make an installation with a GPT partition table with an EFI partion for UEFI boots and something like lilo in the MBR of the disk for legacy boots. It will probably not work with all old computers, but with most. On UEFI systems you will probably somehow in their BIOS point out what to boot. Such a solution will also require you to update two bootloaders everytime you upgrade the kernel.

I have seen many lazy people create disk clone image files of their reference installations. It might seem tempting and will work fine for some time. Then, one day, you want to upgrade the OS installation but still keep all your customizations. With the disk clone image backup plan you will have a hard time trying to remember all the customizations that you have done.

As a Slackware user I prefer to make my own custom Slackware packages for every software that I add and every setting that I change. That makes it easy to reproduce the installations and one day, when I want to start from scratch with a newer version of Slackware I know exactly what I have added or changed before. I might not be able to reuse all packages unmodified, but I know exactly what I need to do again.

Having an easy way to reproduce a system is also part of a backup strategy, but you will need some other backup plan for data like the things in users home directories.

If you are only installing a few systems you might think that it is too much work to create your own custom packages. If so, you might instead keep notes of all the customizations that you do so that you can redo them again by following your notes.

regards Henrik

I had a 2012 Samsung with AMI BIOS, and you could only do legacy boot with MBR. GPT meant UEFI, enabled or not. There were 1000s of ways to have it not booting, not many that actually worked.

EDIT: As for post #1, buy a HD. Install on a UEFI machine and test booting. Use a boot disk if need to boot on legacy machine while testing/configuring.

After staging web application how are you going to transplant to the new hardware?

Combining all of the above:

Install slackware-15.0 onto client's device the regular way, except use gdisk instead of fdisk when formatting, and configure elilo instead of lilo.

Create a slackware package out of your web application: make a directory, and inside that directory, mirror a slackware linux install, with directories, for /usr, /lib, /var, and well, any of the ones that contain the parts of your web application. You don't have to have all the other files and contents, just the directory structure, and the files and contents of your application where they go within. Then from within that directory, the makepkg command creates a slackware package. You probably knew this already, but I woke up this morning with the -v coming up in my alphabet cereal...

Copy your app's slackware package over to the clients system and install it

GPT actually reserves the old MBR area and lilo can still install there. As long as you don't get crazy with a really large number of logical paritions that lilo can't handle I think you will be fine. In any case you'll know you have problems right away because you are moving from bios -> uefi and not the other way round, so that should help.

Basically just install like you always do but use gdisk and not fdisk and make guid partition table.

Make a 250meg or so EFI partition, format it fat32 and mount it on /boot/efi

Also make sure you install the elilo package.

use the blkid utility and update all the fstab entries to mount by UUID rather than /dev/XYZ the installer might have generated, this isn't strictly needed but I find often makes things generally more portable and can simplify life later on.

When you move the drive you will need alternative boot media, but if you are using the stock kernel you should be able to pass the rootfs argument and point at your installed system. Go thru the elio setup and reboot.

That is the top level outline, the docs should cover the rest.

This seems a rather random recommendation. The minimum ESP size if the disk has 4k sectors without 512b emulation, and is 16T or larger, is 260. Windows only requires 100, and uses only a tiny fraction of it. Mine are all multi- multiboot Linux systems with 320M ESP, and ESP usage averages under 10%.

Yep completely unscientific just big enough to ensure there won't be problems.

So, there is no CSM in the UEFI firmware of that server? Then, I strongly recommend you to ensure also that that server is not Secure Boot only. Because no CSM usually also means no ways to disable Secure Boot.

And IF happens that Secure Boot to be required/enforced, the stock Slackware 15.0 will NOT boot on that machine.

Thanks for all the feedback. I'm not sure I communicated clearly. I am developing this web app on an up-to-date Slackware 15.0 system booting legacy MBR and using lilo. The target system will have completely blank drives to start, but the "bios" will be UEFI. I don't want the target system to boot CSM/Legacy, so I don't care anything about the MBR record.

My 1st thought was along the lines recommended by slac-in-the-box by installing a new Slackware 15.0 from DVD. Then restoring everything from my development system except /boot and making the necessary adjusments in /etc/fstab. After much pain and suffering I did already manage to figure out how to create a UEFI booting Slackware system with EFI partition etc., thanks to help from colorpurple21859, see: https://www.linuxquestions.org/quest...ll-4175723159/

But, the reason for this post is that I was hoping there was a faster way than creating a complete new Slackware system from DVD. I though I could perhaps create the correct gdisk partitions, then restore from backup my development system, the run a couple of tools to convert it to booting UEFI; like manually copying the vmlinuz to /boot/efi/EFI/Slackware/ and running a "magic" app that would put whatever is needed in the UEFI boot sector(s) and create the elilo.conf and elilo.efi files in /boot/efi/EFI/Slackware/. Not to get into the weeds, but when I restore a MBR backup to a virgin disk (done many times) I will:
What I don't have to do with this procedure is first create a new Slackware system from DVD, do slackpkg update/upgrade all, then restore the root partition. I was hoping there was some similar procedure for restoring the root partition to a UEFI system w/o first creating a whole new install.

But if not, so be it. If I go the "new install" route, are the only things I have to worry about are, as I mentioned, /boot and /etc/fstab? In fact, I supposed I could also not restore bin/ etc/ lib/ lib64/ opt/ sbin/ usr/ var/. I'd rather not restore /etc as that has group, passwd, httpd, rc.d and other modified config files.

Is there something like the 7-step procedure to restore from backup? Do I really have to install a new system on the target machine first?

@mfoley you've missed 8. /etc/fstab
Because maybe, something changed and you may have to write different disk names there.
Long time ago if you did such migration, it may have been: sda suddenly became hdb. Today, probably sdb became nvme0p2 or simiilar.
TLDR; always double check fstab.

1 members found this post helpful.

Remember toA new one will be automatically generated to have the mac address of the new network interface. (If you don't remove it, you will have non-working eth0 reserved for the old network card and a working eth1 for the new card.)

2 members found this post helpful.

I don't think eliloconfig will run on a legacy system. Will have to manually copy /boot/elilo-x86_64.efi to EFI/Slackware/elilo.efi, along with the kernel to EFI/Slackware/vmlinuz and initrd if you use the generic kernel and manually create an elilo.conf file. I suggest to also create a EFI/BOOT directory and copy the the files from the Slackware directory and rename elilo.efi to Bootx64.efi. The should allow the new system to boot if slackware bootloader isn't registered into the firmware of the new system during installation.

The biggest hurdle will be if secure-boot cannot be disabled on the new system. https://docs.slackware.com/howtos:se...ng_secure_boot
As has already been mentioned may have to edit /etc/fstab for the new system depending on how you transfer the system over.

Who is going to be responsible for updates? If it is the customer, I would suggest to use either grub or rEFInd as boot loader for they can be setup so the only thing that needs to be done with a kernel update is re-generate an initrd if one is use.

This completely depends upon how you made your backup. As said before, to create and restore disk images are easy, but that solution has drawbacks.

If you haven't already thought of some kind of backup plan you should do that. This is a link to some web pages (less than 10 pages, they are easy to read and understand and also entertaining) with good thoughts about backup:

http://www.taobackup.com/

regards Henrik

2 members found this post helpful.

Can't he install lilo for legacy on the MBR, AND elilo for UEFI? They won't trip over each other, will they? You'd need to test it as it is definitely non-kosher, but it should work as elilo boots the EFI partition, and lilo boots the MBR.