12.3-64 UEFI install warnings! Please Help!

English Install/Boot/Login
1

Hello List Moderators! I really thought I had the UEFI boot figured out, but there’s still more I need to know.

The problem is the /boot formatting for the UEFI install. The drop-down box choices for the mount point is only /boot/efi.

With the prior-to-UEFI format of /boot of ext2 I get this warning:


With  your current setup, your openSUSE installation will encounter problems when booting because you have no FAT partition mounted on /boot/efi.

This will cause severe problems with the normal boot setup.

If you do not know exactly what you are doing, us a normal FAT partition for your files below /boot/efi.

Really use this setup?

This time I really have a 12.3-64 bit install DVD and my UEFI bios recognizes the DVD as UEFI bootable.

My hard drive has this (12.3-32) operating system installed into /boot on sda2, / on sda8, /home on sda9.

For the 64-bit install, I have /boot on sda1, / on sda10, and /home on sda11.

So not knowing exactly what I’m doing here, I changed the install partition editor to format /boot as FAT. The label on this partition is boot64. Accepting this gives this:


With  your current setup, your installation will encounter  problems when booting because the disk on which your /boot partition is located does not contain a GPT disk label.

It will probably not be able to boot such a setup.

If you need to use this disk for installation you should destroy the disk label in the expert partitioner.

Really use this setup?

I tried manually changing the /boot mount point for /boot/efi to /boot for each format. Neither appeases the installer.

This time I really have a 12.3-64 bit install DVD and my UEFI bios recognizes the DVD as UEFI bootable.

My hard drive has this (12.3-32) operating system installed into /boot on sda2, / on sda8, /home on sda9.

For the 64-bit install, I have /boot on sda1, / on sda10, and /home on sda11.

What’s the next step for me here short of giving up on UEFI? Heboland.

2

On Wed 01 May 2013 09:36:02 PM CDT, heboland wrote:

Hello List Moderators! I really thought I had the UEFI boot figured out,
but there’s still more I need to know.

The problem is the /boot formatting for the UEFI install. The drop-down
box choices for the mount point is only /boot/efi.

With the prior-to-UEFI format of /boot of ext2 I get this warning:

With your current setup, your openSUSE installation will encounter
problems when booting because you have no FAT partition mounted on
/boot/efi.

This will cause severe problems with the normal boot setup.

If you do not know exactly what you are doing, us a normal FAT
partition for your files below /boot/efi.

Really use this setup?

This time I really have a 12.3-64 bit install DVD and my UEFI bios
recognizes the DVD as UEFI bootable.

My hard drive has this (12.3-32) operating system installed into /boot
on sda2, / on sda8, /home on sda9.

For the 64-bit install, I have /boot on sda1, / on sda10, and /home on
sda11.

So not knowing exactly what I’m doing here, I changed the install
partition editor to format /boot as FAT. The label on this partition is
boot64. Accepting this gives this:

With your current setup, your installation will encounter problems
when booting because the disk on which your /boot partition is located
does not contain a GPT disk label.

It will probably not be able to boot such a setup.

If you need to use this disk for installation you should destroy the
disk label in the expert partitioner.

Really use this setup?

I tried manually changing the /boot mount point for /boot/efi to /boot
for each format. Neither appeases the installer.

This time I really have a 12.3-64 bit install DVD and my UEFI bios
recognizes the DVD as UEFI bootable.

My hard drive has this (12.3-32) operating system installed into /boot
on sda2, / on sda8, /home on sda9.

For the 64-bit install, I have /boot on sda1, / on sda10, and /home on
sda11.

What’s the next step for me here short of giving up on UEFI? Heboland.

Hi
/boot/efi is it’s own partition (~128MB normally, multiboot may need
to be bigger), it needs to have the type set as either ef or on
gpt ef00 and format as fat. /boot is a different folder/partition.

So you would have;
sda1 /boot/efi
sda10 /
sda11 /home

–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 12.3 (x86_64) Kernel 3.7.10-1.1-desktop
up 7 days 0:56, 3 users, load average: 0.09, 0.05, 0.05
CPU Intel® i5 CPU M520@2.40GHz | GPU Intel® Arrandale

3

Thank you malcolmlewis,

it needs to have the type set as either ef or on
gpt ef00 and format as fat. /boot is a different folder/partition.

So can I set a type with the install partitioner for sda1 to be ef or is ef a format type like ext2?

On the other option you mentioned I would select sda1 to be formatted as FAT. Where does the GPT and ef00 come from?

I didn’t see anything I remember like that when I looked at the options in the install partitioner. I got the impression from the FAT warning that GPT was a partition label. AFAIK the install partitioner doesn’t allow setting labels.

If I don’t have to, I would rather keep away from a FAT partition, but any port in a storm! For either option, the sda1 mount point is set to /boot/efi. For grins, can I mount that /boot/efi from my 12.3-32 OS dual boot?

Also, is there applicable UEFI install documentation available? Heboland.

4

On Wed 01 May 2013 11:56:03 PM CDT, heboland wrote:

Thank you malcolmlewis,

> it needs to have the type set as either ef or on
> gpt ef00 and format as fat. /boot is a different folder/partition.

So can I set a type with the install partitioner for sda1 to be ef or
is ef a format type like ext2?

On the other option you mentioned I would select sda1 to be formatted
as FAT. Where does the GPT and ef00 come from?

I didn’t see anything I remember like that when I looked at the options
in the install partitioner. I got the impression from the FAT warning
that GPT was a partition label. AFAIK the install partitioner doesn’t
allow setting labels.

If I don’t have to, I would rather keep away from a FAT partition, but
any port in a storm! For either option, the sda1 mount point is set to
/boot/efi. For grins, can I mount that /boot/efi from my 12.3-32 OS dual
boot?

Also, is there applicable UEFI install documentation available?
Heboland.

Hi
Partition type is ef (hidden) is not to be confused with partition
format which is FAT, no other option for UEFI, here is this
system;


lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0  55.9G  0 disk
├─sda1   8:1    0   128M  0 part /boot/efi
└─sda2   8:2    0  55.8G  0 part /
sdb      8:16   0 232.9G  0 disk
├─sdb1   8:17   0 200.9G  0 part /data
├─sdb2   8:18   0     8G  0 part /tmp
├─sdb3   8:19   0     4G  0 part /var/tmp
├─sdb4   8:20   0     4G  0 part /var/log
└─sdb5   8:21   0    16G  0 part [SWAP]

My gdisk output since I’m running gpt (which i would recommend);


gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.5

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 117231408 sectors, 55.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 22EA0C07-0BC3-41B0-8455-A7F35BFEA03D
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 117231374
Partitions will be aligned on 2048-sector boundaries
Total free space is 3821 sectors (1.9 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
1            2048          264191   128.0 MiB   EF00  EFI System
2          264192       117229567   55.8 GiB    0700  primary

Have you read this?;
http://en.opensuse.org/openSUSE:UEFI

There are also some forum articles on UEFI.

–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 12.3 (x86_64) Kernel 3.7.10-1.1-desktop
up 1:36, 3 users, load average: 0.18, 0.08, 0.06
CPU Intel® i5 CPU M520@2.40GHz | GPU Intel® Arrandale

5

Thanks malcolmlewis!

After reading thru the link you provided, I’m thinking gvt is a new disk partition system to use when starting with a virgin hdd, which isn’t my case.

In the short time I’ve had my tower I’ve attempted several dual boots, 12.2-64/12.3-32 and 12.3-32/13.3-32 attempting to use a common /boot. Each one overwrote grub2 and became inaccessible.

Now I have a second boot partition, but I’m concerned that efi will cause the same result if I can somehow get past the installer partition editor starting with sda1 preformatted to FAT.

Viewed from the 12.3-32, his is where I’m at:

root[501] lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda       8:0    0 931.5G  0 disk 
├─sda1    8:1    0     2G  0 part /boot64
├─sda2    8:2    0     2G  0 part /boot
├─sda3    8:3    0  19.5G  0 part /ntfs
├─sda4    8:4    0     1K  0 part 
├─sda5    8:5    0  14.7G  0 part /usr1
├─sda6    8:6    0  29.3G  0 part /share
├─sda7    8:7    0  39.1G  0 part [SWAP]
├─sda8    8:8    0 429.7G  0 part /
├─sda9    8:9    0  24.4G  0 part /home
├─sda10   8:10   0 341.8G  0 part /12-2
└─sda11   8:11   0  29.2G  0 part /home12-2
sr0      11:0    1  1024M  0 rom  
root[502]

The /sda1 mounted as /boot64 is where I want to put /boot/efi on FAT. sda 10 and 11 is where I want to put / and /home for 12.3-64 respectively.

Will I end up with a dual boot out of this or do I have to sacrafice my 12.3-32 to install 12.3-64 UEFI? Heboland.

6

There is no good out-of-the box support for installing multiple instances of openSUSE sharing the same ESP. grub2 goes into /boot/efi/EFI/opensuse directory, which means two openSUSE instances will overwrite each other every time bootloader is updated. The options are

  • use multiple ESP, one for each installed openSUSE
  • use grub2 in one and elilo in another (elilo goes into /boot/efi/EFI/SuSE). Obvisouly good for two installations only
  • manually change Distributor field in bootloader configuration to something like openSUSE_1, openSUSE_2, … It is the very first word that counts. Then grub2 will be installed under /boot/efi/EFI/opensuse_1, /boot/efi/EFI/opensuse_2, … etc.

I would rather keep away from a FAT partition

You do not have any choice. ESP is the place where bootloader is located and ESP must be FAT. You do not really use it from within installed operating system (you do not even need it to be permanently mounted, only when installing/updating bootloader).

7

Thank you arvidjaar!

For those of us on the UEFI learning curve, Google says ESP translates to “EFI System Partition”. So I think you’re saying I need a boot partition for each openSuse OS. I have that this time, but now I’m fighting with the 12.3-64 DVD installer.

malcolmlewis, I think I made some progress, but still no cigar! The problem is still the stern install partitioner warning about the missing GPT label.

Here’s what I did. First I resized sda1 to 128MB and left the rest of the former 2GB partition as unformatted space.

Next I gritted my teeth and ran gdisk on /dev/sda without the -l. Then I used gdisk to set the type sda1 to ef00.

This is where I’m at now:

root[501] lsblk            
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda       8:0    0 931.5G  0 disk 
├─sda1    8:1    0   128M  0 part 
├─sda2    8:2    0     2G  0 part /boot
├─sda3    8:3    0  19.5G  0 part /ntfs
├─sda4    8:4    0     1K  0 part 
├─sda5    8:5    0  14.7G  0 part /usr1
├─sda6    8:6    0  29.3G  0 part /share
├─sda7    8:7    0  39.1G  0 part [SWAP]
├─sda8    8:8    0 429.7G  0 part /
├─sda9    8:9    0  24.4G  0 part /home
├─sda10   8:10   0 341.8G  0 part /12-2
└─sda11   8:11   0  29.2G  0 part /home12-2
sr0      11:0    1  1024M  0 rom  
root[502]

root[502] gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.5

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format.
***************************************************************

Disk /dev/sda: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): FA7FD71B-FA8B-40DC-9EDC-92BB228287B1
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3851629 sectors (1.8 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          264191   128.0 MiB   8300  Linux filesystem
   2         4098048         8194047   2.0 GiB     8300  Linux filesystem
   3         8194048        49154047   19.5 GiB    0700  Microsoft basic data
   5        49156096        79876095   14.6 GiB    8300  Linux filesystem
   6        79878144       141318143   29.3 GiB    0700  Microsoft basic data
   7       141320192       223240191   39.1 GiB    8200  Linux swap
   8       223242240      1124362239   429.7 GiB   8300  Linux filesystem
   9      1124364288      1175564287   24.4 GiB    8300  Linux filesystem
  10      1175566336      1892366335   341.8 GiB   8300  Linux filesystem
  11      1892368384      1953523711   29.2 GiB    8300  Linux filesystem
root[503]

What am I missing? Is there another action to have gdisk do? My 12.3-32 still boots. I’ve done my 6th 12.3-64 install abort! It would be nice to have the 7th attempt be charmed! The sda1 128MB partition is FAT.

8

Replying back to the list and moderators, I’m back again!

I think I see the problem. I didn’t write the new partition table. This is the message that goes with that:

Hex code or GUID (L to show codes, Enter = 8300): ef00
Changed type of partition to ‘EFI System’

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N):

It looks like this is telling me I would be starting over again! My 12.3-32 would be unsalvagable.

So am I corect in my conclusion that adding a UEFI install trashes anything previously on the drive? Heboland.

9

You should not use gdisk to manage MBR disks, use fdisk for it. ESP can be located on MBR too (although I guess whether it is really supported depends on your firmware).

10

On Thu 02 May 2013 04:36:02 AM CDT, arvidjaar wrote:

There is no good out-of-the box support for installing multiple
instances of openSUSE sharing the same ESP. grub2 goes into
/boot/efi/EFI/opensuse directory, which means two openSUSE instances
will overwrite each other every time bootloader is updated. The options
are

  • use multiple ESP, one for each installed openSUSE
  • use grub2 in one and elilo in another (elilo goes into
    /boot/efi/EFI/SuSE). Obvisouly good for two installations only
  • manually change Distributor field in bootloader configuration to
    something like openSUSE_1, openSUSE_2, … It is the very first word
    that counts. Then grub2 will be installed under
    /boot/efi/EFI/opensuse_1, /boot/efi/EFI/opensuse_2, … etc.

> I would rather keep away from a FAT partition
You do not have any choice. ESP is the place where bootloader is
located and ESP must be FAT. You do not really use it from within
installed operating system (you do not even need it to be permanently
mounted, only when installing/updating bootloader).

Hi
True, maybe the os-prober needs some tweaking…

I use gummiboot for UEFI booting openSUSE 12.2, 12.3 and Win7 gummiboot
loads initrd etc via copies in it’s own directory.

–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 12.3 (x86_64) Kernel 3.7.10-1.1-desktop
up 14:21, 3 users, load average: 0.00, 0.03, 0.08
CPU Intel® i5 CPU M520@2.40GHz | GPU Intel® Arrandale

11

Thanks for the responses guys!

arvidjaar, I took a look at fdisk. An initial passage from its man page seems to be a disclaimer:

DESCRIPTION
fdisk (in the first form of invocation) is a menu-driven program for
creation and manipulation of partition tables. It understands DOS-type
partition tables and BSD- or SUN-type disklabels.

   fdisk  does  not  understand GUID partition tables (GPTs) and it is not
   designed for large partitions.  In these cases, use the  more  advanced
   GNU parted(8).

I’m a user of gparted, using 0.14.1-6-i486 currently. If gparted can make the installer happy, tell me how! I know it can mark a partition hidden if that’s what ef00 means.

So ESP on MBR suggests to me that maybe the UEFI installer would be happier not using my 128MB FAT partition on sda1 for the grub2 efi location. That choice might make the 12.3-32 inaccessable even tho none of it would get overwritten.

malcolmlewis, I didn’t find any gummiboot in my configured repos, so that must be a third party app.

So far gdisk seems to be the only app that understands what my 12.3-64 installer wants. It I do pull the trigger with it and convert my mbr to gpt will gparted work on the rubble that’s left?

If it becomes necessary to return my hdd to it’s virgin state, the only low-level format tool I have is on a floppy. On my tower I don’t have a floppy drive. I wasn’t expecting UEFI to be so irreversible! Am I overreacting? Heboland.

12

What has it to do with os-prober?

13

Exactly. You do not have GPT, you have MBR.

That choice might make the 12.3-32 inaccessable

I’m afraid I lost track what you are attempting to do. Would you mind starting from the beginning and explaining a) what you currently have and b) what you are trying to do?

14

On Thu 02 May 2013 08:06:01 PM CDT, arvidjaar wrote:

malcolmlewis;2553182 Wrote:
> Hi
> True, maybe the os-prober needs some tweaking…

What has it to do with os-prober?

Hi
To detect other openSUSE installs and create additional entries in the
EFI directory when installing.

–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 12.3 (x86_64) Kernel 3.7.10-1.1-desktop
up 6:51, 3 users, load average: 0.09, 0.08, 0.06
CPU Intel® i5 CPU M520@2.40GHz | GPU Intel® Arrandale

15

os-prober already detects and adds another openSUSE installations to grub2 boot menu.

16

Hi
We are digressing a lot :wink: But I meant at the EFI level (as in one ESP) so one can have multiple openSUSE installs without manual intervention. In my case I decided to use gummiboot as it works better for me so I don’t use the openSUSE efi files…

17

This is a) not the task of os-prober b) is totally unrelated to which bootloader you are using.

Installer needs to select directory and filename(s) for files on ESP. Any files, be it bootloader binary, kernel/initrd binary, configuration files, whatever. How should installer chose these names? I.e. currently bootloader goes into \EFI\openSUSE. To allow second installation installer must obviously chose another name - how? Which name? System must keep track of this name somewhere for the future. It should be unique. It ideally should be meaningful to user. So the problem is to come up with scheme that generates unique names that are somehow meaningful and to persistently store them for future reference.

And what about reverse mapping? You boot from Live CD - how you can find out which of dozen installed systems now “owns” \EFI\52d0bced-7d88-4dd1-a733-df2fa0163a01 (as using UUID of course solves uniqueness problem)?

Gummiboot by itself does not address any of these problems.

18

Thanks for all the responses guys.

malcolmlewis, I expect the os prober you mentioned is what gets invoked when the grube menu “probe foreign os” is checked. My only complaint with it, is that it finds oses that it can’t boot. I expect if I have to convert from MBR to GPT, the prober will work equally well.

arvidjaar, let’s start with this:

Exactly. You do not have GPT, you have MBR.

I agree with you. The question I’m wondering now is if I can do a UEFI install of 12.3-64 on a MBR drive. If I can, what do I have to do with fdisk to make the UEFI installer stop complaining about the hdd partitions.

Regarding what I want to accomplish here, I’ll try to be brief. Since I made the investment in a HiTech hardware tower, I want to take advantage of it. Really all I want is a 64-bit OS UEFI boot and be able to run Oracle vb. Along the trail of dried blood since I spent my money, I could not get vb to run on 12.2-64.

The 12.3 I bought turned out to be 32-bit and it ran vb beautifully. I tried to make a pair of 12.3 dual boots with different desktops. The second 12.3 install attempt was a UEFI install. That’s when I found out my 12.3 was only 32 bit.

Now I bought a real 12.3-64 that I want to install using UEFI. That desire is going to be paramount even if I have to wipe out the 32-bit 12.3 with the vb. I think my hw has a problem that will crash the 64-bit 12.3 if I try to run vb. That’s why I want to keep the 32-bit.

If your’re still with me here can I do the 12.3-64 install with MBR? If I have to switch to GPT to get the UEFI install to work, I’ll see if vb will work. If not, I’ll reinstall the 32-bit on the GPT to run vb.

If I can use MBR, I need some guidance regarding fdisk to change my hdd to be accepted by the 12.3-32 DVD installer. Heboland.

19

If you can reproduce it, please start another thread and give details about this problem.

The question I’m wondering now is if I can do a UEFI install of 12.3-64 on a MBR drive.

Yes, you can. Now, whether your firmware will be happy with it is something I cannot answer and of course openSUSE installer may not be fully prepared to it.

If I can, what do I have to do with fdisk to make the UEFI installer stop complaining about the hdd partitions.

You need to create EFI System Partition, this remains true whether you use MBR or GPT. EFI System Partition has MBR partition type “ef”. When you use fdisk to create partitions, you can list all supported types with “L” at the right moment. You can boot from Live CD and create partition and filesystem in advance, then instruct installer to mount it as /boot/efi.

Also, I do not think installer actually checks that partition is the right type. It simply wants FAT filesystem on /boot/efi.

If your firmware allows starting EFI shell on boot, you can verify that ESP you created is recognized by firmware at boot time.

20

Thank you arvidjaar!

You told me what I needed to know to proceed!

Your reference to “my firmware” I take to mean my mobo UEFI bios. Before I go farther, I’ll check for the latest revision.

By the live CD reference I take that to mean live gparted CDs an the like.

My comment about the os prober is probably unfair. What happened was the result of me overwriting my /boot partition with a second install. The os prober finds both installs, but none of the grub2 boot menu choices allows the first install to be reached.

I did have good reasons to believe the second install wouldn’t overwrite the /boot entries of the first, but my reasons didn’t work out.

The sun is out, so it may be a while before I complete this UEFI attempt. I’ll post back to this thread when I have something more of interest to share. Heboland.