Support for GPT boot drive

[Brian K]

eldiener wrote:
since it would allow end-user to buy drives greater than 2 TB
> for their boot drive and than use it as a GPT drive for multi-booting.
>

I'm in agreement with BIBM eventually supporting multi-booting on GPT drives. However you can multi-boot numerous OS on a GPT drive now, using IFL to choose the OS to boot. You don't have to wait for an updated BIBM if you would like to multi-boot a GPT drive now. I have one system with Ubuntu, two Win8.1 and Win10 on HD0, a SSD. Each OS is independent and no OS sees the other OS when it's booted.

[eldiener]

Brian K wrote:
> eldiener wrote:
> since it would allow end-user to buy drives greater than 2 TB
> > for their boot drive and than use it as a GPT drive for multi-booting.
> >
>
> I'm in agreement with BIBM eventually supporting multi-booting on GPT drives. However
> you can multi-boot numerous OS on a GPT drive now, using IFL to choose the OS to
> boot.

What is IFL ? Is this Terabyte's "Image for Linux" ? How does that help multi-booting OSs on a GPT drive ?

> You don't have to wait for an updated BIBM if you would like to multi-boot a
> GPT drive now. I have one system with Ubuntu, two Win8.1 and Win10 on HD0, a SSD.
> Each OS is independent and no OS sees the other OS when it's booted.

[Brian K]

eldiener wrote:
>
> What is IFL ? Is this Terabyte's "Image for Linux" ?

Yes. Image for Linux.

A UEFI Win8/Win10 has 4 partitions. Recovery, ESP, MSR and OS. A UEFI Ubuntu can have at least 3 partitions. ESP, Swap and OS.

Say you are currently booting Win8 from a GPT disk. The disk also contains a Win10 partition and an Ubuntu partition. To boot Win10 you would use an IFL script to restore the Win10 ESP and Recovery images to the relevant partitions and also change the Type GUID of the Win8 partition to a type not recognized by Win10. Use a similar method to boot Ubuntu.

It only takes 30 seconds to boot a different OS. Not BIBM but it works.

[Bob Coleman]

eldiener wrote:

> How about it Terabyte ? You have a great product which end-users
> appreciate. But please don't stick your head in the sand and act like this
> is not an issue, whether now or for the near future.

While I don't need this right now, I agree that it would be a good thing, but isn't that putting it a bit strongly? What has anyone from Terabyte ever said to imply that they don't think it is an issue?

[DrTeeth]

On Fri, 22 Jan 2016 11:10:15 PST, just as I was about to take a herb,
Bob Coleman disturbed my reverie and wrote:

>What has anyone from Terabyte ever said to imply that they don't think it is an issue?
I imagine the poster gets that impression as GPT disks are popular and
TBU has not done anything about it other than to produce a paper
showing how to convert GPT disks to MBR. I myself have wondered about
this lack of progress, but as all my disks are 2TB, it has not
bothered me.
--
Cheers,

DrT

"If you want to find out what is wrong
with democracy, spend five minutes with
the average voter." - Winston Churchill

[eldiener]

Bob Coleman wrote:
> eldiener wrote:
>
> > How about it Terabyte ? You have a great product which end-users
> > appreciate. But please don't stick your head in the sand and act like this
> > is not an issue, whether now or for the near future.
>
> While I don't need this right now, I agree that it would be a good thing, but isn't
> that putting it a bit strongly? What has anyone from Terabyte ever said to imply
> that they don't think it is an issue?

By Terabyte not ever giving the least indication that the restriction in BIBM of booting from an MBR/EMBR drive might be lifted in some future release of BIBM, it appears to me that Terabyte does not think that this is an issue for BIBM or their customers.

[Bob Coleman]

Or don't think the issue has a solution?

I don't know one way or the other, but I lean in the direction of thinking that they can't possibly not know/think it's an issue.

[jaydub]

If 2TB were the issue, I'd say carryon with BIBM. I love BIBM. Problem is, I want to use an NVRM protocol (rather than AHCI) for faster bandwidth and lower latency. No can do with BIBM. For this reason alone, that fat guy in Nevada (I'm thinking The Simpsons) needs to put pencil to paper.

[tas3086]

I know that you can boot and use BIBM from a pen drive. I do some maintenance this way.

I have not tried this, but can BIBM from a PEN booted drive, boot an OS on a separate GPT or MBR disk OS partition?

If so install BIBM on a pen/SD drive, and boot into any disk or ssd drive MBR or GPT OS partition. (pen drive need not be used nor accessed for anything else).
Let me know if I should give it a try!
======================================================
Ok I tried. I was not able to select a GPT partition to boot from, so I guess my suggestion won't work.
So I now agree that BIBM needs to support UEFI and GPT boot selection
Sorry .....

[minimalist]

I didn't notice this was an old thread.

After using BING and BIBM for many years, I have finally moved away from them for GPT disk systems. I have several comments pertinent to this thread:

1) No one has mentioned how much easier dealing with Windows installers is with GPT disks compared with MBR.

On a GPT system, the Windows installer will only write to the selected install partition, the EFI partition, and the Microsoft Reserved partition. If you install when the MS boot manager is the default boot method, the new Windows system will be added to the MS boot manager. The installed partition can be copied to another location to create a clone and a new entry added to the MS boot manager using your favorite BCD editor. The copying and BCD editing can even be done with BIBM from a flash drive, if you can boot legacy/MBR from your UEFI system easily.

On an MBR system, the Windows installer typically (for us in this forum) will not know the correct situation on all disks as most or all disks have more than four partitions. It will gladly write on any "unused" space. It will also gladly add boot files to other Windows partitions or even just ordinary partitions that contain a Drive:\\Windows folder or maybe even Drive:\\Program Files folder. Both of these are relative disasters, although recoverable(but it is way too much trouble to take ownership of all those \boot files and delete them). I now won't use a Windows installer on an MBR system with EMBRM/BIBM unless there is only one drive plugged in and the Windows installer is given access to all of it. Of course this is a small price to pay for the convenience of BIBM.

2) For a boot manager replacement for GPT/UEFI look at rEFInd. There is a lot of information there. All BIOSes are different, my limited experience is that it is best to leave the MS boot manager at the default EFI\Microsoft\Boot\bootmgfw.efi and use the EFI shell to put rEFInd at another location following http://www.rodsbooks.com/refind/install ... l#efishell
See more at https://wiki.archlinux.org/index.php/Un ... l_Commands As near as I can tell, no one has figured out how to boot Windows implementations without using the Windows Boot Manager, so you just need rEFInd to choose between WBM and (your favorite linux loader).

3) Given the end of comment #2 above, BIBM for GPT/UEFI would only need to be able to boot GRUB2, SYSLINUX and Windows Boot Manager.

4) If comment #3 is unattainable, it would be great to offer a bibm.efi executable with the current partioning/backup utilities that could be booted directly on UEFI systems.

5) @eldiener re 250Gb systems. I always thought one of the main assets of multibooting was to separate all your program, data and swap files away from the OS. Then all your OSes share programs and data. To install a new OS you just install it and make sure the logical drives with your files are mounted at the correct locations. Of course it helps if you don't use any non-programs that need to be installed rather than just run from wherever they are located(Most/many non-portable Windows programs don't need to be installed). Bye bye anything from Apple, Google, Microsoft....