Switching my system to UEFI this weekend.
 

My plan for this weekend is to switch my dual-booting system to UEFI. I plan to end up with a BIOS firmware boot menu containing two entries: one for a UEFI-booted Windows (7) and one for a UEFI-booted Slackware.

Currently, both operating systems are on legacy-mode boots. I plan to change that, and I hope this will let me get away bootloader-chaining, MBR-overwriting, and the "add Windows to lilo.conf" complexity that we're all used to dealing with.

I've read this to prepare:

UEFI boot: how does that actually work, then?

And that's "a UEFI" and not "an UEFI", right? It assume it's pronounced "Yuffie?" Like the Final Fantasy character?

slackdocs seems to be slow right now, but I did write some info about UEFI when I switched, dunno if it will be useful:
http://docs.slackware.com/howtos:sla...uefi_and_elilo

Do report how it went. I've been thinking about it for some time on my laptop.

In-place ?. That could be an interesting exercise. I had no end of trouble with Win7 (64-bit) installing on a new-build UEFI m/board - Win7 was an OEM rather than commercial copy and apparently makes quite a difference. I will also be watching with interest.

[caveat]On the system in question I have neither Slack nor elilo[/caveat]

I also switched from BIOS to UEFI on my laptop.
Switching Windows was a headache, Linux not so much.

Here is a wiki page I had written and subsequently refined: https://wiki.manjaro.org/index.php?t...m_BIOS_to_UEFI

To switch, I converted my MBR partition table to GPT using http://www.rodsbooks.com/gdisk/mbr2gpt.html

Then created a UEFI partition (fat32 - 512mb), and switched to UEFI in the firmware.

Then I booted Windows installation disk, and tried automatic repair many times, which probably did not work for me, so tried to install Windows bootloader manually onto the uefi partition using the bcdboot command.
(The following I found later: http://superuser.com/questions/46076...efi-bootloader)

After that I booted to my Linux install through chailoading via an external drive which runs Debian (and Grub), and ran the command to installing Grub-
But my laptop's firmware only recognises Windows (HP), so I had to install rEFInd for dual-booting.
https://wiki.manjaro.org/index.php?t...g_with_Windows

Alternatively, one can copy the grubx64.efi file to the Boot folder inside the EFI partition to make Grub default.
http://www.rodsbooks.com/refind/installing.html#naming

That was actually very painless.

My rig is a tower containing three hard drives: on SSD for Windows, one SSD for Linux, and an NTFS-formatted Caviar Red for storage. The motherboard is an Asus H87-Plus.

I decided to go for the "back up, wipe, install fresh" approach.

First, I disabled secure boot. It turns out that I'd had it on the entire time, and I never noticed because I was booting my operating systems in legacy mode.

Then I backed everything up, and started reinstalling Windows. I set the "CSM" setting in my firmware to "auto" and told my computer to boot the installation disc in UEFI mode. When the installation CD let me repartition the hard drives, of course I accidentally partitioned (and wiped out) the storage drive. That was fine, because I knew I would make that mistake and had backed the drive up. The rest of the installation went as normal. From Windows, I then repartitioned the storage drive, formatted the partition to NTFS, and restored the contents of the storage drive from the backup.

Then I booted my Slackware64 14.1 DVD in UEFI mode, and essentially proceeded according to README_UEFI.TXT.

I chose not to boot the kernel with KMS.

I used cgdisk to create three partitions on my Linux drive:

• An EFI System Partition, size 100M (code EF00)
• A Linux swap partition, same size as my RAM (code 8200)
• A Linux partition, default size and code

When asked whether I wanted to add an EFI boot menu entry for Slackware, I said yes. I then rebooted.

Now, the boot menu that I get when I press F8 at boot has two entries: one for Windows (actually named Windows) and one for Linux (actually named Linux). Both entries were put there by the Slackware installer.

Thanks for posting the feedback. I might actually try it soon.

booted my Slackware64 14.1 DVD in UEFI mode?
 

I was not able to UEFI boot the DVD, until I disconnected my old MBR HDD.(got freeze on grub start) Huge kernel (both 14.1 and current) also went to panic if MBR hdd was connected on boot. But with a generic kernel(from current, not tried it on 14.1) and initrd I managed to UEFI boot successfully with a mix of MBR and GPT hdds. Then just fixed all my mounts and root reference to use partition uuids(to avoid device name change problems) and now slackware64 current (on 3.14.4 generic kernel, not updated to 3.14.5 yet) boots flawlessly from UEFI. BTW Windows 7 Boot Manager always fails on MBR/GPT drive mix, but disconnecting controller channel with MBR drive from UEFI shell helps(was not the case with linux). I have more than 4 MBR partitions, maybe it causes some confusion.

Is there any reason to switch to UEFI?

To use UEFI, or not to use UEFI? answers that question.

Faster booting.

Easier multiboot setups.

How is it faster? And isn't multibooting already pretty easy?

Hardware initialization is technically and objectively faster.

I said easier!

Well, I am thinking about giving it a try but I am too lazy.

The reason to switch to UEFI and also to x86-64 is the same: because they are the future and because there are benefits. You will have to switch one day, the question is not if but when.

Buzzkill. :)

If you have GPT drive (and in case of capacity > 2 Tb it is almost a must) and you want to dual-boot windows 7/8, then you have no choice. That was my case. If you have GNU/Linux only system - I see no obvious reason to upgrade. There are small technical advantages such as slightly faster boot or no need to use a boot loader(in case of linux kernel is configured with EFI stub it could be booted directly), possibility to use UEFI shell and other UEFI applications before boot to any OS.

I can easily see why would someone switch to x86-64 but not why someone would switch to UEFI. In my case, at least.

If your computer supports it then you should switch. UEFI allows support for GUID partition tables, faster booting, and plenty of features that cannot be implemented in BIOS. Now, that doesn't mean you will use the features, and if you don't then you can wait. You will have to switch one day tho, and personally I try to switch to newer technologies sooner as long as they are available because I don't know how much time I will have to do the switch in the future. I mean, if it is available on my hardware and it is newer I will switch to it now, not later. Procrastination has never helped me and probably never will.

I'm not sure if you all have been following the Syndicated Linux News forum, but there have been a couple of recent entries about UEFI booting:

Boot managers and boot devices on a PC with UEFI firmware
How to delete boot managers from a UEFI boot menu

No more MBR-overwriting, bootloader-chaining, setting up LILO/GRUB/BCD boot menus, or any of that nonsense. You just use Linux software to add or remove your boot partitions from the menu that you get when you start the computer up and press F8 during the POST.

I think that's much better.

I'm Sold
 

I'm sold. I need to run out an buy a new motherboard with UEFI!

I've never used UEFI and had been waiting for the Slackware solutions to be figured out. (which they appear to have been) You make it sound enticing and not a pain at all.

I haven't tried the stub loader yet but, for me, efi was more frustrating than the bios setup.

UEFI is a proprietary pre-boot single-tasking operating system heavily influenced by Windows design principles (including executable format and calling convention). Of course it sucks and is buggy as hell. It is basically an overcomplicated 64 bit version of MS-DOS. ;) The main purpose for its introduction was to hinder booting alternative operating systems (Secure Boot).

But you don't have the choice. PC hardware with a real BIOS implementation is not available anymore (and most recent BIOS implementations were worse than UEFI). Enabling the Compatibility Support Module (CSM) and simulating a "legacy boot" doesn't give you the IBM BIOS back, it only complicates things further. So you have to deal with UEFI, if you want or not.

well lets reinvent the wheel 26 X 1 3/8 in the 1890's or is it a 650a as of today. it is all the same to me the system is looking at a boot loader and why people want to be confusing.
It is looking for an image and wow lets put it on a fat32 partition. well. All the same all the same stuff. nothing new. not one thing.

It is an image loaded into ram and for what I see oh well.

That's true. But usually BIOS was not superior in any sense. Also proprietary(open/free alternatives exist but how many use them?), single-tasking, often buggy. The only advantage is simplicity.

Challenged by:
0. switch to uefi
slackware-on-uefi

I wondered about 'Upgrading' from MBR to UEFI on a Uefi-firmware computer

First I read some good stuff for understanding what is happening and needed.
0. slackware64-14.1/README_UEFI.TXT
uefi on hardware
2. uefi and elilo
3. uefi-boot
4. boot managers
5. delete bootmanagers
modify bootmanagers
6. efi bootloaders
7. gdisk
8. convert MBR to GPT
9. switch to uefi, but with grub

THUS this is/was the plan:

Current: MBR lilo-booted Slackware64-current (after 14.1) system on a UEFI firmware computer: a PC SPecialist UltraNote -based on a Clevo W550EU- with intel i7, 16Gb RAM, and OS on a mSATA SSD drive and rest on a 750Gb HDD. Two years ago, Slackware was installed by PXE and the drives reformatted (to MBR) to remove any traces of an unwanted test OS and to use the'legacy BIOS'-mode, which was then the most reliable.

Aim: Change to Uefi in situ (without reformatting the whole drive which would remove data and the installed system etc.)

Precaution: backup that data before start....
Experiment: try it out with a spare external drive

We need an extra partition on the boot-drive:

THUS: use only gdisk for disc-conversion to GPT. Use parted only for freeing space for the ESP by re-sizing partitions !

I practised each step below with an external drive (with a slackware istallation) before doing the whole stuff 'in situ' on my internal drives. In this practice run I had access to internet help and experienced some difficulties I could repair easily. This reminded me not to resize partitions by changing the left boundaries. A file-system check after all actions was also helpful (can be done from within parted).


For the real change:

STEP 1: Boot with a UEFI install/boot medium (0) into the laptop.

Get into the SETUP menu (or 'Bios'). For MBR discs and legacy-booting via MBR and Lilo, OS was set to 'others' and in my case 'uefi was disabled' automatically. (Note, all Windows stuff had been eradicated by formatting the drives to MBR format, although an inactive 'Windows Bootmanager' was still present).

I disabled all internal MBR drives for booting

Only by turning OS to 'Windows 8' and by enabling uefi my Slackware boot-stick worked and started in uefi-mode

Did not mount internal drives (parted and gdisk only work on UNMOUNTED partitions).


STEP 2: on the boot drive created an ESP (Efi System Partition)(0, 4, 6)
Used parted to shrink a (not completely occupied) partition on the boot drive to create space for a EPS partition (around 100-200MB seems to be enough; probably depending how many OSs one wants to boot (but see (3)).

STEP 3: converted discs to GPT-format with gdisk (7)
Ran gdisk on the drives and checked message:

Instead, you can get an error message when your drive is completely occupied:

This indicates that there is not enough space to place GPT information as described in (8):

Pressed "q" to leave gdisk without changing anything.

I got this error and had to reduce the size of my last partition (swap space) (I did this with parted) to get the above clean message.

If you cannnot add an extra primary partition on your MBR drive you have to convert the disk first to GPT, in which all partitions appear the same.

gdisk /dev/sdb

typed "p" to print the partition table (as it will be when disk is converted to GPT
typed "s" to sort the order of partition numbers (which you have to take over to /etc/fstab ) (8)
typed "w" to convert MBR disc to GPT format.

After that, there were gaps in between some partitions as expected (8)

I made then the EPS in the freed-up space as a fat32 formatted partition (with parted but this can be done with gdisk) and then made sure that it was set to the efi format with gdisk:

type "p" to print the partition table: which could show the ESP as 0700. If so:
type "t" to change the ESP to its required format: ef00
type "w" to confirm this.

my boot disk and my data disk:

##########
EDIT: I should have used fsck on the ESP to check whether the fat32 formatting had been done correctly.
(see this very informative Arch-linux page, as referred to from this slack-doc page).
##########

STEP 4 Set up Elilo (0)

Mounted the partition of the boot-disk with the slackware installation (sdb1) to /mnt
Mounted the partition with the EPS (sdb2) to /mnt/boot/efi

Checked whether all was there
Ran eliloconfig; this only worked when the whole system is recognized as uefi-capable: gpt discs; /boot/efi partition present


I got this far AND according to all info, the computer should now be uefi-only.....

But rebooting fails. I need the USB-stick to boot into the installation.

In SETUP I now see an option for secure boot (disabled)

I tried then to do a minimal install (i.e. only the a-packages) in order to get throught the Slackware setup program.

After that still no proper reboot joy.

This is in /boot/efi/EFI/Slackware:

These vmlinuz and initrd.gz look the same as used for booting via lilo in /boot:

-rw-r--r-- 1 root root 3681296 Sep 9 04:46 vmlinuz-generic-3.14.18
-rw-r--r-- 1 root root 5617105 Oct 17 21:04 initrd.gz


and the Slackware installed elilo.conf was:





STEP 5 I probably might go ahead with this: use efibootmgr for making changes:


But there seems no need for it.

When I reset the OS to 'others' in the SETUP menu legacy-bios-mode kicks in and I boot into my system as usual via lilo.

Oh, how one can be relieved seeing the Slackware boot-screen appear :-)

Still, I am a bit disappointed that uefi does not work this way. But I don't think I am up to completely reinstall my system: too much stuff to do on an evening.... and possibly to no avail. I also could not boot from my external drive with a huge.s and despite setting delay and timeout to 300.

Thus despite all theory, in my case uefi-mode does not seem to override MBR stuff (that luckily was not been removed by gdisk conversion).


Do I need to change elilo.conf (but how?)
Do I need to put the huge.s in the /boot/efi/EFI/Slackware?
Do I need to include something in the initrd apart from ext4 file system info?
Do I have bad uefi-firmware???

Cheers,

Rob


PS Yes, this might have been a stupid experiment but one has to try...

######
EDIT: The problem arose from an incorrect fat32 file system on the ESP, as described later on
######

Could you please describe in more detail how does it fail? Post (part of) boot log or the error message. How do you exactly boot EFI from your boot menu - maybe you have a screenshot? Have you tried to boot from UEFI shell on USB stick?

Hi dad_ thanks for replying.

OK: In the boot menu of SETUP 'Slackware' is present and first choice (and the only uefi choice unless I attach my eufi-boot flash-drive to a USB3-port).

In uefi-mode, without the boot-USB, the system hangs, that is: does not start at all and reverts after a couple of seconds to the SETUP screen.
In my SETUP eufi mode is only possible by setting 'OS' to 'Windows 8', which then enables me to set 'Uefi' to 'enabled'.
(this is NOT secure boot as this option comes up in another tab (security) and is only available with the above setting of OS Windows 8 + uefi enabled)

When I boot with the uefi USB-stick and then by pressing 'tab' can input my path to / and the kernel (/dev/sdb1 vmlinuz), it reverts to the boot screen of the USB-disk.

If, in SETUP, I set OS to 'others' uefi is greyed-out and automatically set to 'disabled'.

THEN I get the lilo-boot screen ....and the system boots normally

It just seems that my SETUP firmware does not want to accept that other OSs than Windows 8 can boot uefi...... or it is buggered somehow.

(But why does the boot USB-stick work; that's not Windows 8 either???)

#### EDIT: removed output of what bootlogd (after editing rc.S according to this post) spitted out in /var/log/boot and the top of dmesg as it basically showed the lilo-boot. Hope this might make the post more digestable..
#### end EDIT


Cheers,

Rob

When you boot in uefi mode with the usb key, once system loaded could you post output with:

Hi keefaz,

after modprobe efivars:

/boot/efi/EFI/Slackware/elilo.conf content looks ok ?

edit, sorry didn't read the previous post with your elilo.conf

I notice there is no default value (don't know if it is required with only one kernel entry)

Maybe you could add this line:
just after the "timeout=1" line

Hi Keefaz,

Thanks for the suggestion; I just tried that but to no avail; the system returned back to the SETUP screen again

At this point, it is not clear if elilo loads or not...

Could you change elilo.conf like:
This way, if elilo loads you should see elilo prompt at boot

So you are not able to see any error message and don't have any failure trace?

Again no any error message is shown? What if try lilo(or grub? - what is installed on a USB stick) command line? Do I correctly understand that you're not able to boot your system installed on GPT drive in EFI mode, but still able to boot it in MBR mode(so lilo is still installed in MBR)? Only the distribution installed on a stick boots from EFI?


What about UEFI shell - have you tried it? (UEFI shell is a special application for EFI - it lets you run some commands before starting any OS or bootloader. For example you could manually start a .EFI executable, such as elilo.efi or bootmfgw.efi, from it).

That is correct no error message nor trace.


Yes. That's correct. When I try to uefi-boot from the internal GPT drive nothing happens, just that I get back to the SETUP menu. But for lilo to boot I first have - in SETUP - to change 'OS' from 'Windows 8' to 'Others' and then - automatically - 'Eufi' is set to 'disabled'. This would explain why lilo boots after that.


In SETUP there is such an option but It did not work. I can access the boot menu with efibootmgr after booting from the USB-key (after modbrobe efivars; see previous posts), when I am in slackware; or is that not the shell you mean?

rob

No, UEFI shell is not a unix shell. It is a separate .EFI executable which could be downloaded & started from USB stick for example, or from your EFI fat32 partition. See here:

https://wiki.archlinux.org/index.php...ace#UEFI_Shell

Embedded UEFI shell is also sometimes available - in your case it seems it doesn't work, but you could try some external UEFI shell application (try to download one of the mentioned in the above article - some may work, some not).

Did you try the elilo.conf changes I suggested? (adding delays + prompt command)

Thanks for the advice. It could take me some time to get this going. I just saw in SETUP the option "Launch EFI Shell from filesystem device". Would I need to copy a binary to a particular folder in the EFI folder on the ESP? And how would I then proceed?? This is new for me.

Cheers,

Rob

Hi Keefaz, thanks. I just tested your suggestions but after two seconds of blackness the SETUP menu reappeared as before.

Copy the shell to '/boot/efi/shellx64.efi'. See:
http://docs.slackware.com/howtos:sla...void_surprises

Thanks keefaz, dad_ and metachima for all the pointers. I think I found the solution, albeit fairly indirect. My EPS partition was wrongly fat32 formatted!

An informative link metaschima. The reference in there was even more helpful! Especially the section about ESP on GPT-formatted discs, with: .

I had seen (but initially ignored) this error (my ESP is on /dev/sdb2):

This error could be corrected according to the arch-page with
as confirmed by a repeat of fsck (and the partition type was still EF00 according to gdisk). This wiped my original EFI/Slackware folders I reinstated with mkdir.

I then booted again into uefi-mode with my USB-key, mounted my / and /boot/efi partitions under /mnt and /mnt/boot/efi; did 'modprobe efivars' (both in the tty1 shell I was in as well as after 'chroot /mnt' in another terminal, tty2) and then could repeat 'eliloconfig' (in tty1). (Without the 'chroot /mnt' step 'eliloconfig' or 'efibootmgr' would be 'not found' because the USB-key did not have any slackware packages)

After that I booted straight into Slackware 3.14.18 without needing to change anything in the elilo.conf. I did not even get the chance to test the uefi Shell I had copied earlier according to your (metaschima and dad_) instructions; no need ;-).

This post is from an uefi-booted slackware-current installation:

and after some clean-up:

Cheers,

rob

I was not aware of such EFI peculiarities because my EFI partition was created by windows 7 installer :) (I went EFI only to be able to dual-boot win7/linux off my GPT disk and for win7 EFI required in this case).

Congrats!:cool:

BTW: I have EFI related question to all - in case of elilo package is upgraded(and this has happened already in Slackware64 current at least once) - we have to manually overwrite elilo files in /boot/efi? There's no special script like eliloconfig? Or we could safely use it in case of upgrade also?

There's no reason to change anything in /boot/efi after an update of the elilo package. Similarly you wouldn't need to change anything in /boot after an update of the lilo package.

Thanks.

As far as I understood what is happening is that eliloconfig 0. controls whether you're on an uefi-system (GPT discs, ESP present etc), then 1. copies the required files to the EPS, and 2. makes a boot entry (See the script by, as root, 'less /usr/sbin/eliloconfig' or F3 in mc).

For 1. the required files are in the /boot folder: vmlinuz is the kernel installed and renamed to vmlinuz; with or without initrd.gz and the elilo.efi file is the one that fits your architecture (in my case elilo-x86_64.efi). (You can see this eg by comparing the contents of /boot and /boot/efi/EFI/Slackware alongside in mc)

Yes, but all happens in /boot/efi/EFI/Slackware. Thus:

I wonder whether, after an upgrade (via upgradepkg or installpkg) of a kernel or elilo the required files get automatically copied to the EPS or whether you have to rerun eliloconfig. But it seems that eliloconfig might replace your current setup which is maybe not what you want, say when adding another kernel for testing.

And here a related question comes in: could you do this manually then, by copying the new kernel (and initrd.gz) and editing elilo.conf; (in this respect it looks quite similar to lilo.conf). But would one still need to add the new kernel to the boot menu with 'efibootmgr' or would 'elilo.efi' produce a menu one can choose from (after increasing time-out etc)? OR do you have to make a new folder (say Slackware-new) with the same contents as before but with vmlinuz (and initrd.gz) replaced by the new ones and add it to the boot menu with efibootmgr which then needs to be assessed during the booting phase with F7 (on my system)?

Rob

elilo.efi is the boot entry in efibootmgr, so no need to update it after elilo.conf edits

If you have more than one entry in elilo.conf, just add "prompt" line, then at boot you can see elilo prompt and press enter to boot default or press tab to see other options (labels)

Elilo is quite different from lilo. To update lilo code installed in MBR (or linux partition) you just run command when you update your kernel config or lilo itself. With elilo the actual executable code is in elilo.efi file on your EFI FAT32 partition and AFAIK there's no command equivalent to lilo to update it(we have just /sbin/eliloconfig and /sbin/eliloalt). The new code installed by the upgraded elilo package is unpacked to /boot and is not runnable by EFI until you copy it to your EFI partition(eliloconfig does this among other things). I would prefer to not use elilo at all, and just boot the EFI stub which is present even in generic kernel, but there are some problems with initrd and kernel config - so this cannot be done without rebuilding the kernel manually?

You could also install rEFInd, which provides EFI filesystem drivers for ext2, so it can execute ELILO from your /boot or root partition. (UEFI = Unified Extensible Firmware Interface) With its help ELILO can then read its configuration file, kernel and initrd from a linux partition, too. So this setup allows you to keep everything outside the ESP without having to switch to uber-complicated GRUB2.

Very interesting thread with lots of useful information and excellent references!

I am slowly approaching this UEFI mountain, too, and haven't read all the useful references provided here. But as far as I did, I haven't seen advice, how to go about disk encryption including /root the partition. My (preliminary) conclusion is, that still everything is valid as described in README_CRYPT.TXT.
EDIT: Except partitioning using with gdisk rather than fdisk etc., and apart from using copying a few files to the EFI partition instead of installing lilo to the MBR, of course.

So I should avoid to encrypt /boot, right? And although it's not mentioned, I'd also avoid to encrypt the EFI System partition.

Is there anything else to be taken into account, not mentioned in the official documentation?

Thanks in advance

gargamel

Another question I have: Is my understanding correct, that the order of installing systems for multiboot becomes less relevant with UEFI?

In the past it was always recommended to install MS Windows first, then Linux, because the Windows installer would wipe the boot record. With UEFI it should easily be possible to install Linux first, then Windows. Is this correct?

gargamel

Maybe check this out, EFI_Gentoo_End_to_End_Install, for some pointers about efi and encryption..

rob

BTW. I have windows in a virtual machine, saves to decide which OS to start ;-) And I ran in sleep/resume problems after I had activated some Windows-specific settings in the setup for my processor (Intel Smart Techn. and Rapid Start). These problems (direct resume from suspend) were described here XPS 13 wakes up from suspend spontaneously, and http://xps13-9333.appspot.com/#intel_rapid. There are modules in the kernel to take care for these settings but turning them off in the set-up seemed easier. But these could be relevant in the case you multiboot with windows (though not specific for uefi).