How to produce an ISO image that boots only on UEFI?
1
I want to create an ISO image that boots ONLY on UEFI environments. I've managed to create images that boot on BIOS systems, but I can't figure out how to create an image that works only on UEFI.
I've read xorriso's manual, and fiddled a lot with its options, but had no luck.
I need that when such image gets flashed into a USB stick, it boots only on UEFI, and not in MBR-based BIOS.
boot grub2 uefi iso
asked Jan 17 at 20:10
Luis LavaireLuis Lavaire
167
|
show 5 more comments
1
I want to create an ISO image that boots ONLY on UEFI environments. I've managed to create images that boot on BIOS systems, but I can't figure out how to create an image that works only on UEFI.
I've read xorriso's manual, and fiddled a lot with its options, but had no luck.
I need that when such image gets flashed into a USB stick, it boots only on UEFI, and not in MBR-based BIOS.
boot grub2 uefi iso
asked Jan 17 at 20:10
Luis LavaireLuis Lavaire
167
There are a few discussion of this here already. Maybe share some of your research? What other Q&A have you visited?
– jdv
Jan 17 at 20:34
2
Duplicate of : UEFI only USB key, just extract ISO ( 7 zip or similar) to FAT32 formatted flash drive partition & set boot flag. askubuntu.com/questions/395879/…
– oldfred
Jan 17 at 20:37
4
Possible duplicate of How to create UEFI-only bootable USB live media?
– user535733
Jan 17 at 22:50
No, it's not. Those questions refer to how to create an USB stick that can boot one or more ISO images on an UEFI environment. My question is how to create ISO images that, when flashed into an USB stick, are bootable only on UEFI.
– Luis Lavaire
Jan 18 at 4:28
Captcha does not let me post answers. So as comment: Debian does it for its ARM64 ISOs. See: wiki.debian.org/RepackBootableISO#arm64_release_9.4.0 You can avoid EFI image duplication by using -e '--interval:appended_partition_2:all::' instead of -e $file_path.
– Thomas Schmitt
Jan 18 at 6:15
|
show 5 more comments
1
1
1
1
I want to create an ISO image that boots ONLY on UEFI environments. I've managed to create images that boot on BIOS systems, but I can't figure out how to create an image that works only on UEFI.
I've read xorriso's manual, and fiddled a lot with its options, but had no luck.
I need that when such image gets flashed into a USB stick, it boots only on UEFI, and not in MBR-based BIOS.
boot grub2 uefi iso
asked Jan 17 at 20:10
Luis LavaireLuis Lavaire
167
I want to create an ISO image that boots ONLY on UEFI environments. I've managed to create images that boot on BIOS systems, but I can't figure out how to create an image that works only on UEFI.
I've read xorriso's manual, and fiddled a lot with its options, but had no luck.
I need that when such image gets flashed into a USB stick, it boots only on UEFI, and not in MBR-based BIOS.
boot grub2 uefi iso
boot grub2 uefi iso
asked Jan 17 at 20:10
Luis LavaireLuis Lavaire
167
asked Jan 17 at 20:10
Luis LavaireLuis Lavaire
167
edited Jan 29 at 1:05
Luis Lavaire
asked Jan 17 at 20:10
Luis LavaireLuis Lavaire
167
asked Jan 17 at 20:10
Luis LavaireLuis Lavaire
167
asked Jan 17 at 20:10
Luis LavaireLuis Lavaire
167
167
There are a few discussion of this here already. Maybe share some of your research? What other Q&A have you visited?
– jdv
Jan 17 at 20:34
2
Duplicate of : UEFI only USB key, just extract ISO ( 7 zip or similar) to FAT32 formatted flash drive partition & set boot flag. askubuntu.com/questions/395879/…
– oldfred
Jan 17 at 20:37
4
Possible duplicate of How to create UEFI-only bootable USB live media?
– user535733
Jan 17 at 22:50
No, it's not. Those questions refer to how to create an USB stick that can boot one or more ISO images on an UEFI environment. My question is how to create ISO images that, when flashed into an USB stick, are bootable only on UEFI.
– Luis Lavaire
Jan 18 at 4:28
Captcha does not let me post answers. So as comment: Debian does it for its ARM64 ISOs. See: wiki.debian.org/RepackBootableISO#arm64_release_9.4.0 You can avoid EFI image duplication by using -e '--interval:appended_partition_2:all::' instead of -e $file_path.
– Thomas Schmitt
Jan 18 at 6:15
|
show 5 more comments
There are a few discussion of this here already. Maybe share some of your research? What other Q&A have you visited?
– jdv
Jan 17 at 20:34
2
Duplicate of : UEFI only USB key, just extract ISO ( 7 zip or similar) to FAT32 formatted flash drive partition & set boot flag. askubuntu.com/questions/395879/…
– oldfred
Jan 17 at 20:37
4
Possible duplicate of How to create UEFI-only bootable USB live media?
– user535733
Jan 17 at 22:50
No, it's not. Those questions refer to how to create an USB stick that can boot one or more ISO images on an UEFI environment. My question is how to create ISO images that, when flashed into an USB stick, are bootable only on UEFI.
– Luis Lavaire
Jan 18 at 4:28
Captcha does not let me post answers. So as comment: Debian does it for its ARM64 ISOs. See: wiki.debian.org/RepackBootableISO#arm64_release_9.4.0 You can avoid EFI image duplication by using -e '--interval:appended_partition_2:all::' instead of -e $file_path.
– Thomas Schmitt
Jan 18 at 6:15
There are a few discussion of this here already. Maybe share some of your research? What other Q&A have you visited?
– jdv
Jan 17 at 20:34
There are a few discussion of this here already. Maybe share some of your research? What other Q&A have you visited?
– jdv
Jan 17 at 20:34
2
2
Duplicate of : UEFI only USB key, just extract ISO ( 7 zip or similar) to FAT32 formatted flash drive partition & set boot flag. askubuntu.com/questions/395879/…
– oldfred
Jan 17 at 20:37
Duplicate of : UEFI only USB key, just extract ISO ( 7 zip or similar) to FAT32 formatted flash drive partition & set boot flag. askubuntu.com/questions/395879/…
– oldfred
Jan 17 at 20:37
4
4
Possible duplicate of How to create UEFI-only bootable USB live media?
– user535733
Jan 17 at 22:50
Possible duplicate of How to create UEFI-only bootable USB live media?
– user535733
Jan 17 at 22:50
No, it's not. Those questions refer to how to create an USB stick that can boot one or more ISO images on an UEFI environment. My question is how to create ISO images that, when flashed into an USB stick, are bootable only on UEFI.
– Luis Lavaire
Jan 18 at 4:28
No, it's not. Those questions refer to how to create an USB stick that can boot one or more ISO images on an UEFI environment. My question is how to create ISO images that, when flashed into an USB stick, are bootable only on UEFI.
– Luis Lavaire
Jan 18 at 4:28
Captcha does not let me post answers. So as comment: Debian does it for its ARM64 ISOs. See: wiki.debian.org/RepackBootableISO#arm64_release_9.4.0 You can avoid EFI image duplication by using -e '--interval:appended_partition_2:all::' instead of -e $file_path.
– Thomas Schmitt
Jan 18 at 6:15
Captcha does not let me post answers. So as comment: Debian does it for its ARM64 ISOs. See: wiki.debian.org/RepackBootableISO#arm64_release_9.4.0 You can avoid EFI image duplication by using -e '--interval:appended_partition_2:all::' instead of -e $file_path.
– Thomas Schmitt
Jan 18 at 6:15
|
show 5 more comments
1 Answer
1
active
oldest
votes
1
A good guide is this Debian web page.
An image that boots only on UEFI can be created with xorriso like this:
xorriso -as mkisofs
-iso-level 3
-r -V <ISO_LABEL>
-J -joliet-long
-append_partition 2 0xef <BOOT_IMG>
-partition_cyl_align all
-o <OUTPUT_IMAGE>
<ISO_DIRECTORY>
The UEFI_BOOT_IMAGE is an ESP ([U]EFI System Partition) image file. That means that it should be formatted as a FAT32 partition. You can generate it with:
BOOT_IMG_DATA=$(mktemp -d)
BOOT_IMG=$(mktemp -d)/efi.img
mkdir -p $(dirname $BOOT_IMG)
truncate -s 8M $BOOT_IMG
mkfs.vfat $BOOT_IMG
mount $BOOT_IMG $BOOT_IMG_DATA
mkdir -p $BOOT_IMG_DATA/efi/boot
grub-mkimage
-C xz
-O x86_64-efi
-p /boot/grub
-o $BOOT_IMG_DATA/efi/boot/bootx64.efi
boot linux search normal configfile
part_gpt btrfs ext2 fat iso9660 loopback
test keystatus gfxmenu regexp probe
efi_gop efi_uga all_video gfxterm font
echo read ls cat png jpeg halt reboot
umount $BOOT_IMG_DATA
rm -rf $BOOT_IMG_DATA
That will create the ESP image in $(mktemp -d)/efi.img, so you must replace the placeholder with the actual file path.
This answer was based on a coment by @ThomasSchmitt.
answered Jan 21 at 20:06
Luis LavaireLuis Lavaire
167
1
The option -e "--interval:appended_partition_2:all::" is quite new (2.5 years, xorriso-1.4.6). If you use it, then you do not need the file <BOOT_IMG> under the <ISO_DIRECTORY> and thus in the resulting ISO. This reduces the size of the ISO by a few MB. (Option -e announces the EFI System Partition to El Torito for booting from CD, DVD, or BD. If you do not need booting from optical media then you may omit options -e and -no-emul-boot completely.)
– Thomas Schmitt
Jan 22 at 12:31
1
After saving the few MB, consider to invest them into xorriso option -partition_offset "16". It will make the partition table more acceptable to partition editors by starting partition 1 at block 16*4=64 rather than at block 0. Further it will let programs like /sbin/isosize tell the size of the ISO image including the appended partition. (If the partition starts at block 0 then the size of the ISO has to stay within the range of partition 1.) The price is a second superblock and a second directory tree for partition 1. File data content blocks will be shared.
– Thomas Schmitt
Jan 22 at 12:40
1
Maybe my first comment is unclear in one aspect: You need file <BOOT_IMG> for option -append_partition. But it does not have to be stored underneath <ISO_DIRECTORY> if you point -e to the appended partition. Normally -e expects the path of a data file inside the emerging ISO filesystem. The original Debian method is older than xorriso-1.4.6 and causes the <BOOT_IMG> file to be in the image twice. Once as data file and once as appended data after the end of the filesystem range.
– Thomas Schmitt
Jan 23 at 15:08
Thanks, again, @ThomasSchmitt. Your comment was rather clear. I just finished trying the options you mentioned, and they worked very well. The image booted without issues. The only thing I noted is that when I used the flag-partition_offset 16, the output offdisk -l <OUTPUT_IMAGE>listed the first partition as an unknown filesystem type. When I didn't use it, it was listed as type Linux filesystem. But it was bootable on either case. Is this something that I should take into account?
– Luis Lavaire
Jan 23 at 17:22
Hm. Indeed with -partition_offset 16 the type produced by libisofs is 0xcd (a value once proposed by GRUB's developer V. Serbinenko) whereas with the default offset 0 it is type 0x83 ("Linux"). You may enforce type 0x83 of partition 1 by option -iso_mbr_part_type 0x83 (available since xorriso-1.4.8). Whether the type is significant depends on the interpreting program. See en.wikipedia.org/wiki/Partition_type#List_of_partition_IDs . Important is that only the EFI partition has type 0xef.
– Thomas Schmitt
Jan 23 at 18:36
|
show 1 more comment
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1110651%2fhow-to-produce-an-iso-image-that-boots-only-on-uefi%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
1
A good guide is this Debian web page.
An image that boots only on UEFI can be created with xorriso like this:
xorriso -as mkisofs
-iso-level 3
-r -V <ISO_LABEL>
-J -joliet-long
-append_partition 2 0xef <BOOT_IMG>
-partition_cyl_align all
-o <OUTPUT_IMAGE>
<ISO_DIRECTORY>
The UEFI_BOOT_IMAGE is an ESP ([U]EFI System Partition) image file. That means that it should be formatted as a FAT32 partition. You can generate it with:
BOOT_IMG_DATA=$(mktemp -d)
BOOT_IMG=$(mktemp -d)/efi.img
mkdir -p $(dirname $BOOT_IMG)
truncate -s 8M $BOOT_IMG
mkfs.vfat $BOOT_IMG
mount $BOOT_IMG $BOOT_IMG_DATA
mkdir -p $BOOT_IMG_DATA/efi/boot
grub-mkimage
-C xz
-O x86_64-efi
-p /boot/grub
-o $BOOT_IMG_DATA/efi/boot/bootx64.efi
boot linux search normal configfile
part_gpt btrfs ext2 fat iso9660 loopback
test keystatus gfxmenu regexp probe
efi_gop efi_uga all_video gfxterm font
echo read ls cat png jpeg halt reboot
umount $BOOT_IMG_DATA
rm -rf $BOOT_IMG_DATA
That will create the ESP image in $(mktemp -d)/efi.img, so you must replace the placeholder with the actual file path.
This answer was based on a coment by @ThomasSchmitt.
answered Jan 21 at 20:06
Luis LavaireLuis Lavaire
167
1
The option -e "--interval:appended_partition_2:all::" is quite new (2.5 years, xorriso-1.4.6). If you use it, then you do not need the file <BOOT_IMG> under the <ISO_DIRECTORY> and thus in the resulting ISO. This reduces the size of the ISO by a few MB. (Option -e announces the EFI System Partition to El Torito for booting from CD, DVD, or BD. If you do not need booting from optical media then you may omit options -e and -no-emul-boot completely.)
– Thomas Schmitt
Jan 22 at 12:31
1
After saving the few MB, consider to invest them into xorriso option -partition_offset "16". It will make the partition table more acceptable to partition editors by starting partition 1 at block 16*4=64 rather than at block 0. Further it will let programs like /sbin/isosize tell the size of the ISO image including the appended partition. (If the partition starts at block 0 then the size of the ISO has to stay within the range of partition 1.) The price is a second superblock and a second directory tree for partition 1. File data content blocks will be shared.
– Thomas Schmitt
Jan 22 at 12:40
1
Maybe my first comment is unclear in one aspect: You need file <BOOT_IMG> for option -append_partition. But it does not have to be stored underneath <ISO_DIRECTORY> if you point -e to the appended partition. Normally -e expects the path of a data file inside the emerging ISO filesystem. The original Debian method is older than xorriso-1.4.6 and causes the <BOOT_IMG> file to be in the image twice. Once as data file and once as appended data after the end of the filesystem range.
– Thomas Schmitt
Jan 23 at 15:08
Thanks, again, @ThomasSchmitt. Your comment was rather clear. I just finished trying the options you mentioned, and they worked very well. The image booted without issues. The only thing I noted is that when I used the flag-partition_offset 16, the output offdisk -l <OUTPUT_IMAGE>listed the first partition as an unknown filesystem type. When I didn't use it, it was listed as type Linux filesystem. But it was bootable on either case. Is this something that I should take into account?
– Luis Lavaire
Jan 23 at 17:22
Hm. Indeed with -partition_offset 16 the type produced by libisofs is 0xcd (a value once proposed by GRUB's developer V. Serbinenko) whereas with the default offset 0 it is type 0x83 ("Linux"). You may enforce type 0x83 of partition 1 by option -iso_mbr_part_type 0x83 (available since xorriso-1.4.8). Whether the type is significant depends on the interpreting program. See en.wikipedia.org/wiki/Partition_type#List_of_partition_IDs . Important is that only the EFI partition has type 0xef.
– Thomas Schmitt
Jan 23 at 18:36
|
show 1 more comment
1
A good guide is this Debian web page.
An image that boots only on UEFI can be created with xorriso like this:
xorriso -as mkisofs
-iso-level 3
-r -V <ISO_LABEL>
-J -joliet-long
-append_partition 2 0xef <BOOT_IMG>
-partition_cyl_align all
-o <OUTPUT_IMAGE>
<ISO_DIRECTORY>
The UEFI_BOOT_IMAGE is an ESP ([U]EFI System Partition) image file. That means that it should be formatted as a FAT32 partition. You can generate it with:
BOOT_IMG_DATA=$(mktemp -d)
BOOT_IMG=$(mktemp -d)/efi.img
mkdir -p $(dirname $BOOT_IMG)
truncate -s 8M $BOOT_IMG
mkfs.vfat $BOOT_IMG
mount $BOOT_IMG $BOOT_IMG_DATA
mkdir -p $BOOT_IMG_DATA/efi/boot
grub-mkimage
-C xz
-O x86_64-efi
-p /boot/grub
-o $BOOT_IMG_DATA/efi/boot/bootx64.efi
boot linux search normal configfile
part_gpt btrfs ext2 fat iso9660 loopback
test keystatus gfxmenu regexp probe
efi_gop efi_uga all_video gfxterm font
echo read ls cat png jpeg halt reboot
umount $BOOT_IMG_DATA
rm -rf $BOOT_IMG_DATA
That will create the ESP image in $(mktemp -d)/efi.img, so you must replace the placeholder with the actual file path.
This answer was based on a coment by @ThomasSchmitt.
answered Jan 21 at 20:06
Luis LavaireLuis Lavaire
167
1
The option -e "--interval:appended_partition_2:all::" is quite new (2.5 years, xorriso-1.4.6). If you use it, then you do not need the file <BOOT_IMG> under the <ISO_DIRECTORY> and thus in the resulting ISO. This reduces the size of the ISO by a few MB. (Option -e announces the EFI System Partition to El Torito for booting from CD, DVD, or BD. If you do not need booting from optical media then you may omit options -e and -no-emul-boot completely.)
– Thomas Schmitt
Jan 22 at 12:31
1
After saving the few MB, consider to invest them into xorriso option -partition_offset "16". It will make the partition table more acceptable to partition editors by starting partition 1 at block 16*4=64 rather than at block 0. Further it will let programs like /sbin/isosize tell the size of the ISO image including the appended partition. (If the partition starts at block 0 then the size of the ISO has to stay within the range of partition 1.) The price is a second superblock and a second directory tree for partition 1. File data content blocks will be shared.
– Thomas Schmitt
Jan 22 at 12:40
1
Maybe my first comment is unclear in one aspect: You need file <BOOT_IMG> for option -append_partition. But it does not have to be stored underneath <ISO_DIRECTORY> if you point -e to the appended partition. Normally -e expects the path of a data file inside the emerging ISO filesystem. The original Debian method is older than xorriso-1.4.6 and causes the <BOOT_IMG> file to be in the image twice. Once as data file and once as appended data after the end of the filesystem range.
– Thomas Schmitt
Jan 23 at 15:08
Thanks, again, @ThomasSchmitt. Your comment was rather clear. I just finished trying the options you mentioned, and they worked very well. The image booted without issues. The only thing I noted is that when I used the flag-partition_offset 16, the output offdisk -l <OUTPUT_IMAGE>listed the first partition as an unknown filesystem type. When I didn't use it, it was listed as type Linux filesystem. But it was bootable on either case. Is this something that I should take into account?
– Luis Lavaire
Jan 23 at 17:22
Hm. Indeed with -partition_offset 16 the type produced by libisofs is 0xcd (a value once proposed by GRUB's developer V. Serbinenko) whereas with the default offset 0 it is type 0x83 ("Linux"). You may enforce type 0x83 of partition 1 by option -iso_mbr_part_type 0x83 (available since xorriso-1.4.8). Whether the type is significant depends on the interpreting program. See en.wikipedia.org/wiki/Partition_type#List_of_partition_IDs . Important is that only the EFI partition has type 0xef.
– Thomas Schmitt
Jan 23 at 18:36
|
show 1 more comment
1
1
1
A good guide is this Debian web page.
An image that boots only on UEFI can be created with xorriso like this:
xorriso -as mkisofs
-iso-level 3
-r -V <ISO_LABEL>
-J -joliet-long
-append_partition 2 0xef <BOOT_IMG>
-partition_cyl_align all
-o <OUTPUT_IMAGE>
<ISO_DIRECTORY>
The UEFI_BOOT_IMAGE is an ESP ([U]EFI System Partition) image file. That means that it should be formatted as a FAT32 partition. You can generate it with:
BOOT_IMG_DATA=$(mktemp -d)
BOOT_IMG=$(mktemp -d)/efi.img
mkdir -p $(dirname $BOOT_IMG)
truncate -s 8M $BOOT_IMG
mkfs.vfat $BOOT_IMG
mount $BOOT_IMG $BOOT_IMG_DATA
mkdir -p $BOOT_IMG_DATA/efi/boot
grub-mkimage
-C xz
-O x86_64-efi
-p /boot/grub
-o $BOOT_IMG_DATA/efi/boot/bootx64.efi
boot linux search normal configfile
part_gpt btrfs ext2 fat iso9660 loopback
test keystatus gfxmenu regexp probe
efi_gop efi_uga all_video gfxterm font
echo read ls cat png jpeg halt reboot
umount $BOOT_IMG_DATA
rm -rf $BOOT_IMG_DATA
That will create the ESP image in $(mktemp -d)/efi.img, so you must replace the placeholder with the actual file path.
This answer was based on a coment by @ThomasSchmitt.
answered Jan 21 at 20:06
Luis LavaireLuis Lavaire
167
A good guide is this Debian web page.
An image that boots only on UEFI can be created with xorriso like this:
xorriso -as mkisofs
-iso-level 3
-r -V <ISO_LABEL>
-J -joliet-long
-append_partition 2 0xef <BOOT_IMG>
-partition_cyl_align all
-o <OUTPUT_IMAGE>
<ISO_DIRECTORY>
The UEFI_BOOT_IMAGE is an ESP ([U]EFI System Partition) image file. That means that it should be formatted as a FAT32 partition. You can generate it with:
BOOT_IMG_DATA=$(mktemp -d)
BOOT_IMG=$(mktemp -d)/efi.img
mkdir -p $(dirname $BOOT_IMG)
truncate -s 8M $BOOT_IMG
mkfs.vfat $BOOT_IMG
mount $BOOT_IMG $BOOT_IMG_DATA
mkdir -p $BOOT_IMG_DATA/efi/boot
grub-mkimage
-C xz
-O x86_64-efi
-p /boot/grub
-o $BOOT_IMG_DATA/efi/boot/bootx64.efi
boot linux search normal configfile
part_gpt btrfs ext2 fat iso9660 loopback
test keystatus gfxmenu regexp probe
efi_gop efi_uga all_video gfxterm font
echo read ls cat png jpeg halt reboot
umount $BOOT_IMG_DATA
rm -rf $BOOT_IMG_DATA
That will create the ESP image in $(mktemp -d)/efi.img, so you must replace the placeholder with the actual file path.
This answer was based on a coment by @ThomasSchmitt.
answered Jan 21 at 20:06
Luis LavaireLuis Lavaire
167
edited Jan 25 at 22:25
answered Jan 21 at 20:06
Luis LavaireLuis Lavaire
167
answered Jan 21 at 20:06
Luis LavaireLuis Lavaire
167
answered Jan 21 at 20:06
Luis LavaireLuis Lavaire
167
167
1
The option -e "--interval:appended_partition_2:all::" is quite new (2.5 years, xorriso-1.4.6). If you use it, then you do not need the file <BOOT_IMG> under the <ISO_DIRECTORY> and thus in the resulting ISO. This reduces the size of the ISO by a few MB. (Option -e announces the EFI System Partition to El Torito for booting from CD, DVD, or BD. If you do not need booting from optical media then you may omit options -e and -no-emul-boot completely.)
– Thomas Schmitt
Jan 22 at 12:31
1
After saving the few MB, consider to invest them into xorriso option -partition_offset "16". It will make the partition table more acceptable to partition editors by starting partition 1 at block 16*4=64 rather than at block 0. Further it will let programs like /sbin/isosize tell the size of the ISO image including the appended partition. (If the partition starts at block 0 then the size of the ISO has to stay within the range of partition 1.) The price is a second superblock and a second directory tree for partition 1. File data content blocks will be shared.
– Thomas Schmitt
Jan 22 at 12:40
1
Maybe my first comment is unclear in one aspect: You need file <BOOT_IMG> for option -append_partition. But it does not have to be stored underneath <ISO_DIRECTORY> if you point -e to the appended partition. Normally -e expects the path of a data file inside the emerging ISO filesystem. The original Debian method is older than xorriso-1.4.6 and causes the <BOOT_IMG> file to be in the image twice. Once as data file and once as appended data after the end of the filesystem range.
– Thomas Schmitt
Jan 23 at 15:08
Thanks, again, @ThomasSchmitt. Your comment was rather clear. I just finished trying the options you mentioned, and they worked very well. The image booted without issues. The only thing I noted is that when I used the flag-partition_offset 16, the output offdisk -l <OUTPUT_IMAGE>listed the first partition as an unknown filesystem type. When I didn't use it, it was listed as type Linux filesystem. But it was bootable on either case. Is this something that I should take into account?
– Luis Lavaire
Jan 23 at 17:22
Hm. Indeed with -partition_offset 16 the type produced by libisofs is 0xcd (a value once proposed by GRUB's developer V. Serbinenko) whereas with the default offset 0 it is type 0x83 ("Linux"). You may enforce type 0x83 of partition 1 by option -iso_mbr_part_type 0x83 (available since xorriso-1.4.8). Whether the type is significant depends on the interpreting program. See en.wikipedia.org/wiki/Partition_type#List_of_partition_IDs . Important is that only the EFI partition has type 0xef.
– Thomas Schmitt
Jan 23 at 18:36
|
show 1 more comment
1
The option -e "--interval:appended_partition_2:all::" is quite new (2.5 years, xorriso-1.4.6). If you use it, then you do not need the file <BOOT_IMG> under the <ISO_DIRECTORY> and thus in the resulting ISO. This reduces the size of the ISO by a few MB. (Option -e announces the EFI System Partition to El Torito for booting from CD, DVD, or BD. If you do not need booting from optical media then you may omit options -e and -no-emul-boot completely.)
– Thomas Schmitt
Jan 22 at 12:31
1
After saving the few MB, consider to invest them into xorriso option -partition_offset "16". It will make the partition table more acceptable to partition editors by starting partition 1 at block 16*4=64 rather than at block 0. Further it will let programs like /sbin/isosize tell the size of the ISO image including the appended partition. (If the partition starts at block 0 then the size of the ISO has to stay within the range of partition 1.) The price is a second superblock and a second directory tree for partition 1. File data content blocks will be shared.
– Thomas Schmitt
Jan 22 at 12:40
1
Maybe my first comment is unclear in one aspect: You need file <BOOT_IMG> for option -append_partition. But it does not have to be stored underneath <ISO_DIRECTORY> if you point -e to the appended partition. Normally -e expects the path of a data file inside the emerging ISO filesystem. The original Debian method is older than xorriso-1.4.6 and causes the <BOOT_IMG> file to be in the image twice. Once as data file and once as appended data after the end of the filesystem range.
– Thomas Schmitt
Jan 23 at 15:08
Thanks, again, @ThomasSchmitt. Your comment was rather clear. I just finished trying the options you mentioned, and they worked very well. The image booted without issues. The only thing I noted is that when I used the flag-partition_offset 16, the output offdisk -l <OUTPUT_IMAGE>listed the first partition as an unknown filesystem type. When I didn't use it, it was listed as type Linux filesystem. But it was bootable on either case. Is this something that I should take into account?
– Luis Lavaire
Jan 23 at 17:22
Hm. Indeed with -partition_offset 16 the type produced by libisofs is 0xcd (a value once proposed by GRUB's developer V. Serbinenko) whereas with the default offset 0 it is type 0x83 ("Linux"). You may enforce type 0x83 of partition 1 by option -iso_mbr_part_type 0x83 (available since xorriso-1.4.8). Whether the type is significant depends on the interpreting program. See en.wikipedia.org/wiki/Partition_type#List_of_partition_IDs . Important is that only the EFI partition has type 0xef.
– Thomas Schmitt
Jan 23 at 18:36
1
1
The option -e "--interval:appended_partition_2:all::" is quite new (2.5 years, xorriso-1.4.6). If you use it, then you do not need the file <BOOT_IMG> under the <ISO_DIRECTORY> and thus in the resulting ISO. This reduces the size of the ISO by a few MB. (Option -e announces the EFI System Partition to El Torito for booting from CD, DVD, or BD. If you do not need booting from optical media then you may omit options -e and -no-emul-boot completely.)
– Thomas Schmitt
Jan 22 at 12:31
The option -e "--interval:appended_partition_2:all::" is quite new (2.5 years, xorriso-1.4.6). If you use it, then you do not need the file <BOOT_IMG> under the <ISO_DIRECTORY> and thus in the resulting ISO. This reduces the size of the ISO by a few MB. (Option -e announces the EFI System Partition to El Torito for booting from CD, DVD, or BD. If you do not need booting from optical media then you may omit options -e and -no-emul-boot completely.)
– Thomas Schmitt
Jan 22 at 12:31
1
1
After saving the few MB, consider to invest them into xorriso option -partition_offset "16". It will make the partition table more acceptable to partition editors by starting partition 1 at block 16*4=64 rather than at block 0. Further it will let programs like /sbin/isosize tell the size of the ISO image including the appended partition. (If the partition starts at block 0 then the size of the ISO has to stay within the range of partition 1.) The price is a second superblock and a second directory tree for partition 1. File data content blocks will be shared.
– Thomas Schmitt
Jan 22 at 12:40
After saving the few MB, consider to invest them into xorriso option -partition_offset "16". It will make the partition table more acceptable to partition editors by starting partition 1 at block 16*4=64 rather than at block 0. Further it will let programs like /sbin/isosize tell the size of the ISO image including the appended partition. (If the partition starts at block 0 then the size of the ISO has to stay within the range of partition 1.) The price is a second superblock and a second directory tree for partition 1. File data content blocks will be shared.
– Thomas Schmitt
Jan 22 at 12:40
1
1
Maybe my first comment is unclear in one aspect: You need file <BOOT_IMG> for option -append_partition. But it does not have to be stored underneath <ISO_DIRECTORY> if you point -e to the appended partition. Normally -e expects the path of a data file inside the emerging ISO filesystem. The original Debian method is older than xorriso-1.4.6 and causes the <BOOT_IMG> file to be in the image twice. Once as data file and once as appended data after the end of the filesystem range.
– Thomas Schmitt
Jan 23 at 15:08
Maybe my first comment is unclear in one aspect: You need file <BOOT_IMG> for option -append_partition. But it does not have to be stored underneath <ISO_DIRECTORY> if you point -e to the appended partition. Normally -e expects the path of a data file inside the emerging ISO filesystem. The original Debian method is older than xorriso-1.4.6 and causes the <BOOT_IMG> file to be in the image twice. Once as data file and once as appended data after the end of the filesystem range.
– Thomas Schmitt
Jan 23 at 15:08
Thanks, again, @ThomasSchmitt. Your comment was rather clear. I just finished trying the options you mentioned, and they worked very well. The image booted without issues. The only thing I noted is that when I used the flag
-partition_offset 16, the output of fdisk -l <OUTPUT_IMAGE> listed the first partition as an unknown filesystem type. When I didn't use it, it was listed as type Linux filesystem. But it was bootable on either case. Is this something that I should take into account?– Luis Lavaire
Jan 23 at 17:22
Thanks, again, @ThomasSchmitt. Your comment was rather clear. I just finished trying the options you mentioned, and they worked very well. The image booted without issues. The only thing I noted is that when I used the flag
-partition_offset 16, the output of fdisk -l <OUTPUT_IMAGE> listed the first partition as an unknown filesystem type. When I didn't use it, it was listed as type Linux filesystem. But it was bootable on either case. Is this something that I should take into account?– Luis Lavaire
Jan 23 at 17:22
Hm. Indeed with -partition_offset 16 the type produced by libisofs is 0xcd (a value once proposed by GRUB's developer V. Serbinenko) whereas with the default offset 0 it is type 0x83 ("Linux"). You may enforce type 0x83 of partition 1 by option -iso_mbr_part_type 0x83 (available since xorriso-1.4.8). Whether the type is significant depends on the interpreting program. See en.wikipedia.org/wiki/Partition_type#List_of_partition_IDs . Important is that only the EFI partition has type 0xef.
– Thomas Schmitt
Jan 23 at 18:36
Hm. Indeed with -partition_offset 16 the type produced by libisofs is 0xcd (a value once proposed by GRUB's developer V. Serbinenko) whereas with the default offset 0 it is type 0x83 ("Linux"). You may enforce type 0x83 of partition 1 by option -iso_mbr_part_type 0x83 (available since xorriso-1.4.8). Whether the type is significant depends on the interpreting program. See en.wikipedia.org/wiki/Partition_type#List_of_partition_IDs . Important is that only the EFI partition has type 0xef.
– Thomas Schmitt
Jan 23 at 18:36
|
show 1 more comment
draft saved
draft discarded
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1110651%2fhow-to-produce-an-iso-image-that-boots-only-on-uefi%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
There are a few discussion of this here already. Maybe share some of your research? What other Q&A have you visited?
– jdv
Jan 17 at 20:34
2
Duplicate of : UEFI only USB key, just extract ISO ( 7 zip or similar) to FAT32 formatted flash drive partition & set boot flag. askubuntu.com/questions/395879/…
– oldfred
Jan 17 at 20:37
4
Possible duplicate of How to create UEFI-only bootable USB live media?
– user535733
Jan 17 at 22:50
No, it's not. Those questions refer to how to create an USB stick that can boot one or more ISO images on an UEFI environment. My question is how to create ISO images that, when flashed into an USB stick, are bootable only on UEFI.
– Luis Lavaire
Jan 18 at 4:28
Captcha does not let me post answers. So as comment: Debian does it for its ARM64 ISOs. See: wiki.debian.org/RepackBootableISO#arm64_release_9.4.0 You can avoid EFI image duplication by using -e '--interval:appended_partition_2:all::' instead of -e $file_path.
– Thomas Schmitt
Jan 18 at 6:15