I have two bootable partitions, /dev/sda and /dev/sda2. However, when I restart my PC the UEFI bootsystem only recognizes the /dev/sda partition.

How do I fix this? I set the boot and esp flags to /dev/sda2, which contains a Manjaro ISO. /dev/sda contains a Solus ISO. I'm using the UEFI bootsystem, NOT Legacy boot. How can I set it to recognize /dev/sda2 rather than /dev/sda?

Here is an image if it will better articulate what I'm trying to type.

Partition layout

  • UEFI only boots from /EFI/Boot/bootx64.efi in the ESP - efi system partition (the FAT32 one) for external devices. Only BIOS boot is thru MBR of a drive, which is not shown.
    – oldfred
    Jun 30 '20 at 3:38
  • Not entirely sure what your trying to say, sorry. But I don't have any external devices and I was able to boot into /dev/sda (Solus OS) just fine.
    – samuel
    Jun 30 '20 at 3:43
  • It is extremely weird to have multiple iso9660 partitions on a hard drive; are you sure it's what you meant to do and could work? Jun 30 '20 at 3:50
  • Also: "boot to /dev/sda" and "boot to /dev/sda1" are quite different and it surprises me that sda boots at all when what you've displayed shows sda1 as the Solus partition. Are those labels accurate? Jun 30 '20 at 3:54

The UEFI specification requires the firmware to support FAT32 for EFI System Partition, but it is allowed to support other filesystem types too. For example, Apple devices support HFS+ at the firmware level, and apparently at least some Asus motherboards support NTFS and ISO9660 in addition to FAT32.

It seems you've originally written the Solus ISO to /dev/sda, which is a whole-disk device, so the image must have included its own partition table, effectively creating /dev/sda1 for you. That's what isohybrid-prepared ISO images do - and without such special preparation, an ISO will not be bootable at all when written onto a HDD-like storage device.

Technically, the isohybrid command uses the flexibility of the iso9660 format to prefix the image with a partition table (either MBR or GPT style) and then arrange things so that in addition to being a valid ISO image as a whole, it will also be possible to parse it as a raw disk image that includes a partition table and (usually) a single partition containing a ISO9660 filesystem.

If the Manjaro ISO also has been isohybrid-prepared, it also includes a partition table of its own. If you created /dev/sda2 and wrote the ISO into it, there is now a partition table within a partition - and that is definitely not normal. Linux could sort of deal with it (with the help of losetup and/or kpartx commands, at least), but I would not be at all surprised if the system firmware cannot make sense of it.

(As far as I know, there is no official name for the arrangement that allows an ISO image to be also treated as a functional HDD image - but the isohybrid seems to have been the first tool to implement it.)

Your current partitioning scheme on sda can be interpreted in a total of three ways:

  1. A "superfloppy" configuration: a valid ISO9660 filesystem (Solus) written into the whole-disk device sda, with some undefined garbage after the end of the filesystem (which would actually be the Manjaro ISO)
  2. An apparently valid GPT partition table indicating the presence of two partitions: an ISO9660 filesystem (Solus) and a second ISO9660 filesystem (Manjaro).
  3. The super-weird option: a GPT partition table indicating the presence of two partitions: an ISO9660 filesystem (Solus), and a second partition containing another partition table, which defines one partition with an ISO9660 filesystem in it (Manjaro)

It seems that your system firmware will test for case #1 before #2, and therefore prefers interpretation #1. Unfortunately, there may be nothing you can do to override that. If your firmware allows you to access an UEFI shell, you could use its map command to see how the firmware sees your disk... but not necessarily allow you to modify that.

As far as I know, no firmware nor OS will automatically accept interpretation #3, but with Linux you could pretty easily use kpartx -a /dev/sda2 to parse that second partition table and generate a /dev/mapper/sda2p1 device to access it, if you ever had need to do such a thing.

(You might find such a nested partition structure when dealing with Xen VMs set up with a VM system image on a partition device: although the image of the VM's system disk is on a partition, the VM sees it as a whole disk and so the OS installer will partition it. Now, if you have to modify some files within a VM that hangs at early boot to make it boot successfully again, you'll need to be able to deal with second-order partitions like this. I had to do something very much like this just last week!)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.