Jump to content

Acronis ISO Boot on UEFI PC


zamarac

Recommended Posts

There are new annoying bugs in your new version (may be on purpose B) ), but I don't want this thread be hijacked to ISOBuster. Note, out testing and suggestions are free, while the package needs update or enhancement.

My goodness, you're a character aren't you ?

Sorry to have hijacked your thread. I hope you get the answers you seek.

Needless to say I strongly disagree with your comments and ... well ... I will refrain from further commenting.

I will retire from this thread. I'll leave the test exe online for a few more hours, for those who care, I'll remove it later.

You shouln't mention extents, I've two old testing files arround.

a Insane_3PiT.iso (exploring the limits: several extents to the same 3 GiB section), IsoBuster lists at 700 TiB file. Just laugh about the crazy file.

a chars.iso (9 extents to a 26 byte section each): IsoBuster displays size 234 bytes correctly and extract a file 16618 bytes

I will gladly look into these cases cdob. contact me here: www.isobuster.com/support.php#contact and we can follow up via email afterwards.

Cheers.

Link to comment
Share on other sites


Very good. :thumbup:

Though latest version does not work (for me) on the "reference" Slitaz :(:

http://mirror.slitaz.org/iso/3.0/slitaz-3.0.iso

:unsure:

I still see the "Bootimage.img" on LBA 33 sized 2.00 kb (and  in the accessible part of the .iso the \BOOT\ISOLINIUX.BIN at 14.00 kb)

 

I'll check a few other .iso's I have around and see if I can find "unexpected" behaviours and report.

 

Idea's :w00t: :

  1. Not to beat a dead horse :ph34r:, but maybe you could distinguish a "real" name like "Acronis" (which text string is in the boot catalog) from a "fake" name (the friendly name you use to give access to the disc extent) by making the latter red in colour? (relevance of this near to 0, of course, just a way to distinguish actual contents of the .iso from "artifacts")
  2. As above, but if possible an added column with the ID of the image (00/01/02/EF for 80x86(BIOS)/PowerPC/Mac/UEFI) would be nice.
  3. Maybe you could add a setting - a sort of minimal "database" or .ini file - where one could add to a given "name" found in the boot catalog an offset to the bootsector, something like "Acronis=12", when another "queer" image is found one could add an entry to this list, maybe adding a "check" for -say- first few bytes of the loader, like "Acronis=12=EA5E7D000030" to cover more cases?

jaclaz

Link to comment
Share on other sites

My goodness, you're a character aren't you ?

I strongly disagree with your comments.

I will retire from this thread.

 

Everyone in this thread is a character, you're simply not familiar with that. :)

 

If you "strongly desagree", why your last version:

- produced no improvements in the area you claim it did? Can you post a screenshot proving otherwise, using same checksum package?

- introduced new bugs like desyncing left and right program pans, and also removal of settings allowing to stop scanning hard drive at each restart - instead of simply opening the last open image at program restart, or at least offering such settings?

 

If I'm mistaken - pls show were. This is not "my" thread, but its not devoted to paid program testing either. If you're willing to offer real improvements relevant to subject of this thread (no other ISOs discussed) with no artificial barriers I'll be glad to test it further.  :yes:

 

 

I'll check a few other .iso's I have around and see if I can find "unexpected" behaviours and report.

 

Pls do it on ISOBuster's forum if there is one, but certainly outside of this thread. Your above post was reported to moderation team. Btw you never explained the purpose of inviting such discussion here to begin with, and it doesn't look clear cut to me. You can't do whatever you want in blatant disregard to forum rules - regardless what you think about yourself. Especially when trying at the same time to teach moral in many other threads, like you have any.   ;)

Edited by zamarac
Link to comment
Share on other sites

@isobuster

JFYI:

 

Files on which bextract.cmd works fine (and latest posted Isobuster does not):

Kav rescue disk 10
http://rescuedisk.kaspersky-labs.com/rescuedisk/updatable/kav_rescue_10.iso
has seemingly a "eltorito.img" on sector 228 sized 25225 bytes


Acronis Antimalware CD
https://kb.acronis.com/content/18647
has ISOLUX.BIN on sector 228 92 11691 bytes


Files on which bextract.cmd DOES NOT work (and Isobuister also *somehow* fails):
2OS 3.16
http://sourceforge.net/projects/meos/
http://sourceforge.net/projects/meos/files/binarys/3.16/
(isobuster gets it seemingly "wrong" in size as 2 Kb, AND it recognizes it as MagicIso bootsector, though it is seemingly an ISOLINUX)

2OS 8.10
http://sourceforge.net/projects/meos/
http://sourceforge.net/projects/meos/files/binarys/8.10/
(isobuster gets it seemingly "right" in size, 14 Kb, AND it recognizes it as MagicIso bootsector, AND it is seemingly a modified ISOLINUX, BUT isobuster extracts only the first 12 Kb)

 

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

 

@isobuster

JFYI:

 

Files on which bextract.cmd works fine (and latest posted Isobuster does not):

Kav rescue disk 10
http://rescuedisk.kaspersky-labs.com/rescuedisk/updatable/kav_rescue_10.iso
has seemingly a "eltorito.img" on sector 228 sized 25225 bytes


Acronis Antimalware CD
https://kb.acronis.com/content/18647
has ISOLUX.BIN on sector 228 11691 bytes


Files on which bextract.cmd DOES NOT work (and Isobuister also *somehow* fails):
2OS 3.16
http://sourceforge.net/projects/meos/
http://sourceforge.net/projects/meos/files/binarys/3.16/
(isobuster gets it seemingly "wrong" in size as 2 Kb, AND it recognizes it as MagicIso bootsector, though it is seemingly an ISOLINUX)

2OS 8.10
http://sourceforge.net/projects/meos/
http://sourceforge.net/projects/meos/files/binarys/8.10/
(isobuster gets it seemingly "right" in size, 14 Kb, AND it recognizes it as MagicIso bootsector, AND it is seemingly a modified ISOLINUX, BUT isobuster extracts only the first 12 Kb)

 

jaclaz

 

 

 

About reboot.pro site being for sale and/or decreases of traffic... What I post, nonsense as it might be, tends to be "specific"

 

jaclaz

 

All this staff above you keep posting is irrelevant to the thread topic. You don't behave this way on reboot.pro forum - why? You don't try to disrupt discussions over there, neither hijack threads. Is it because popularity of reboot.pro is so low now, there are no new developments, and its owner attempts to sell stolen forum members contributions failed miserably? Sorry you didn't get your cash.  :}  Is that why you try to raise popularity of reboot.pro by damaging reputation of msfn.org forum - disrupt popular discussions here? I know you're around for awhile here, but things were never so bad at reboot.pro. So desperate now? As admitted, you were paid a moderator fee on reboot.pro until removed on forum members strong demand, but still keeping your share? While you're just an ordinary member here - so may be trying to extort some deals from msfn.org team by hijacking hot threads?  :lol:

Edited by zamarac
Link to comment
Share on other sites

:boring:

 

Anyways, questions of my own regarding this WinPE5 image. What is its architecture? Windows 8 brought out an "apology" of sorts from Microsoft, who had intended to see x86 disappear completely (in collusion with Intel and the others who drafted UEFI 2.3.1) and obviously this hasn't happened. As a result, Windows 8 (and WinPE as evidenced by Server 2012 PXE boot roms) have the ability to do a UEFI boot on both x86 and amd64 platforms. Although, I do not know if they can be interchanged, as I solely deal with 64bit UEFI booting.

Link to comment
Share on other sites

Anyways, questions of my own regarding this WinPE5 image. What is its architecture? 

 

If you're asking about Acronis WinPE image, ATIH2015_WinPE5.iso structure was shown in this post. This is 64-bit ISO to my understanding. My question was, how it boots in UEFI mode (even when burned as a CD, though booting it as ISO is more interesting) assuming its Fat-formatted EFI volume is inside El-Torito floppy - is it?

Edited by zamarac
Link to comment
Share on other sites

My question was, how it boots in UEFI mode (even when burned as a CD, though booting it as ISO is more interesting) assuming its Fat-formatted EFI volume is inside El-Torito floppy - is it?

The 64 bit UEFI firmware reads the El Torito boot catalog, mounts the EFI referenced FAT floppy and lauch the EFI application \efi\boot\bootX64.efi.
Link to comment
Share on other sites

That post you have found the x64 EFI boot file but not what architecture the WinPE is.

 

Is that what you're looking for?  :rolleyes: Where would it show "the ability to boot on x86 and amd64 platforms interchangeably"? I can see only UEFI & BIOS support.

 

dpv6n4.jpg

 

The 64 bit UEFI firmware reads the El Torito boot catalog, mounts the EFI referenced FAT floppy and lauch the EFI application \efi\boot\bootX64.efi.

 

Thanks for extreme clarity - as always brief.  :D  So the EFI.img is in fact the El-Torito floppy image placed on the ISO, and it has a boot catalog? Is this catalog placed in a certain file inside the floppy, or just in a few sectors in the floppy's bootsector that were referenced to as BootCatalog.cat earlier?

 

But in case of ACIH2015_Linux.iso there are 2 El-Torito floppies on the same ISO - one is for BIOS PC boot, and another is for EFI boot - correct? So how the system finds the right floppy to deal with? Does it mount both (or all) floppies first, and then look for specific files in each?

 

How this structure is different from a bootable Acronis2015_Linux USB Thumb? Any principal differences in booting Linux from ISO compare to a USB Thumb in UEFI and BIOS modes?

Edited by zamarac
Link to comment
Share on other sites

as always brief.

Well, this is asking for http://en.wikipedia.org/wiki/El_Torito_(CD-ROM_standard)

It's 20 years old only. Time to learn some basics?

 

So the EFI.img is in fact the El-Torito floppy image placed on the ISO, and it has a boot catalog? Is this catalog placed in a certain file inside the floppy, or just in a few sectors in the floppy's bootsector that were referenced to as BootCatalog.cat earlier?

The El Torito specification requests one boot catalog. CD sector 17 contains a pointer to the boot catalog.

Details clarifies the specification and a hex editor. 

 

But in case of ACIH2015_Linux.iso there are 2 El-Torito floppies on the same ISO - one is for BIOS PC boot, and another is for EFI boot - correct? So how the system finds the right floppy to deal with?

The system reads CD sector 17 and the boot catalog next.

There is one BIOS and another EFI entry at the boot catalog.

The system interprets the boot catalog and select one appropiate entry.

 

How this structure is different from a bootable Acronis2015_Linux USB Thumb? Any principal differences in booting Linux from ISO compare to a USB Thumb in UEFI and BIOS modes?

A USB Thumb resembles a hard disk. Booting from hard disk rules apply here. The UEFI and BIOS reads hard disk structures and boot this

More basics http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface http://en.wikipedia.org/wiki/Master_boot_record

The BIOS process the MBR code.

A 64 bit UEFI reads NVRAM or searches file \efi\boot\bootX64.efi

By the way: the 64 bit Acrornis dat*.dat UEFI files works at a 64 bit machine with a BIOS too.

No need for the 'BIOS' files at a 64 bit machine.

The 'BIOS' files refers to 32 bit machines.

Link to comment
Share on other sites

Time to learn some basics?

 

By the way: the 64 bit Acrornis dat*.dat UEFI files works at a 64 bit machine with a BIOS too.

No need for the 'BIOS' files at a 64 bit machine.

The 'BIOS' files refers to 32 bit machines.

 

You can laugh, I was never a big fan of CDs & DVDs in terms of booting power - too slow and at times costly to make.  :)

 

Not sure I fully understand your comment about BIOS support by UEFI files on a 64-bit PC. On one hand, it means that the 64-bit Linux ISO is likely to work on BIOS 32-bit PC as well - is that correct? But it won't on UEFI 32-bit PC? How about WinPE ISO - can it work on both, and how to find out looking at its structure - possible?

 

Does it mean that on 64-bit BIOS PC, the Boot Catalog points FW to UEFI floppy instead of BIOS floppy? If YES, is it a typical approach for Linux based ISOs? But the BIOS floppy contains other files apart from *.dats. Does it mean that on a BIOS 64-bit PC only UEFI floppy is useful?

 

Since USB Thumb is treated as Hard Drive rather than CD-ROM (I didn't know that  :huh: ), is it possible to use the Linux ISO's 2 El-Torito images (BIOS and UEFI) on a USB Thumb in any way - either by copying the images or extracting their content? This may be needed, if Acronis is NOT installed on a user's PC, so no way to prepare Acronis USB Thumb from the program GUI, but a user can possibly download Acronis Linux ISO and extract it onto a bootable USB Thumb - possible? Would it work the same way for a WinPE ISO?

Edited by zamarac
Link to comment
Share on other sites

Not sure I fully understand your comment about BIOS support by UEFI files on a 64-bit PC. On one hand, it means that the 64-bit Linux ISO is likely to work on BIOS 32-bit PC as well - is that correct? But it won't on UEFI 32-bit PC?

UEFI is a firmware just like BIOS is. PCs with UEFI firmware "can" emulate BIOS. I say "can" because it isn't a requirement. Manufacturers may include this option as a compatibility for legacy operating systems. This is typically termed as a CSM even if the "BIOS" menus don't have options to configure it or use that term directly. Some menus do not use the term CSM, but instead "Windows 8 mode" as (initially) Windows 8 certification required UEFI 2.3.1, which is why initial launch products came with 64bit Windows.

As a backstory, only Vista SP1 x64 to Windows 7 SP1 x64 supported MBR booting on UEFI 2.3.1 firmware. It changed prior to the launch of Windows 8 as some point, as evidence that Windows 8 has a 32bit version that also supports UEFI 2.3.1. All editions of Vista and 7 32bit do not support UEFI hardware officially, and there are specific cases where those OSes will not boot properly, if at all on that hardware.

As of now, there is no such thing (that I am aware of) as a UEFI 32bit PC. Remember the UEFI 2.3.1 spec was designed to eliminate 32bit, so they are natively 64bit. All UEFI "32bit" systems I have encountered are actually 64bit with a firmware limitation to support the boot of only 32bit MBR or GPT disks. You can think of these systems as being lacking of a proper CSM.

So to clarify our use of (seemingly) outdated terms...

BIOS is the "old" computer firmware, but it is also a term referring to booting an MBR disk. Another term for this is Legacy boot. And since the term BIOS is also (for many years) referred to the BIOS Setup menu we can enter at boot to configure said BIOS settings, it is difficult to just stop calling those menus BIOS. So we are not now (on modern hardware) entering the BIOS, but the UEFI. But we have called those menus BIOS for so many years... and with exception to the new Visual BIOSes on Intel, Asus and MSI boards, many manufacturers still sell products where the Setup menu looks the same as their older BIOS based systems. So understand the various ways people may use the term, then you can probably figure out which meaning they mean.

I can't speak specifically for Linux, but I would imagine that in order for it to boot on any specific platform, it would require the appropriate boot rom. In my own experience with Recovery DVDs, I specifically deal with UEFI x64 systems, so the DVDs can boot in legacy or on UEFI systems in x64 mode. Being a "victim" of initial pre-launch Windows 8 requirements, we pretty much eliminated x86 OS support on the UEFI hardware, so no testing of multi-boot (BIOS vs UEFI mode) Recovery DVDs were done on the firmware locked x86 booting hardware.

Of course, as myself, I don't delve too deeply into the structure of this or that (I leave that to jaclaz) and instead go for the "let's see if this works" approach. Thinking about this, if you have a concern about whether or not said ISO can boot on the x86 locked UEFI hardware, I MAY still have that board available to me to test with, providing you can give instructions on how to make the boot media.

Link to comment
Share on other sites

 

Not sure I fully understand your comment about BIOS support by UEFI files on a 64-bit PC. On one hand, it means that the 64-bit Linux ISO is likely to work on BIOS 32-bit PC as well - is that correct? But it won't on UEFI 32-bit PC?

UEFI is a firmware just like BIOS is. PCs with UEFI firmware "can" emulate BIOS.

 

If you have a concern about whether or not said ISO can boot on the x86 locked UEFI hardware, I MAY still have that board available to me to test with, providing you can give instructions on how to make the boot media.

 

Thanks for interesting overview. :)  In this thread we were exploring primary boot options available in Acronis ISOs keeping in mind that UEFI emulation of BIOS features via CSM is not always available on every PC despite required by standards. Did you find an answer to your earlier WinPE question from the pic I posted?  :unsure:

 

As to testing Acronis ISOs boot compatibility with UEFI 32-bit FW, that would be nice! I found some ad links to trial install ISOs mentioned here (slow speed). You can try latest Linux and WinPE ones, they seems to be clean, just follow download instructions in bold.

Edited by zamarac
Link to comment
Share on other sites

On one hand, it means that the 64-bit Linux ISO is likely towork on BIOS 32-bit PC as well - is that correct?

No, not this direction.

Linux-based bootable media http://www.acronis.com/en-us/support/documentation/AcronisBackup_11.5/index.html#1230.html

The 32-bit components can work on 64-bit hardware. However, you need 64-bit components to boot a machine that uses Unified Extensible Firmware Interface (UEFI).

How about WinPE ISO

A UEFI (WinPE) ISO is either 32 bit or 64 bit.

can it work on both

No, UEFI specification supports one EFI boot catalog entry only.

and how to find out looking at its structure - possible?

A 32 bit UEFI searches file /efi/boot/bootia32.efi

Acronis dosn't support 32-Bit UEFI devices at boot: https://kb.acronis.com/content/43091

 

Does it mean that on 64-bit BIOS PC, the Boot Catalog points FW to UEFI floppy instead of BIOS floppy? If YES, is it a typical approach for Linux based ISOs?

There is no 64 bit BIOS. It's independent from the OS.

The BIOS reads the Boot Catalog and selects the BIOS entry.

The UEFI firmware reads the Boot Catalog and selects the EFI entry.

One ISO for both: BIOS and UEFI

 

Since USB Thumb is treated as Hard Drive rather than CD-ROM (I didn't know that :huh: )

Do you like to boot from a USB Thumb? This was not specified so far.

Yes, this assume a USB HDD booting at current hardware.

Windows differs a USB Thumb and a USB HDD, actually a removable or fixed disk... I'm claiming amnesia next.

 

is it possible to use the Linux ISO's 2 El-Torito images (BIOS and UEFI) on a USB Thumb in any way

Use previous mentioned grub.cfg: this works at BIOS and UEFI 64 bit machines.

Add a loopback grub.cfg entry to 32 bit BIOS machines.

Yes, you may extract files as another option.

 

Would it work the same way for a WinPE ISO?

https://kb.acronis.com/content/46255 https://kb.acronis.com/content/41723 https://kb.acronis.com/content/11071

There are a lot of different cases: different WinPE versions add components to ISO or to WIM image. Use the manufacturer solution.

It resembles a default WinPE. Diskpart section similiar http://msdn.microsoft.com/library/hh825109.aspx

And copy extracted files to USB thumb.

I'm claiming amnesia at Acronis WinPE ISO questions...

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...