custom pve iso
- Thread starter tomcat
- Start date
Hi,
thanks to proxmox for flying xorriso.
You may mount the ISO via a loop device (or as virtual CD-ROM)
and let xorriso pack up the mounted directory tree at the
root of the new ISO, overwrite the kernel by a subsequent
pathspec, and apply the necessary options for booting.
The demanding part is about the boot options.
You will have to analyze the boot equipment of the original
image. Released xorriso-1.3.8 can do:
and reveils that the image has the full {BIOS, EFI, Mac} x {CD, HD}
equipment of GRUB2:
The APM/HFS+ stuff is a speciality of grub-mkrescue which uses
xorriso -as mkisofs option -hfsplus. By a lengthy xorriso -find
command i can see that the following file is blessed in HFS+ as
"Intel Boot File":
/System/Library/CoreServices/boot.efi
But actually i am unable to test APM/HFS+. Most of this was
contributed to xorriso by Vladimir Serbinenko of GRUB2.
Let's assume you don't want to boot the ISO on a HFS+ Mac,
but only prepare for BIOS and EFI:
The used options are explained in
http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
When presented on an USB stick, the resulting repacked.iso
booted my BIOS equipped test machine up to a bright
screen which offered me to install Proxmox or to test
memory.
I did not replace the kernel when repacking.
There remains the problem that the file repacked.iso is
50 percent larger than the original ISO. tar produces a
similarly large result. This is due to zisofs compression
applied to 11787 of the 14170 data files in the original
image.
If ISO size matters, then one could apply zisofs compression
to those data files which will surely be opened only via
a zisofs enabled Linux kernel. GRUB2 and early boot stages
of proxmox might not be able to deal with compressed file
content.
Have a nice day
Thomas
thanks to proxmox for flying xorriso.
You may mount the ISO via a loop device (or as virtual CD-ROM)
and let xorriso pack up the mounted directory tree at the
root of the new ISO, overwrite the kernel by a subsequent
pathspec, and apply the necessary options for booting.
The demanding part is about the boot options.
You will have to analyze the boot equipment of the original
image. Released xorriso-1.3.8 can do:
Code:
xorriso -indev proxmox-ve_3.4-3f2d890e-1.iso \
-toc \
-pvd_info \
-report_el_torito plain \
-report_system_area plainequipment of GRUB2:
Code:
...
Volume Id : PVE
...
Modif. Time : 2015021906085500
...
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x0000 0x00 4 35033
El Torito boot img : 2 UEFI y none 0x0000 0x00 5760 6790
El Torito img path : 1 /boot/grub/i386-pc/eltorito.img
El Torito img opts : 1 boot-info-table grub2-boot-info
El Torito img path : 2 /efi.img
...
System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off GPT APM
...
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x00 0xee 1 1298567
...
GPT partname local : 2 EFI boot partition
...
GPT partition path : 2 /efi.img
...
APM partition name : 2 HFSPLUS_Hybrid
APM partition type : 2 Apple_HFS
APM start and size : 2 8230 316250
...xorriso -as mkisofs option -hfsplus. By a lengthy xorriso -find
command i can see that the following file is blessed in HFS+ as
"Intel Boot File":
/System/Library/CoreServices/boot.efi
But actually i am unable to test APM/HFS+. Most of this was
contributed to xorriso by Vladimir Serbinenko of GRUB2.
Let's assume you don't want to boot the ISO on a HFS+ Mac,
but only prepare for BIOS and EFI:
Code:
# Need an MBR. After inspection of the first 32 KB by od -c
# i am sure that there is no code outside the MBR and the
# partition tables. So i just cout out the first 512 bytes.
dd if=proxmox-ve_3.4-3f2d890e-1.iso bs=512 count=1 of=proxmox.mbr
# Mount the original image in order to copy its directory tree
mount -o loop proxmox-ve_3.4-3f2d890e-1.iso /mnt/iso
# Prepare the paths for kernel swap. The new kernel gets the old name
# in the hope that this suffices to integrate it into the old system.
my_new_kernel=...disk.path.to.new.kernel...
old_kernel=/boot/vmlinuz-2.6.32-37-pve
# Now repack while overwriting the kernel from /mnt/iso by the new one.
# Keep volume id and modification time. The booting system might
# search for them among disk identifiers.
xorriso -as mkisofs \
-o repacked.iso \
-r -V 'PVE' \
--modification-date=2015021906085500 \
--grub2-mbr proxmox.mbr \
--protective-msdos-label \
-efi-boot-part --efi-boot-image \
-c '/boot/boot.cat' \
-b '/boot/grub/i386-pc/eltorito.img' \
-no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info \
-eltorito-alt-boot \
-e '/efi.img' -no-emul-boot \
/mnt/iso \
-graft-points "$old_kernel"="$my_new_kernel"http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
When presented on an USB stick, the resulting repacked.iso
booted my BIOS equipped test machine up to a bright
screen which offered me to install Proxmox or to test
memory.
I did not replace the kernel when repacking.
There remains the problem that the file repacked.iso is
50 percent larger than the original ISO. tar produces a
similarly large result. This is due to zisofs compression
applied to 11787 of the 14170 data files in the original
image.
If ISO size matters, then one could apply zisofs compression
to those data files which will surely be opened only via
a zisofs enabled Linux kernel. GRUB2 and early boot stages
of proxmox might not be able to deal with compressed file
content.
Have a nice day
Thomas
Last edited: