Hi, Sreyan Chakravarty wrote here: > Its stuck at the bootmenu. and at syslinux@xxxxxxxxxxxx: > Unfortunately when I boot and press enter nothing happens. So i assume you see an ISOLINUX menu with the labels you expect from your isolinux.cfg file. (If not, then this would make much more sense to me, though.) Since i assume that your "." directory was the mounted original ISO or a copy of the mounted file tree of that ISO, the difference can only be in the non-file data blocks of the ISO. > genisoimage ... -b isolinux/isolinux.bin -c isolinux/boot.cat > -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot > -e images/efiboot.img -no-emul-boot This creates boot records for booting via PC-BIOS and EFI from DVD, but not from USB stick or hard disk. A run of program isohybrid --uefi would equip the ISO by MBR code and GPT partition table which marks efiboot.img as EFI System Partition. Whatever it should boot from (virtual) DVD via PC-BIOS compatible firmware. And if you see an ISOLINUX menu, then it booted indeed. ------------------------------------------------------------------------- > If anyone knows how the official images are compiled please let me know. It is probably my software which packed up as ISO what Fedora's software has prepared on hard disk. In the past i encountered livecd-tools as producer of Fedora images. livecd-tools uses the mkisofs emulation mode of xorriso by the link name "xorrisofs" in program https://github.com/livecd-tools/livecd-tools/blob/master/imgcreate/live.py The xorrisofs arguments in live.py would match what can be seen in the ISO. The run: orig=Fedora-Workstation-Live-x86_64-31-1.9.iso xorriso -indev "$orig" -report_el_torito plain -report_system_area plain shows that it has equipment for booting via PC-BIOS or EFI from DVD or from USB-stick: Preparer Id : XORRISO-1.5.0 2018.09.15.133001, LIBISOBURN-1.5.0, LIBISOFS-1.5.0, LIBBURN-1.5.0 ... El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x0000 0x00 4 16852 El Torito boot img : 2 UEFI y none 0x0000 0x00 21716 43 El Torito boot img : 3 UEFI y none 0x0000 0x00 45520 5472 El Torito img path : 1 /isolinux/isolinux.bin El Torito img opts : 1 boot-info-table isohybrid-suitable El Torito img path : 2 /images/efiboot.img El Torito img path : 3 /images/macboot.img ... System area summary: MBR isohybrid cyl-align-off GPT ... MBR partition table: N Status Type Start Blocks MBR partition : 1 0x80 0x00 0 3768320 MBR partition : 2 0x00 0xef 172 21716 MBR partition : 3 0x00 0x00 21888 45520 MBR partition path : 2 /images/efiboot.img MBR partition path : 3 /images/macboot.img (Only of interest if the machine is an old Mac: The file /images/macboot.img is advertised by El Torito and MBR partition table, but not by an Apple Partition Map, as was done in Fedora-Workstation-Live-x86_64-29-1.2.iso. This advertising would be created by xorrisofs option -isohybrid-apm-hfsplus which does the same as isohybrid's option --mac.) Let's assume, that livecd-tools would not be the right guess and thus could not tell the used xorrisofs arguments. xorriso can guess the boot related options for a replaying xorrisofs run from the ISO image: xorriso -indev "$orig" -report_el_torito as_mkisofs as -V 'Fedora-WS-Live-31-1-9' --modification-date='2019102323212900' -isohybrid-mbr --interval:local_fs:0s-15s:zero_mbrpt,zero_gpt:'Fedora-Workstation-Live-x86_64-31-1.9.iso' -partition_cyl_align off -partition_offset 0 --mbr-force-bootable -iso_mbr_part_type 0x00 -c '/isolinux/boot.cat' -b '/isolinux/isolinux.bin' -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot -e '/images/efiboot.img' -no-emul-boot -boot-load-size 21716 -isohybrid-gpt-basdat -eltorito-alt-boot -e '/images/macboot.img' -no-emul-boot -boot-load-size 45520 -isohybrid-gpt-hfsplus Some of them are automatic consequences of the others and may have been omitted when the ISO was made: -partition_cyl_align off -partition_offset 0 --mbr-force-bootable -iso_mbr_part_type 0x00 Whether -V 'Fedora-WS-Live-31-1-9' --modification-date='2019102323212900' are significant depends on the software in the ISO. The isolinux.cfg refers to the -V text. grub-mrescue refers to the date as UUID. The option -isohybrid-mbr gets as parameter a disk file path with an isohybrid MBR template (isohdpfx.bin) or the lengthy --interval:... string which tells it to pick a template from the original ISO image's start. One could harvest it manually and submit its path as argument: dd if=Fedora-Workstation-Live-x86_64-29-1.2.iso bs=1 count=446 \ of=/tmp/isohdpfx.bin xorrisofs \ ... -isohybrid-mbr /tmp/isohdpfx.bin \ ... (As said, one might want to add option -isohybrid-apm-hfsplus to the option -isohybrid-gpt-hfsplus of macboot.img.) ------------------------------------------------------------------------- But this all does not explain why ISOLINUX could get stuck in its menu. I am not an expert for bootloaders or initrds, but rather their neighbor. So i cannot even guess what goes wrong. Have a nice day :) Thomas _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
