All change for UEFI/GUID? Pre-partitioning and multi-boot on a new build

Hello openSUSE,
Thank you for an interesting and useful website/forum. I am a new user looking for some final input/guidance before installing. After many years thinking about it, I am finally migrating from Windows to (SUSE) Linux as part of my new home PC build. Yet, as I’d still like a transitional period with Windows for legacy/proprietary issues, a multi-boot system seems the way to go. I had always thought that I would need to pre-partition my HDD in preparation for a multi-boot system to overcome Windows’ demand for primary partitions etc… but then along comes UEFI/GUID to sweep away MSDOS/MBR and the partition/size limitations and also offer other benefits - especially for multi-boot systems…

So, my newly built office/media PC has 64 bit Intel architecture, UEFI v2.6 BIOS and a single 2TB hybrid HDD - onto which I am now ready to install the OSes from a UEFI mode DVD: W7x64 for legacy, then SUSE 13.1 x64 for main use (in three ext4 partitions) , and, if all goes well, maybe Ubuntu 14 x64 for a separate, secure on-line transaction system, plus a large data storage/library partition accessible from all OSes (so NTFS - I guess) at the end. After studying your site, I created a SUSE 13.1 x64 live ISO DVD to familiarise myself with the OS and get a copy of GParted.

I have read many of your helpful guides and tutorials yet I’m still uncertain on a couple of areas:

Q1: Installing/Partitioning. My objective is an optimised, future proof, partition layout that supports the inherent qualities and intended purposes of each OS. Should I pre-partition/prepare my new HDD with GParted first in any way (for example, set the PT to gpt, then create a 100GB space for SUSE after leaving 100GB unallocated space for W7 in front) or just trust the W7 and SUSE installers to do the job – using the advance/custom install options as required?

I know I should install Windows first: I expect, in UEFI mode, it will set the PT to gpt and create its ESP (FAT32), MSR and OS partitions. Yet, can W7’s strict, proprietary installation compromise my later Linux installations and multi-boot intentions in any way? For example, under UEFI, other OSes will be using the W7-created ESP, and I will no doubt have to shrink the W7OS partition to make room for them. As I am in the fortunate position of being able to plan and control things somewhat with a completely fresh start/install, do I need to check or modify the W7 installation manually to optimise/prepare for the SUSE installation? Or has the old advice of pre-partitioning for multi-boot systems now become unnecessary with UEFI/GUID?

Q2. Booting and boot managers/loaders. My goal would be to create a robust and reliable boot process for my multi-boot system that, on booting, presents a boot menu of all OSes then defaults to auto boot SUSE Linux.

I know that UEFI has its own boot manager and that this works with the specific OS boot managers/loaders that will be loaded into their respective directory in ESP. I know that GRUB2.efi can manage this process and can chain-load Windows when required. I also know there are other options to GRUB2. I have read some dual boot tutorials that simply suggest that the install process of SUSE will reliably deliver my objective… and then read other articles that contain lines of coding and scripts for modifying the ESP entries and/or boot managers in order to achieve such a goal… and others somewhere in between. I realise SUSE is being developed all the time, so what is now the best/recommended way to create and configure a stable boot process that reliably performs my multi-boot objective?

Many thanks in advance for any responses.
SimonG

As far as I know, if you install Windows 7 yourself you should have some control over the partitioning. In particular, you should be able to set the size of the main Windows partition, so as to leave space for linux.

You can use the same EFI partition for opensuse. Just make sure it is big enough. I’m using 500M for my EFI partitions at present, and most of that is empty space.

I don’t know whether you will run into problems with UEFI. Some people. Most of those who build their own computer are doing okay. Most of the problems with UEFI have workarounds.

My advice would be to start with installing Windows in EFI mode, leaving enough unused disk space for later install of linux.

When later installing opensuse, the installer will probably make reasonable recommendations, though you might want to modify those. The EFI partition needs to be mounted at “/boot/efi”.

It will probably go well, but ask in this forum if you run into problems.

Hello
Thank you for your helpful reply. I have had some delays but now I am back to my project.
Following your advice, I installed W7x64 onto my new/clean HDD in UEFI mode; I was able to allocate a 100GB of space for it during install. Later, GParted (from my live DVD) confirmed a gpt table and the ESP and MSR system partitions; W7 Bootmanager is also registered in the UEFI boot menu. It all looks and works fine - my only problem was that I could not find a way to specify/force an extension of the ESP size from the standard W7 100MB, as per your advice.

Effectively, I am now ready to install SUSE Linux in dual boot. I did an aborted dry run installation with my live 13.1 SUSE DVD: choosing custom/edit install, all the W7 partitions were listed correctly and I could easily edit the three proposed SUSE partitions to extend swap and to resize home to 100GB etc., and the existing (W7) ESP was automatically mounted to /boot/efi/ - as per your advice.

Before I proceed, I have a couple of issues/questions.

  1. The ESP size=100MB: I could not extend it during the W7 install and as it is now the first partition of three on my HDD, it seems I cannot easily/reliably extend it now. The only way I can see to change it to c. 500MB is to wipe the whole W7 installation, pre-partition the HD with a 500MB FAT32 and 100GB OS partition and re-install W7 in the expectation that it will obligingly slot into these new quarters (the merging/re-allocation of the MSR is not a problem). I am willing to do this (this is a fresh install with no data to be lost and the machine is not yet in service etc.) if I would be saving myself problems/limitations in the future. Essentially, how strong is your advice re a 500MB ESP? Once the boot process of a machine is set up (and remains unchanged), does its use of the ESP change over time? Do things accumulate there? Can I limit these things? Why is it good to have lots of spare space there? The W7 Bootmanager currently uses 22MB of the 100MB.

  2. Although it clearly identified all the existing W7 partitions, I was slightly surprised that YaST did not explicitly confirm - especially in the booting options review page - that it had detected another OS - W7 - and that its intentions were to install SUSE alongside W7, make GRUB2 the default boot manager and offer a dual boot menu for W7 on start up. Perhaps this is all too obvious for an experienced user but it would be an extra reassurance for a new user to make this explicit – given the criticality of OS installs. I am comparing with Ubuntu which I think does this - perhaps I shouldn’t do!

  3. Drivers. Getting ahead of myself - but as SUSE will be a new OS, before I can do much else, I will need to load hardware drivers: e.g. chipset, video, LAN, audio etc… I loaded these for W7 from my new mobo driver CD; presumably, this is no good for Linux? They are very standard/latest drivers…e.g. Intel, Realtek etc… does SUSE Auto Configuration install (these) drivers?

Thanks in advance,
SimonG

Hi
On my dual boot test system with Windows preview, it created a 300MB (sda1) recovery partition, then 260MB efi, and a 128MB MSR (which should be there on UEFI 7?), so your intention to future proof may be flawed?

I always use the custom partitioning and dump windows at the end of the drive since it doesn’t get used much…

In saying the above, I’m only using 42MB of the 260MB allocated as follows;

Boot -1.6MB
Microsoft - 24MB
openSUSE - 3.5MB
HP - 13MB (BIOS update and tools)

Have a look at this thread for my systems partitioning.
https://forums.opensuse.org/showthread.php/502132-How-to-partition-disk-with-btrfs

That’s probably big enough. So just go ahead and install.

From “df” output:


/dev/sdb1                    511720     9360    502360   2% /boot/efi

That’s with Windows 8, opensuse 13.2 and opensuse-factory all installed. I’m not using close to all of the space.

I’m using “grub2-efi” to boot, and that keeps most of what’s needed in “/boot”. Some alternate boot methods (such as “elilo”) require that kernels and “initrd” files be in the ESP, and in that case 100M would be a bit tight. But, using grub2-efi you will have plenty of space.

Hello,
Thanks for the input. Sorry for the delayed response: in part, I was sidetracked by an errant md5 checking program that seemed to have problems with large files (MD5 Checker by Tsoft – that I later found listed as suspect in openSUSE support notes)…anyway, I replaced it with another program and am back on track.
To recap: this is a dual-boot, x64, new build under pure UEFI/GUID; W7x64 is now installed, with a 100MB ESP. I downloaded and verified a full 13.2 ISO DVD and did an install dry run: most things looked OK with no major issues/errors.

A couple of things I wasn’t sure about: i) although it identified the W7 partitions correctly, YaST didn’t explicitly state that it recognised them as a viable/ongoing OS and that (via grub) it intended to take control of the ‘meta’ booting and set-up a dual boot front end menu. Perhaps the fact that the ESP mount point was automatically set to /boot/efi is all the proof that was needed; ii) ‘enable Secure Boot=true’ was stated on the last confirmation page before install: I wasn’t sure if this was OS specific/limited - i.e. support for SB in SUSE or if it intended to change my UEFIBIOS ‘SB=disabled’ setting. As I don’t think W7 will work with SB enabled in UEFI and as SB seems to be the cause of so many issues especially in dual boot systems, I decided to override this and set ‘enable SB=false’ - at least until I have a stable install and can understand SB in SUSE a little better in the hope that I can switch SB back on later, if desired.

Install: So, I decided to go ahead and install. Most things were default/recommendations except adjusting partition sizes, changing file system types and customising a few packages. The whole install – creating the partitions, formatting them (c.200GB), reading (from DVD) and writing nearly 4GB of data and finally rebooting, all took less than 8 minutes in total. This seemed so fast, that at first I thought something had gone wrong or was missing… but there were no nasty messages/alerts and from an install/dual-boot perspective, everything seems to be working fine: the UEFI boot manager has been updated and re-prioritised; grub (bootmanager part) seems installed in ESP OK and (the bootloader part) in /root OK; the grub boot menu displays/works perfectly and both OSes appear to boot and load fine. The 100MB common ESP (sda1) is only 18MB=18% used in total, so size here doesn’t seem to be a problem (I used grub2.efi, as advised).

SUSE and going forward: I couldn’t tell if AutoConfig ran as, unlike 13.1, 13.2 didn’t make this explicit on set up, but I assume it did. It seemed only my network card (Intel integrated graphics) was not working (as I declined the offer to configure it at install to keep things simple) but I have since managed to get this configured and working via YaST. I haven’t quite yet worked out how to check that all the other drivers are latest/full. I am not familiar with Linux at all so there’s plenty to learn and am reading through SUSE online guides and other sources.

So, I think I can take this as a success – certainly the dual-boot/install part - and certainly far more straightforward than I was anticipating. Although its only a single and somewhat vanilla example, I would also say that this vindicates what I see as the many advantages of using UEFI/GUID - especially in multi-boot – and I remain baffled by the slow pace and generally unenthusiastic – occasionally even resistant – responses I see on websites to its wider adoption and use. As for SUSE, as I go forward, if it continues to prove itself as capable as it has during my installation and in my first tentative uses, then I will be very impressed and very satisfied with it.

Thanks once again for the input.
SimonG

Yast is not going to tell you that. It will setup to boot grub2-efi. But it is grub2-efi that has to recognize Windows and provide a boot menu item.

As far as I know, that will work. However, my dual-boot UEFI box has Windows 8, not Windows 7. Until recently, most Windows 7 systems were using traditional BIOS booting rather than UEFI booting.

You should assume that it will work. And, if it doesn’t work, ask for help in getting it working.

Perhaps the fact that the ESP mount point was automatically set to /boot/efi is all the proof that was needed; ii) ‘enable Secure Boot=true’ was stated on the last confirmation page before install: I wasn’t sure if this was OS specific/limited - i.e. support for SB in SUSE or if it intended to change my UEFIBIOS ‘SB=disabled’ setting.

The secure-boot support you see in the installer is only about making sure that opensuse can boot that way. It won’t change your firmware settings on secure boot. It will just install opensuse in such a way that it will boot with or without secure-boot.

As I don’t think W7 will work with SB enabled in UEFI and as SB seems to be the cause of so many issues especially in dual boot systems, I decided to override this and set ‘enable SB=false’ - at least until I have a stable install and can understand SB in SUSE a little better in the hope that I can switch SB back on later, if desired.

You are probably correct about WIndows 7.

I normally leave secure-boot enabled on my dual boot UEFI box. I leave it disabled on a second UEFI box. However, in all honest, I don’t see secure-boot as providing anything that I find useful (apart from the ability to test secure-boot).

The whole install – creating the partitions, formatting them (c.200GB), reading (from DVD) and writing nearly 4GB of data and finally rebooting, all took less than 8 minutes in total.

The newer disks are faster. And they really have speeded up install in other ways. There are commands that need to be run after installing certain packages. And there used to be a lot of redundant processing in how that was done. A lot of that redundancy has been eliminated.

SUSE and going forward: I couldn’t tell if AutoConfig ran as, unlike 13.1, 13.2 didn’t make this explicit on set up, but I assume it did.

Some of that used to be done after the reboot. Now it is mostly done during the initial install, so you don’t notice it. This is another good move that speeds up install.

So, I think I can take this as a success – certainly the dual-boot/install part - and certainly far more straightforward than I was anticipating.

I’m glad you have it working.