Etcher: PVE images seem not bootable but, in fact, are

[Chemin1]

Current versions of Etcher confront me with "It looks like this is not a bootable image" when I try to flash an ISO image of the current Proxmox VE 5.4 onto USB even though, in fact, it gives a bootable USB drive.

I checked with Windows 10 1809 (OS Build 17763.1) x64 and Etcher versions

• 1.5.24 Error
• 1.5.17 Error
• 1.5.5 Error
• 1.5.0 Error
• 1.4.9 NO error

and on PVE 5.4 x64 with Etcher versions

• 1.5.24 Error
• 1.5.0 Etcher crashing due to some other error about images
• 1.4.9 NO error

Version 1.5.0 apparently introduced some change that gives this message for PVE ISO files.

Etcher's documentation explains

Etcher copies images to drives byte by byte, without doing any transformation to the final device, which means images that require special treatment to be made bootable, like Windows images, will not work out of the box.

Copying byte by byte is exactly what is requried for PVE ISO files.
This can be seen as using dd and avoiding Rufus is suggested in the PVE Wiki and even clearer as the USB drive is working in the end.

[lurch]

Just because I was curious, I decided to have a go at digging into this...
According to mbr the PVE ISO has a single partition, with type 0xee. That means that partitioninfo (which is used in etcher-sdk ) then tries to parse the GPT, but gpt then throws an error because it has an invalid GPT signature, and it seems that paritioninfo isn't handling this error?

$ node
> partitioninfo = require('partitioninfo');
{ PartitionNotFound: [Function: PartitionNotFound],
  get: [Function: get],
  getPartitions: [Function: getPartitions] }
> partitioninfo.getPartitions('/home/qpc/Downloads/proxmox-ve_5.4-1.iso')
Promise { <pending> }
> (node:13391) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: Invalid signature: Expected "EFI PART", saw "PM"

That's as far as my knowledge goes, and @zvin will have to look into this further... :slightly_smiling_face:

I'm guessing that the image is still bootable because the BIOS probably isn't bothering to check the GPT signature?

... did a bit more digging and found https://superuser.com/questions/1399681/what-is-the-gpt-header-signature-for and if I hexdump the PVE ISO then I see it _does_ have a EFI PART signature (at offset 0x200), so maybe the bug is something to do with the loop inside detectGPT ?
Hmmm, and why does getDiskPartitions do const mbrBuf = await readFromDisk(disk, offset, MBR_SIZE); but then const gptBuf = await readFromDisk(disk, 0, GPT_SIZE); - shouldn't the gptBuf line also be using offset ?

[lurch]

Version 1.5.0 apparently introduced some change that gives this message for PVE ISO files.

Perhaps https://github.com/balena-io-modules/partitioninfo/pull/38 is that change? :man_shrugging:

[Chemin1]

Thank you and @zvin for looking into this!

I'm guessing that the image is still bootable (...)?

Yes. Even though the error message appeared, I successfully booted the current PVE from the USB drive that was flashed by the current Etcher.

[zvin]

The issue comes from node-gpt that can't parse the partition table of this disk image.
It errors with Error: Invalid signature: Expected "EFI PART", saw "PM".
I'll have a look.

[zvin]

fdisk output:

Disk proxmox-ve_5.4-1.iso: 655.3 MiB, 687079424 bytes, 1341952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 2CBA5013-16E7-4D41-B75D-544A6474498B

Device                  Start     End Sectors   Size Type
proxmox-ve_5.4-1.iso1      64     539     476   238K Microsoft basic data
proxmox-ve_5.4-1.iso2     540    6299    5760   2.8M EFI System
proxmox-ve_5.4-1.iso3    6300 1341303 1335004 651.9M Apple HFS/HFS+
proxmox-ve_5.4-1.iso4 1341304 1341903     600   300K Microsoft basic data

[zvin]

Etcher's "It looks like this is not a bootable image" message only means that we couldn't find a partition table in the disk image.
I guess the version of partitioninfo that was working just returned the protective MBR partition when parsing the GPT partition table was failing.

[Chemin1]

Thank you for solving this!