152 replies to this topic

[migle]

dmazar, on 11 September 2012 - 09:40 PM, said:

migle, just wanted to let you know that I have reused your BootDuet code in a solution for booting XPC bootloader from a USB stick that contains other hackintosh bootloaders (Chameleon, Clover, XPC). Here.

Well you give such visible credit and everything, thanks...
Just tell me if someone changes it (maybe corrects a bug, supports a different case).

SupraMac, on 27 August 2012 - 04:17 PM, said:

I agree, same issue for me, file not found ; )

About that "file not found", if the problem persists, maybe seek help for that on gitorious.

[nicholasdille]

Hi everyone,

I am also seeing a hang after "Welcome to EFI World" but in a slightly different situation.

I have built a USB stick from tianocore_uefi_duet_installer (http://www.gitorious..._duet_installer) as well as from the EDK2 sources according to http://pete.akeo.ie/...usb-stick.html.

This stick works as expected on my hardware but it fails after the welcome message in a virtual machine on VMware Workstation 9 as well as Hyper-V 3 (on Windows Server 2012).

Is this an expected behaviour? Is there anything I can do about this?

BTW, I am aware that VMware Workstation can be configured to use UEFI instead of BIOS.

Thanks in advance!
Nicholas

[m.savazzi]

Hi Everyone,
Sorry to bother but I have a problem with DUET.
Let me give you the background: I want to install and boot windows from a GPT disk on a raid controller on my PC.
Now using the info from A BIOS to UEFI Transformation http://www.rodsbooks...uefi/index.html I was able to create the partition, install SYSLINUX and DUET and boot from the USB dongle to begin installation.
The issue is that at the first reboot (when I remove the USB Stick) DUET does not boot and does not recognize the RAID card and partitions.
I’ve checked with the SYSLINUX community and the fact that DUET is loaded means that SYSLINUX is able to recognize the disks and loads DUET.
How can I have DUET recognize the disks on the raid controller? Raid is a Areca-1220  (http://www.areca.com...upport/main.htm) and there is an EFI bios for Mac Books here ftp://ftp.areca.com.tw/RaidCards/BIOS_Firmware/ARC1220/MacPro_EFI_BIOS/80429/
But I do not know how to try to load it or what to do.

Can anyone help me?

[migle]

m.savazzi, on 18 November 2012 - 07:26 PM, said:

Can anyone help me?

I can't. Anyway, I think your diagnostic is correct, that duet does not know your raid controller. Is there no chance of having it behave like an AHCI controller?

The EFILDR20 file is a bundle. It has the basic UEFI functionality and then it has many packages. There is nothing in DUET to support areca controllers. You see, DUET would be the toolkit to help areca developers run and debug their firmware.
I think understand that some packages that skodabenz has assembled come from VirtualBox, but I don't think there is anything in VirtualBox about areca controllers.
You would have to find such code and then compile it and assemble it into the EFILDR image.

I don't think you would be lucky enough to find such code. Anyway, the subversion repository for the EFI Developer's Toolkit is http://edk2.svn.sour...ranches/UDK2010, otherwise search for tianocore.

The only viable option I see is try flashing that BIOS onto your areca card (provided you can go back to the BIOS you currently have) and hope that it magically works (maybe it emulates an AHCI controller).

If it doesn't work, I think your chances are not very good.

If you could find EFI code to support areca, you would then find help for compiling it at http://gitorious.org...efi_duet_builds.

That's all I can say.

[Antonio19]

Well, I managed to install succesfuly the latest version of tianocore_uefi_duet_installer on a brand new SATA drive GPT formatted.
I followed the instructions from http://www.rodsbooks...uefi/index.html (from user srs5694).

I first installed Windows 7 then Ubuntu 12.04 both in UEFI.

However within DUET Boot Manager "Managing the Boot Process" it looks like there is no way to add permanently a new Boot Option. The same is true for modifying the Boot Order.

My EFI System Partition is mounted as /boot/efi then I have EFI folder which contains Boot, extras, Microsoft, Shell, ubuntu.

To be able to see the GRUB EFI menu at startup, I have to manually add, each time I boot my PC, a Boot Option that use the file /boot/efi/EFI/ubuntu/grubx64.efi, then to modify the Boot Order.

It looks like the default option is broadly set as the SATA GTP Disk [no specific file is given], which for me ends up to always booting Windows 7, the first OS I installed.

Is there anyway to make any of these manually added Boot Options stick for good ?

Or another way to set the default boot to GRUB EFI ?

Thanks for your feedback.

[migle]

Antonio19, on 20 December 2012 - 06:14 PM, said:

Is there anyway to make any of these manually added Boot Options stick for good ?

Well, there should be, but there isn't right now.
Those boot options and your default choice, in a real UEFI, would be recorded in NVRAM.
In Duet, there is a module to emulate an NVRAM, which is EfiVar.

Your boot options would be recorded by this EfiVar module in a file called EFIVAR.BIN in the root directory of your ESP.

It happens that people (Keshav) have verified that when they compile this module in Duet, Windows does not work so well (or something like that, don't remember exactly).
So, the preliminary solution, I think still is to eliminate this module when compiling Duet.
Which means you don't get this EFIVAR.BIN file in your ESP.

Furthermore, I wrote the boot loader, BootDuet, which is responsible for loading EFILDR and EFIVAR.BIN into memory and jumping into EFILDR, and I never had the chance to see if EFIVAR.BIN was being loaded correctly (and its address passed correctly to EFILDR).

So, how have we been getting by?

First, you don't need to boot Linux through UEFI, it boots from a GPT disk using a regular BIOS just fine.
Actually, it's better not to use UEFI, because Duet takes a lot of time to boot.

You actually only need DUET for booting Windows.
And if that is your only EFI boot option, DUET will just boot it without asking.

So, myself, I have the regular GRUB installed, which boots from a GPT disk just fine. I have several options for booting Linux and FreeBSD, and then I have a single option to boot DUET, which boots Windows.

From a practical point of view, this works just fine.

If you are looking for the satisfaction of total UEFI emulation, then you know were to start: compile an EFILDR which has the EfiVar module in it, then check if anything gets stored in EFIVAR.BIN, and then we'll see if it gets loaded properly.

But really, there are more interesting things in life...

Greetings,

[Antonio19]

Thank you for your prompt reply. Thank you for your work as well on writing the Boot Loader BootDuet.

Seeping through the messages of this thread I realised after posting and as you suggest that the (latest) version from Keshav (gitorious repo) I installed is missing the EFIVAR.BIN file. Hence the trouble for not "remembering" the configuration.

The solution you describe using as well as the one used by Keshav, is to only boot Windows in UEFI through an option Boot DUET, the other OSes being installed outside DUET ? Do you use GRUB2 Legacy or GRUB2 EFI ? Then you add manually the option "Boot DUET" ?

Usually I add GRUB2 menu entries to /etc/grub.d/40_custom. Do you chainload the EFI System partition then ? to make the option of booting DUET from GRUB.

My current problem is that the PC boots in windows at startup and no GRUB2 booting options are first displayed.

May be as you suggest it is not worth to try to get through a full EFILDR compilation with the EFIVAR module.

However, after some testing on a pure GTP [EFI] hard drive I realized that if I only install a Linux with GRUB2 EFI, then DUET is stuck at its menu screen. I have to select the file to boot through the menu to make it launch Linux in EFI mode. But as soon as I add Windows 7 x64 entry in the boot/EFI partition (I installed Windows through DUET in EFI previouly - (on first DUET install) - then I re-installed DUET & installed Linux through it - And at last I did only add the entry for Windows 7 in the EFI partition) then DUET always launch directly Windows unless you press F12 at the tianocore welcome screen to enter its selection menu.

This behaviour looks "hardcoded" somewhere. What I would like is a similar "hardcode" to boot GRUB2 EFI. This should be a lot easier than sorting the issues of EFIVAR.

Furthermore I've seen that Keshav posted on 29 April 2011 that "I am able to boot linux x86_64 using grub2 (1.99~rc2)in edk2_x64.". This is exactly the behaviour I would like on my system.

Booting time for Linux is greatly reduced in EFI mode. Usually I get less than 5 sec. in EFI vs. 17 sec. in MBR. Same for Logging out.

I didn't had a look at the different repositories. I don't know if it is easy to get the version of that time back and running. May be only Keshav could have a quick answer on this ? ...

Greetings & Happy Holidays.

[migle]

I guess you edited this last post. My main motivation for replying was that you seemed to have understood that you had to have a hybrid MBR disk for Linux to boot without using EFI, and that is not the case. To be clear:

• Linux or FreeBSD boot just fine from an GPT-only disk without having EFI firmware. Actually, this is expected, GPT is a very simple partition table layout, easy to read from a boot-loader without any help from EFI firmware, or 32 or 64-bit address space. These OSes don't even have to care, because once the kernel is loaded into memory (e.g. by GRUB), everything is already solved.
  
• Only Windows requires the boot disk to be MBR when using the old BIOS, they were probably just lazy to write a couple of pages of assembly code.
  
• You can't have Linux booting faster through DUET than without it. DUET alone takes longer to boot than Linux (or almost).

Antonio19, on 21 December 2012 - 08:46 PM, said:

Seeping through the messages of this thread I realised after posting and as you suggest that the (latest) version from Keshav (gitorious repo) I installed is missing the EFIVAR.BIN file. Hence the trouble for not "remembering" the configuration.

Not exactly. There shouldn't be any EFIVAR.BIN file. This file is only created by that module (which is actually called FsVariable, not EfiVar) after something is saved on "NVRAM".

Antonio19, on 21 December 2012 - 08:46 PM, said:

Usually I add GRUB2 menu entries to /etc/grub.d/40_custom. Do you chainload the EFI System partition then ? to make the option of booting DUET from GRUB.

Yes. I use GRUB2, which is installed in a 64kB partition with code EF02. I have options for booting Linux and FreeBSD directly without going through DUET (and this is a GPT-only disk). Then, I have one option for chainloading the ESP which boots DUET.

Antonio19, on 21 December 2012 - 08:46 PM, said:

...
This behaviour looks "hardcoded" somewhere. What I would like is a similar "hardcode" to boot GRUB2 EFI. This should be a lot easier than sorting the issues of EFIVAR.

I don't think there is any "hardcoded" behaviour. If it boots directly, it is because it only finds one boot option.

Antonio19, on 21 December 2012 - 08:46 PM, said:

Furthermore I've seen that Keshav posted on 29 April 2011 that "I am able to boot linux x86_64 using grub2 (1.99~rc2)in edk2_x64.". This is exactly the behaviour I would like on my system.

Booting time for Linux is greatly reduced in EFI mode. Usually I get less than 5 sec. in EFI vs. 17 sec. in MBR. Same for Logging out.

I didn't had a look at the different repositories. I don't know if it is easy to get the version of that time back and running. May be only Keshav could have a quick answer on this ? ...

Access to older versions is easy at gitorious. You'd have to go there to contact Keshav too, I don't think he reads this any more.
However, you are a bit mistaken as to what your best option is.

Your quote from Keshav is old. It says he is able to boot Linux, it doesn't say it does so directly, without choosing an option...
Also, it was only latter that he realised that he had to leave the FsVariable module out, so that Windows worked properly.

I think you already understand that you can do everything without going through DUET and use it only for Windows.
Try it and you'll see that that's your best option.

Why load a several hundred kB firmware emulation, which is totally useless after Linux boots? If the only use for the firmware is to boot the OS...

Greetings,

[Antonio19]

Thank you for the details. I installed GRUB2 on a 1MiB partition with flag bios_grub on while installing Linux Ubuntu 12.04 by setting the boot loader on this partition.

Now Linux is working on GTP partitioning using bios_grub.

I was trying to make DUET USB like the Chinese poster at the beginning of this thread with no luck.

sh ./install-duet -m -s [path to]/syslinux-5.00/mbr /dev/sdg2

Afterwards I would copy through "dd" to a partition on my HD and chainload in GRUB2.

Should I use a bootable BIOS FAT32 USB ? how to install DUET to get a bootable USB DUET stick ?

Or using the memdisk compiled img ? [This looks very different from the poster I mentioned].

Regards.

EDIT: It looks like I found a text file Usage_Linux which details "Setting up DUET USB flash drive in Linux" within the master.tar.gz I will give it a try. However I would like to know if you did use the method of the Chinese poster.

[migle]

Antonio19, on 23 December 2012 - 04:36 PM, said:

I was trying to make DUET USB like the Chinese poster at the beginning of this thread with no luck.

sh ./install-duet -m -s [path to]/syslinux-5.00/mbr /dev/sdg2

Afterwards I would copy through "dd" to a partition on my HD and chainload in GRUB2.

Should I use a bootable BIOS FAT32 USB ? how to install DUET to get a bootable USB DUET stick ?

Or using the memdisk compiled img ? [This looks very different from the poster I mentioned].

Well, you should forget those old posts and follow what's on gitorious and github.
I never used those install scripts, so I don't know what is wrong.

There is very little to do in preparing a bootable USB drive with DUET.
You need only:

• Partition the USB drive in GPT. Pay attention to the initial sector of your ESP partition, take note of it, let's assume it is 1234.
  
• Format that partition in FAT32, filling in the "hidden sectors" field of the BPB, with a command such as: mkfs.msdos -F 32 -h 1234 /dev/sdb1
  
• Install the boot sector program, BootDuet, with dd if=bd32.bin of=/dev/sdb1 bs=1 skip=90 seek=90 count=420 (or follow the instructions on the INSTALL file of BootDuet)
  
• Copy DUET, that is, the EFILDR20 file to the root directory of the partition you just created.
  
• Now it should work, you can additionally copy any *.EFI files you want, such as EFI Shell, etc.

If you can follow these instructions yourself, all you need is BootDuet, which is on https://github.com/migle/BootDuet.
Otherwise, you have a lot of info on gitorious and github, but I agree, there are so many options that it is confusing.
For instance, Rod Smith (the author of gdisk), wrote an install script which does what I said, which you can find here, https://github.com/t...at/duet-install.

I no longer keep bootable USB drives with DUET... I once found it appealing, having the EFI shell and all, providing me some error recovery tools...
But it is so limited, compared to a bootable USB drive with a free OS, that I'm no longer willing to waste time setting it up.


Greetings,

[Antonio19]

Well, I am back at it. Thank you for your information. However I have still some questions.

On my system based on a GPT hard drive I have now several Linux running fine with GRUB2 intalled on a 1MiB partition with flag "bios_grub". I just want to add an entry for Windows 7 in GRUB2 to be able to launch Windows as well on this GPT disk.

Obviously I need to install DUET to do that. Initially I thought like making a DUET USB and map it on the GPT HD (ref. to the Chinese poster). Reading your answer I understand that I can do it directly on the HD (?)...

I never had a look to your BootDuet-master.zip before. So I went to compile it on my system. It gave me a list of bdxx.bin lst and map files. My system is amd64 then I guess I should use the file bd32_64.bin instead of bd32.bin as input file. I imagine I need as well to copy the bootmgfw.efi (and all of the files installed in the boot/efi partition by the windows installation in EFI mode).

Should I use a build with the hard-coded BIOS drive number (for the ESP) ?

However I am afraid it will compromise my working Linuxes installation. I don't want to directly boot into Windows. I would like it to work through GRUB2 after chainloading it in a specific entry for EFI DUET.

Could this work ? I guess I will not set the "boot" flag on the EFI System Partition so I will still be able to boot on the "bios_grub" flag 1 MiB partition ?

I mainly use Linux which I found more configurable, much quicker and more safe than Microsoft Windows. However, I still have some programs like Garmin GPS which only works in Windows. Some big commercial programs like the Adobe Creative Suite, ... etc.

Regards.

[migle]

Antonio19, on 10 January 2013 - 05:27 PM, said:

My system is amd64 then I guess I should use the file bd32_64.bin instead of bd32.bin as input file. I imagine I need as well to copy the bootmgfw.efi (and all of the files installed in the boot/efi partition by the windows installation in EFI mode).

No, read the INSTALL file. The *_64.bin files are for 64-bit Logical Block Addressing, that's when the hard disk has more blocks than can be addressed with 32 bits (that's 2^32 blocks or 3TB) and still only when your ESP partition lies beyond the first 3TB.

You can, of course, boot using only the hard disk. You have GRUB 2 already correctly installed, you now only need to install BootDuet (and DUET, which is the EFILDR20 file) to your ESP and then chainload the ESP from GRUB.

Antonio19, on 10 January 2013 - 05:27 PM, said:

Should I use a build with the hard-coded BIOS drive number (for the ESP) ?

No, that's mainly for using without a smart boot loader, and GRUB is smart and well behaved.

Antonio19, on 10 January 2013 - 05:27 PM, said:

Could this work ? I guess I will not set the "boot" flag on the EFI System Partition so I will still be able to boot on the "bios_grub" flag 1 MiB partition ?

That's the preferrable setup. You don't need to copy and windows *.EFI files --- Windows already installed then into the EFI System Partition. You need only:

• Copy the EFILDR20 file to the EFI System Partition (there should be only one in the disk)
  
• Install BootDuet to the same ESP, using the dd command as explained in the INSTALL file (possibly also overwritting the hidden sectors field of the Boot Parameter Block of that partition as well, also as explained in the INSTALL file).
  
• Add an entry to GRUB menu to chainload BootDuet which is on the ESP.

If you don't understand these steps well, then you should probably use the materials on rodsbooks.com, which relieve you from some of these details, but with which I cannot help you.

Greetings,

[Antonio19]

Well, I have tried to use the procedure you describe with no success. The install script you mentioned from Rod Smith is mainly suited to start from an empty drive. So I would have preferred to simply install an access for Windows in the current installation.

When selecting the Windows entry from the GRUB2 menu I get the following error message:
"error: invalid signature."

May be the problem is related on "How is the Hard Drive Partition Signature is calculated" in DUET. There is at least one question from a user on their edk2-devel email archive. I didn't found an answer for this. Nor why there is no problem with the Rod Smith script starting from a blank drive.
--------------------------------------------------------------------------------------------------------------------------------------------------
EDIT 1: For the following test I removed the EFI directory completely (containing Windows / ubuntu boot manager firmware) in the Boot DUET partition. Meaning the partition is either empty or with file Efildr20

On my latest test when I remove the Efildr20 file from the root of the Boot DUET partition I get the same error message meaning it does not load this file. Hence couldn't boot DUET.

Then copying again Efildr20 to the root of the partition, I get "error:   file not found."

Removing it another time and I still get the same message "file not found".

It looks like it is unable to see the file Efildr20 ...

EDIT 2: It looks like the trouble come from the chainloading entry in GRUB2. I used an entry which worked well in pure EFI mode (on another computer).

Per se, if I remove my entry and replace it by the one used by the Chinese Poster:

menuentry "EFI DUET" {
set root=(hd0,3)
chainloader +1
}

I exit grub, but I get the error message:

"This is not a bootable disk. Please insert a bootable floppy and press any key to try again ..."

EDIT 3: replacing chainloader +1 by the path to the Windows boot manager firmware
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi
does not change anything. The system is expecting a bootable partition and it says it isn't. Why isn't it seen as bootable ? partition type is EF00 (boot flag is set).

Removing the file Efildr20 from the partition does not change anything. Meaning the system does not load Efildr20 but exit on error before. Hence should have nothing to do with the chainloading.

Well, I am not close to a quick solution.
--------------------------------------------------------------------------------------------------------------------------------------------------
Here are the detailed steps I followed. If you find anything I did wrong, please let me know.

Partition List on /dev/sda
-------------------------- -----
Command (? for help): p
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 6BA8BBC5-DB5D-47FA-A208-5ED2A213A87C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 4678632301 sectors (2.2 TiB)

Number  Start (sector) End (sector)  Size    Code  Name
   1    2048 1953791   953.0 MiB   0700  EFI System (for future
   2   1953792 1955839   1024.0 KiB  EF02  Boot BIOS GRUB
   3   1955840 2932735   477.0 MiB   0700  EFI Boot DUET
   4   2932736 3194879   128.0 MiB   0C01  Microsoft Reserved
   5   3194880 393818111   186.3 GiB   0700  Windows 7
   6    393820160 784445439   186.3 GiB   AF00  Mac OS X
   7    784445440 785422335   477.0 MiB   0700  boot
   8    785422336 801046527   7.5 GiB 8200  linux-swap
   9    801046528 947529727   69.8 GiB 0700  root
  10    947529728   1181904895   111.8 GiB   0700  home

Preparing the boot partition
---------------------------- -------

$ sudo mkfs.msdos -F 32 -h 1955840 -v /dev/sda3
mkfs.msdos 3.0.12 (29 Oct 2011)
/dev/sda3 has 255 heads and 63 sectors per track,
logical sector size is 512,
using 0xf8 media descriptor, with 976896 sectors;
file system has 2 32-bit FATs and 8 sectors per cluster.
FAT size is 960 sectors, and provides 121868 clusters.
There are 32 reserved sectors.
Volume ID is 84239f3a, no volume label.
$

Show detailed information on ESP for DUET
----------------------------------------- --------------
Command (? for help): i
Partition number (1-10): 3
Partition GUID code: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)
Partition unique GUID: 98475614-D7BE-494E-92DA-02B0A01EB693
First sector: 1955840 (at 955.0 MiB)
Last sector: 2932735 (at 1.4 GiB)
Partition size: 976896 sectors (477.0 MiB)
Attribute flags: 0000000000000000
Partition name: 'EFI Boot DUET'

Install BootDuet on the boot sector
----------------------------------- ---------
$ sudo -i
[sudo] password for jean:
# pwd
/root
# cd /home/jean/Downloads/BootDuet-master
# ls
bd12.bin  bd16_64.bin  bd16.bin  bd32_64.bin  bd32.bin  BootDuet.S  Makefile
bd12.lst  bd16_64.lst  bd16.lst  bd32_64.lst  bd32.lst  COPYING README
bd12.map  bd16_64.map  bd16.map  bd32_64.map  bd32.map  INSTALL
# dd if=bd32.bin of=/dev/sda20 bs=1 skip=90 seek=90 count=420
420+0 records in
420+0 records out
420 bytes (420 copied, 0.000607002 s, 692 kB/s
# logout
$

Get UUID for the Boot DUET Partition
------------------------------------ -----------
$ sudo blkid /dev/sda3
/dev/sda3: UUID="8423-9F3A" TYPE="vfat"

Chainloading Windows 7 in GRUB2
------------------------------- -------------
$ gksu gedit /etc/grub.d/40_custom

then append the following entry:

menuentry "Windows 7 x86_64 UEFI-GPT" {
insmod chain
insmod ntfs
search --fs-uuid --no-floppy --set=root 8423-9F3A
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi
}

Run update-grub
--------------- ------
$ sudo update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.2.0-35-generic
Found initrd image: /boot/initrd.img-3.2.0-35-generic
Found linux image: /boot/vmlinuz-3.2.0-23-generic
Found initrd image: /boot/initrd.img-3.2.0-23-generic
Found memtest86+ image: /memtest86+.bin
done
$

Mount the Boot DUET partition & Copy Microsoft Boot Manager Firmware [from Earlier install, as I have restored an image of the Windows 7 x64 partition]
-------------------------------------------------------------------------------------------------------------------------------------------------------
$ sudo mount /dev/sda3 /boot/efi
[sudo] password for jean:
$ sudo cp -R EFI /boot/efi
$

Copy DUET EFI Loader for FAT32
------------------------------ -------------
$ sudo cp Efildr20 /boot/efi

Unmount the Boot DUET partition
-------------------------------
$ sudo umount /dev/sda3

Change the partition type code of the Boot DUET partition
-------------------------------------------------------------------------
$ sudo gdisk
Command (? for help): t
Partition number (1-10): 3
Current type is 'Microsoft basic data'
Hex code or GUID (L to show codes, Enter = 8300): EF00
Changed type of partition to 'EFI System'

Command (? for help): p
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 6BA8BBC5-DB5D-47FA-A208-5ED2A213A87C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 4678632301 sectors (2.2 TiB)

Number  Start (sector) End (sector)  Size    Code  Name
   1 2048 1953791   953.0 MiB   0700  
   2 1953792 1955839   1024.0 KiB  EF02  
   3 1955840 2932735   477.0 MiB   EF00  
   4 2932736 3194879   128.0 MiB   0C01  
   5 3194880    393818111   186.3 GiB   0700  
   6    393820160    784445439   186.3 GiB   AF00  
   7    784445440    785422335   477.0 MiB   0700  
   8    785422336    801046527   7.5 GiB 8200  
   9    801046528    947529727   69.8 GiB 0700  
  10    947529728   1181904895   111.8 GiB   0700  

Command (? for help): w

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

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sda.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
$

Reboot
---------

Regards.