I am unable to boot the custom ISO I have created.
I have just created a Custom ISO from the Fedora Live ISO using the following command:
genisoimage -U -r -v -T -J -joliet-long -V "Fedora-WS-Live-31-1-9" -volset "Fedora-WS-Live-31-1-9" -A "CDLABEL=Fedora-WS-Live-31-1-9" -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 -o ../Fedora_Custom.iso .
But I can't for the life of me figure out why I can't get the Live ISO to boot. Its stuck at the bootmenu.
This is the directory structure for my custom ISO:
[sreyan@localhost Fedora_ISO]$ tree . . ├── anaconda-ks.cfg ├── EFI │ └── BOOT │ ├── BOOT.conf │ ├── BOOTIA32.EFI │ ├── BOOTX64.EFI │ ├── fonts │ │ └── unicode.pf2 │ ├── grub.cfg │ ├── grubia32.efi │ ├── grubx64.efi │ ├── mmia32.efi │ └── mmx64.efi ├── images │ ├── efiboot.img │ ├── macboot.img │ └── pxeboot │ ├── initrd.img │ └── vmlinuz ├── isolinux │ ├── boot.cat │ ├── boot.msg │ ├── grub.conf │ ├── initrd.img │ ├── isolinux.bin │ ├── isolinux.cfg │ ├── ldlinux.c32 │ ├── libcom32.c32 │ ├── libutil.c32 │ ├── memtest │ ├── splash.png │ ├── vesamenu.c32 │ └── vmlinuz └── LiveOS └── squashfs.img
7 directories, 28 files
And this is for the original:
[sreyan@localhost Fedora-WS-Live-31-1-9]$ tree . . ├── EFI │ └── BOOT │ ├── BOOT.conf │ ├── BOOTIA32.EFI │ ├── BOOTX64.EFI │ ├── fonts │ │ └── unicode.pf2 │ ├── grub.cfg │ ├── grubia32.efi │ ├── grubx64.efi │ ├── mmia32.efi │ └── mmx64.efi ├── images │ ├── efiboot.img │ ├── macboot.img │ └── pxeboot │ ├── initrd.img │ └── vmlinuz ├── isolinux │ ├── boot.cat │ ├── boot.msg │ ├── grub.conf │ ├── initrd.img │ ├── isolinux.bin │ ├── isolinux.cfg │ ├── ldlinux.c32 │ ├── libcom32.c32 │ ├── libutil.c32 │ ├── memtest │ ├── splash.png │ ├── vesamenu.c32 │ └── vmlinuz └── LiveOS └── squashfs.img
7 directories, 27 files
If anyone knows how the official images are compiled please let me know.
On Tue, Apr 7, 2020 at 5:23 PM Sreyan Chakravarty sreyan32@gmail.com wrote:
I am unable to boot the custom ISO I have created.
I have just created a Custom ISO from the Fedora Live ISO using the following command:
genisoimage -U -r -v -T -J -joliet-long -V "Fedora-WS-Live-31-1-9" -volset "Fedora-WS-Live-31-1-9" -A "CDLABEL=Fedora-WS-Live-31-1-9" -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 -o ../Fedora_Custom.iso .
But I can't for the life of me figure out why I can't get the Live ISO to boot. Its stuck at the bootmenu.
This is the directory structure for my custom ISO:
[sreyan@localhost Fedora_ISO]$ tree . . ├── anaconda-ks.cfg ├── EFI │ └── BOOT │ ├── BOOT.conf │ ├── BOOTIA32.EFI │ ├── BOOTX64.EFI │ ├── fonts │ │ └── unicode.pf2 │ ├── grub.cfg │ ├── grubia32.efi │ ├── grubx64.efi │ ├── mmia32.efi │ └── mmx64.efi ├── images │ ├── efiboot.img │ ├── macboot.img │ └── pxeboot │ ├── initrd.img │ └── vmlinuz ├── isolinux │ ├── boot.cat │ ├── boot.msg │ ├── grub.conf │ ├── initrd.img │ ├── isolinux.bin │ ├── isolinux.cfg │ ├── ldlinux.c32 │ ├── libcom32.c32 │ ├── libutil.c32 │ ├── memtest │ ├── splash.png │ ├── vesamenu.c32 │ └── vmlinuz └── LiveOS └── squashfs.img
7 directories, 28 files
And this is for the original:
[sreyan@localhost Fedora-WS-Live-31-1-9]$ tree . . ├── EFI │ └── BOOT │ ├── BOOT.conf │ ├── BOOTIA32.EFI │ ├── BOOTX64.EFI │ ├── fonts │ │ └── unicode.pf2 │ ├── grub.cfg │ ├── grubia32.efi │ ├── grubx64.efi │ ├── mmia32.efi │ └── mmx64.efi ├── images │ ├── efiboot.img │ ├── macboot.img │ └── pxeboot │ ├── initrd.img │ └── vmlinuz ├── isolinux │ ├── boot.cat │ ├── boot.msg │ ├── grub.conf │ ├── initrd.img │ ├── isolinux.bin │ ├── isolinux.cfg │ ├── ldlinux.c32 │ ├── libcom32.c32 │ ├── libutil.c32 │ ├── memtest │ ├── splash.png │ ├── vesamenu.c32 │ └── vmlinuz └── LiveOS └── squashfs.img
7 directories, 27 files
As you can see there is no difference except for the Kickstart file which I am not even using in isolinux.cfg
This is the output of isolinux.cfg:
default vesamenu.c32 timeout 600
display boot.msg
# Clear the screen when exiting the menu, instead of leaving the menu displayed. # For vesamenu, this means the graphical background is still displayed without # the menu itself for as long as the screen remains in graphics mode. menu clear menu background splash.png menu title Fedora-Workstation-Live 31 menu vshift 8 menu rows 18 menu margin 8 #menu hidden menu helpmsgrow 15 menu tabmsgrow 13
# Border Area menu color border * #00000000 #00000000 none
# Selected item menu color sel 0 #ffffffff #00000000 none
# Title bar menu color title 0 #ff7ba3d0 #00000000 none
# Press [Tab] message menu color tabmsg 0 #ff3a6496 #00000000 none
# Unselected menu item menu color unsel 0 #84b8ffff #00000000 none
# Selected hotkey menu color hotsel 0 #84b8ffff #00000000 none
# Unselected hotkey menu color hotkey 0 #ffffffff #00000000 none
# Help text menu color help 0 #ffffffff #00000000 none
# A scrollbar of some type? Not sure. menu color scrollbar 0 #ffffffff #ff355594 none
# Timeout msg menu color timeout 0 #ffffffff #00000000 none menu color timeout_msg 0 #ffffffff #00000000 none
# Command prompt text menu color cmdmark 0 #84b8ffff #00000000 none menu color cmdline 0 #ffffffff #00000000 none
# Do not display the actual menu unless the user presses a key. All that is displayed is a timeout message.
menu tabmsg Press Tab for full configuration options on menu items.
menu separator # insert an empty line menu separator # insert an empty line
label linux menu label ^Start Fedora-Workstation-Live 31 kernel vmlinuz append initrd=initrd.img root=live:CDLABEL=Fedora-WS-Live-31-1-9 rd.live.image quiet
label check menu label Test this ^media & start Fedora-Workstation-Live 31 menu default kernel vmlinuz append initrd=initrd.img root=live:CDLABEL=Fedora-WS-Live-31-1-9 rd.live.image rd.live.check quiet
menu separator # insert an empty line
# utilities submenu menu begin ^Troubleshooting menu title Troubleshooting
label vesa menu indent count 5 menu label Start Fedora-Workstation-Live 31 in ^basic graphics mode text help Try this option out if you're having trouble starting Fedora-Workstation-Live 31. endtext kernel vmlinuz append initrd=initrd.img root=live:CDLABEL=Fedora-WS-Live-31-1-9 rd.live.image nomodeset quiet
label memtest menu label Run a ^memory test text help If your system is having issues, a problem with your system's memory may be the cause. Use this utility to see if the memory is working correctly. endtext kernel memtest
menu separator # insert an empty line
label local menu label Boot from ^local drive localboot 0xffff
menu separator # insert an empty line menu separator # insert an empty line
label returntomain menu label Return to ^main menu menu exit
menu end
This is the same as the original ISO, there is no difference.
If there is no difference why am I unable to boot into Fedora.
These are the command line params from isolinux in both mine and original ISO.
Mine: https://imgur.com/a/iV5SlW5 Original: https://imgur.com/a/6sfmiJr
For me I am unable to progress any further than the boot screen.
Where am I going wrong ?
Regards, Sreyan Chakravarty
Hi,
Sreyan Chakravarty wrote here:
Its stuck at the bootmenu.
and at syslinux@syslinux.org:
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
Hi, 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.
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.
Wow, you have given me a lot of information, most of which i am having trouble understanding because it way too advanced.
So basically what you are saying is my image given the parameters is not bootable from USB, but is bootable from DVD/CD. But here is the problem, the ISO booted and displayed all the memory options. So something weird is happening there.
I have mailed the guys on the ISOLINUX mailing list but I will probably not get a reply.
Whatever it should boot from (virtual) DVD via PC-BIOS compatible firmware. And if you see an ISOLINUX menu, then it booted indeed.
Yeah this is the weird part.
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
I could not understand what all this is. What I could make out was that the livecd-tools for Fedora itself make use of a genisoimage like program called xorriso. The documentation is so complicated I could not figure out how to use it.
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
I could not understand these commands at all. If its alright with you, would you mind adding some more details ?
-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
I could not find these options listed in the xorriso man page so I don't understand what you are referring to.
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.
The most important question I would ask you is:
If someone asked you to create a custom Fedora ISO that you could use in VirtualBox/DVD/USB, what would you do ?
Please note, I mean "custom" as in it should contain some extra files that are not part of the stock ISO. For example, in this case it is my Kickstart file.
What would you do ?
Thanks again.
Regards, Sreyan Chakravarty
Hi,
Sreyan Chakravarty wrote:
If someone asked you to create a custom Fedora ISO that you could use in VirtualBox/DVD/USB, what would you do ?
(As first i'd try what you did: Build a new ISO from the mounted original. Then i'd try whether the original works in the test situation. Then i'd invest an unpredictable amount of time digging for reasons why my ISO does not work while the original works.)
Then i'd add the file by multi-session to a copy of the original ISO
cp Fedora-Workstation-Live-x86_64-31-1.9.iso test.iso
file_or_tree_on_disk="$HOME"/my_file path_in_iso=/my_file
xorriso -dev test.iso \ -boot_image any keep \ -map "$file_or_tree_on_disk" "$path_in_iso"
(These xorriso commands are documented in man xorriso, as they are part of the native non-emulated command mode. See below for your question about the emulated options.)
Afterwards test.iso should contain the same files as the original ISO plus the file or tree given by "$HOME"/my_file as file or tree with the path /my_file. The boot equipment is supposed to stay unchanged.
The resulting ISO will grow by the size of the whole ISO directory tree and the size of the data files which get added.
Of course any distro can impose arbitrary demands on how a file in an ISO has to be announced in some list file in the ISO, or equipped with some crytographic signature. A few plain data files and directories, which have no role in the official boot process, should not demand much announcement ... i hope.
---------------------------------------------------------------------------
But here is the problem, the ISO booted and displayed all the memory options. So something weird is happening there.
Yes. The weirdness is probably in ISOLINUX or (if you can navigate in the menu) in the start-up of Linux kernel and initrd.
Did you verify that the original ISO works as expected ?
I have mailed the guys on the ISOLINUX mailing list but I will probably not get a reply.
There's hardly anybody at home any more.
What I could make out was that the livecd-tools for Fedora itself make use of a genisoimage like program called xorriso.
xorriso (where i am developer) has an emulation mode which takes many options of program mkisofs. genisoimage is a fork of mkisofs from 2006, beefed up by boot capabilities which Debian needed. Most of them are available in xorriso, too.
xorriso -indev "$orig" -report_el_torito plain -report_system_area plain
I could not understand these commands at all. If its alright with you, would you mind adding some more details ?
The shown xorriso run is for inspection of the boot entry points of ISOs, regardless which program made them.
We see the El Torito Catalog which PC-BIOS and EFI look up when the ISO is presented to them on CD, DVD, or BD medium. The one of your custom ISO will only have two entries.
Since you see the ISOLINUX menu, your test boots via catalog entry 1, which marks the first 2048 bytes of file /isolinux/isolinux.bin. The entry stems from mkisofs/genisoimage/xorrisofs option -b. The program determines the block address of isolinux.bin in the ISO and writes this number into the El Torito Catalog and into the boot-info-table inside isolinux.bin. So isolinux.bin will get selected for being started by PC-BIOS compatible firmware, which has no clue of ISO 9660 as filesystem. isolinux.bin knows how to read ISO 9660 filesystems and thus can load the menu configuration file, which it then displays.
The MBR partition table would be of interest if EFI firmware in non-legacy mode would boot. But in this case you would see a GRUB menu, which comes from software inside the FAT filesystem image /images/efiboot.img. xorriso shows that this image is exposed as MBR partition of type EF, so that EFI firmwares knows where to look for /EFI/BOOT/BOOTX64.EFI or /EFI/BOOT/BOOTIA32.EFI.
I could not find these options listed in the xorriso man page so I don't understand what you are referring to.
The man page of the mkisofs emulation is shown by
man xorrisofs
Many of the options are compatible with mkisofs and genisoimage. Some are special to xorriso.
Have a nice day :)
Thomas
Hi,
i wrote:
The resulting ISO will grow by the size of the whole ISO directory tree and the size of the data files which get added.
Clarification: "size of the whole ISO directory tree" means the size of the meta-data, not the size of the data files in the tree. The meta-data in Fedora-Workstation-Live-x86_64-31-1.9.iso are very small, because there are very few files in the tree.
Adding a text file of a few hundred bytes yielded a growth of 393216 bytes.
Have a nice day :)
Thomas
Its not everyday that I have the honor of talking to an actual developer for a GNU utility. I am extremely lucky, grateful and honored to have your input on my problem. Thank you so much for that.
The idea of using multi-session to add the file to the ISO image is genius by the way.
There is however one problem I am facing: The super-block is getting corrupted somehow, and that too in a very weird way. I will explain later.
So first, this is the command that I ran:
xorriso -dev Fedora-Workstation-Live-x86_64-31-1.9.iso -boot_image any keep -map /home/sreyan/anaconda-ks.cfg /isolinux/anacondaks.cfg
It ran perfectly, but when I tried mounting the now modified ISO image by double clicking in GNOME File Manager which uses GNOME Disks to mount ISO files I get the error:
Error mounting /dev/loop0p1 at /run/media/sreyan/Fedora-WS-Live-31-1-9: can't read superblock on /dev/loop0p1
Screenshot here: https://imgur.com/a/wLktqsp
Now is where it gets weird.
I thought that the image was completely corrupted but I wanted to check if I could mount it via command line, so I did:
sudo mount -t iso9660 Fedora-Workstation-Live-x86_64-31-1.9.iso /mnt
Weirdly, no errors. I went to the /mnt directory and I could browse all my files and even verified that the file that I added in was actually added in.
I also ran isovfy on my modified image, again it reported no errors.
So I printed out some diagnostic information of the ISO using the command that you shared, I did not know any other way:
xorriso -indev Fedora-Workstation-Live-x86_64-31-1.9.iso -report_el_torito plain -report_system_area plain
I did this on both the original untouched ISO and the modified one. The only relevant differences I could find where:
In Original: El Torito catalog : 42 1 In Modified: El Torito catalog : 942111 1
In Original: Media summary: 1 session, 942080 data blocks, 1840m data, 20.3g free In Modified: Media summary: 1 session, 942113 data blocks, 1840m data, 20.3g free
To rectify this I tried certain variations of the command you shared:
xorriso -dev Fedora-Workstation-Live-x86_64-31-1.9.iso -boot_image any keep -rom_toc_scan "on:emul_wide" -map /home/sreyan/anaconda-ks.cfg /isolinux/anacondaks.cfg
xorriso -dev Fedora-Workstation-Live-x86_64-31-1.9.iso -boot_image any keep -md5 off -map /home/sreyan/anaconda-ks.cfg /isolinux/anacondaks.cfg
xorriso -dev Fedora-Workstation-Live-x86_64-31-1.9.iso -boot_image any keep -md5 off -rom_toc_scan on:emul_wide -map /home/sreyan/anaconda-ks.cfg /isolinux/anacondaks.cfg
But none of the above worked, I kept getting the same error.
Can you please help me ?
What am I doing wrong ?
Thanks again.
On Tue, Apr 7, 2020 at 11:10 PM Thomas Schmitt scdbackup@gmx.net wrote:
Hi,
i wrote:
The resulting ISO will grow by the size of the whole ISO directory tree and the size of the data files which get added.
Clarification: "size of the whole ISO directory tree" means the size of the meta-data, not the size of the data files in the tree. The meta-data in Fedora-Workstation-Live-x86_64-31-1.9.iso are very small, because there are very few files in the tree.
Adding a text file of a few hundred bytes yielded a growth of 393216 bytes.
Have a nice day :)
Thomas _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On 4/8/20 9:57 AM, Sreyan Chakravarty wrote:
It ran perfectly, but when I tried mounting the now modified ISO image by double clicking in GNOME File Manager which uses GNOME Disks to mount ISO files I get the error:
Error mounting /dev/loop0p1 at /run/media/sreyan/Fedora-WS-Live-31-1-9: can't read superblock on /dev/loop0p1
Something is getting tricked by the special way the iso file is constructed. There aren't partitions. Or there might be, but they aren't what you want.
Now is where it gets weird.
I thought that the image was completely corrupted but I wanted to check if I could mount it via command line, so I did:
sudo mount -t iso9660 Fedora-Workstation-Live-x86_64-31-1.9.iso /mnt
That is the right way to mount it, using the raw file, not trying to access a partition inside it.
So if I put the image into a USB can I boot it ?
My question is that why can't GNOME disks mount it ?
On Wed, Apr 8, 2020 at 10:36 PM Samuel Sieb samuel@sieb.net wrote:
On 4/8/20 9:57 AM, Sreyan Chakravarty wrote:
It ran perfectly, but when I tried mounting the now modified ISO image by double clicking in GNOME File Manager which uses GNOME Disks to mount ISO files I get the error:
Error mounting /dev/loop0p1 at /run/media/sreyan/Fedora-WS-Live-31-1-9: can't read superblock on /dev/loop0p1
Something is getting tricked by the special way the iso file is constructed. There aren't partitions. Or there might be, but they aren't what you want.
Now is where it gets weird.
I thought that the image was completely corrupted but I wanted to check if I could mount it via command line, so I did:
sudo mount -t iso9660 Fedora-Workstation-Live-x86_64-31-1.9.iso /mnt
That is the right way to mount it, using the raw file, not trying to access a partition inside it. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On 4/8/20 11:03 AM, Sreyan Chakravarty wrote:
So if I put the image into a USB can I boot it ?
Yes.
My question is that why can't GNOME disks mount it ?
Gnome Disks is expecting a disk and the .iso file looks like one: # file Fedora-Workstation-Live-x86_64-31-1.9.iso Fedora-Workstation-Live-x86_64-31-1.9.iso: DOS/MBR boot sector; partition 2 : ID=0xef, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 172, 21716 sectors
In Nautilus, if I right-click an .iso file, I have the option to open with the disk image mounter. That works.
On 4/8/20 11:03 AM, Sreyan Chakravarty wrote:
Yes.
Gnome Disks is expecting a disk and the .iso file looks like one: # file Fedora-Workstation-Live-x86_64-31-1.9.iso Fedora-Workstation-Live-x86_64-31-1.9.iso: DOS/MBR boot sector; partition 2 : ID=0xef, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 172, 21716 sectors
So if I am correct, you are saying that GNOME Disks is being tricked into thinking the ISO file is a disk since it has partitions in it. Correct ?
In Nautilus, if I right-click an .iso file, I have the option to open with the disk image mounter. That works.
Well I am using the Disk Image Mounter, that still can't mount this file.
On 4/8/20 10:37 PM, Sreyan Chakravarty wrote:
On 4/8/20 11:03 AM, Sreyan Chakravarty wrote: Gnome Disks is expecting a disk and the .iso file looks like one: # file Fedora-Workstation-Live-x86_64-31-1.9.iso Fedora-Workstation-Live-x86_64-31-1.9.iso: DOS/MBR boot sector; partition 2 : ID=0xef, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 172, 21716 sectors
So if I am correct, you are saying that GNOME Disks is being tricked into thinking the ISO file is a disk since it has partitions in it. Correct ?
Yes.
In Nautilus, if I right-click an .iso file, I have the option to open with the disk image mounter. That works.
Well I am using the Disk Image Mounter, that still can't mount this file.
From the Nautilus right-click menu? What happens?
In Nautilus, if I right-click an .iso file, I have the option to open with the disk image mounter. That works.
Ok, using the command:
xorriso -dev test.iso \ -boot_image any keep \ -map "$file_or_tree_on_disk" "$path_in_iso"
Does not work even if I use right-click and select Disk Image Mounter. But when I add an output device to the image like
xorriso -indev test.iso \ -boot_image any keep \ -map "$file_or_tree_on_disk" "$path_in_iso" \ -outdev test.iso
Everything magically works.
Weird.
Hi,
But when I add an output device to the image like xorriso -indev test.iso \ -boot_image any keep \ -map "$file_or_tree_on_disk" "$path_in_iso" \ -outdev test.iso
Everything magically works. Weird.
Hm. This should yield the same result as -dev test.iso. I still get mount: /dev/loop0p1: can't read superblock if i let losetup create a partition device and try to mount it.
It would be explainable if -indev was a different file than test.iso. Partition 1 would still be smaller than the ISO image. But with -indev not equal -outdev you'd created no add-on session with metadata after the end of the partition. So the metadata would sit at the partition start and the mount command does not yet run into an error. You would probably get problems with reading data file content from the end of the image. E.g. if you tar up the mounted ISO.
tar cf - /mnt/iso | wc
You can compare partition size and image size by
xorriso -indev test.iso -report_system_area plain
For me it reports after above run
ISO image size/512 : 3768452 ... MBR partition table: N Status Type Start Blocks MBR partition : 1 0x80 0x00 0 3768320
So partition 1 is too small by 3768452 - 3768320 = 132 blocks of 512 bytes. With a larger add-on file this gap would grow more.
Have a nice day :)
Thomas
Hm. This should yield the same result as -dev test.iso. I still get mount: /dev/loop0p1: can't read superblock
May be I am doing something wrong.
Without your help I think I would have left Fedora since there are no tutorials as to how I can get a Kickstart file on to a disk. You have helped me a lot more than you know. xorriso seems to be the best documented software for ISO file manipulation. I did not even know that USB sticks had a MBR partition.
Its just that for beginners like me who come from Windows, its difficult to find the correct documentation.
Thanks again, and I hope to talk to you again if I face problems with the libburn suite of programs.
On Fri, Apr 10, 2020 at 2:43 AM Thomas Schmitt scdbackup@gmx.net wrote:
Hi,
But when I add an output device to the image like xorriso -indev test.iso \ -boot_image any keep \ -map "$file_or_tree_on_disk" "$path_in_iso" \ -outdev test.iso
Everything magically works. Weird.
Hm. This should yield the same result as -dev test.iso. I still get mount: /dev/loop0p1: can't read superblock if i let losetup create a partition device and try to mount it.
It would be explainable if -indev was a different file than test.iso. Partition 1 would still be smaller than the ISO image. But with -indev not equal -outdev you'd created no add-on session with metadata after the end of the partition. So the metadata would sit at the partition start and the mount command does not yet run into an error. You would probably get problems with reading data file content from the end of the image. E.g. if you tar up the mounted ISO.
tar cf - /mnt/iso | wc
You can compare partition size and image size by
xorriso -indev test.iso -report_system_area plain
For me it reports after above run
ISO image size/512 : 3768452 ... MBR partition table: N Status Type Start Blocks MBR partition : 1 0x80 0x00 0 3768320
So partition 1 is too small by 3768452 - 3768320 = 132 blocks of 512 bytes. With a larger add-on file this gap would grow more.
Have a nice day :)
Thomas _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
Hi,
i wrote:
I still get mount: /dev/loop0p1: can't read superblock
Sreyan Chakravarty wrote:
May be I am doing something wrong.
Success by mistake is a classical pattern. :)) We will learn more when success vanishes righteously.
I did not even know that USB sticks had a MBR partition.
To be exacting: They can get a MBR partition table. In case of the Fedora ISO its MBR partition 2 is the boot starting point for EFI when the ISO is presented on USB stick.
Partitioning is not a special property of a storage device, but rather just a few blocks of data in a specified format. There are various formats, of which MBR partition table probably stems from MS-DOS. The modern successor is GUID Partition Table (GPT) as specified in UEFI. Apple, BSD Unix, SUN, etc. have/had their own partition table formats. Linux understands many of them and never introduced an own format, afaik.
I hope to talk to you again if I face problems with the libburn suite of programs.
Please Cc me in this case. I am only temporarily subscribed here while waiting for Richard Shaw to get his paycheck and to make his decision whether really to invest the hard-earned money in experiments with BD-R multi-layer media.
(Further i subscribed to Tom Horsley's bug report about USB-DVD allergy.)
In general, questions about xorriso, cdrskin, libburn, libisofs, or libisoburn may be posted to bug-xorriso@gnu.org .
Have a nice day :)
Thomas
On 4/10/20 1:46 PM, Sreyan Chakravarty wrote:
Hm. This should yield the same result as -dev test.iso. I still get mount: /dev/loop0p1: can't read superblock
May be I am doing something wrong.
Without your help I think I would have left Fedora since there are no tutorials as to how I can get a Kickstart file on to a disk. You have helped me a lot more than you know. xorriso seems to be the best documented software for ISO file manipulation. I did not even know that USB sticks had a MBR partition.
Its just that for beginners like me who come from Windows, its difficult to find the correct documentation.
That is far from a beginner task and something that extremely few people would have any reason to do. It's also rare that you're trying to create something for optical media. If you were using USB flash, it would be simple.
If you were using USB flash, it would be simple.
How would it be simple ? There are no tutorials or docs out there laying out how you are suppose to do a Kickstart install with NFS.
On Sat, Apr 11, 2020 at 12:25 PM Samuel Sieb samuel@sieb.net wrote:
On 4/10/20 1:46 PM, Sreyan Chakravarty wrote:
Hm. This should yield the same result as -dev test.iso. I still get mount: /dev/loop0p1: can't read superblock
May be I am doing something wrong.
Without your help I think I would have left Fedora since there are no tutorials as to how I can get a Kickstart file on to a disk. You have helped me a lot more than you know. xorriso seems to be the best documented software for ISO file manipulation. I did not even know that USB sticks had a MBR partition.
Its just that for beginners like me who come from Windows, its difficult to find the correct documentation.
That is far from a beginner task and something that extremely few people would have any reason to do. It's also rare that you're trying to create something for optical media. If you were using USB flash, it would be simple. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On 4/11/20 1:09 AM, Sreyan Chakravarty wrote:
If you were using USB flash, it would be simple.
How would it be simple ? There are no tutorials or docs out there laying out how you are suppose to do a Kickstart install with NFS.
There are. Also, you could ask here as there are several active users that do that. That's how I do most of my installs. Actually, most are network boot installs, but I've done some starting from USB as well.
There are no tutorials or docs out there laying out how you are suppose
to do a Kickstart install with NFS.
Whoops, I mean USB not NFS.
Ok, I don't mean to rude or flippant, but I these requests mainly don't get answered. I mean dont get me wrong I owe all my progress to Thomas and you.
Anyways can you help me with this issue : https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/...
On Sat, Apr 11, 2020 at 2:13 PM Samuel Sieb samuel@sieb.net wrote:
On 4/11/20 1:09 AM, Sreyan Chakravarty wrote:
If you were using USB flash, it would be simple.
How would it be simple ? There are no tutorials or docs out there laying out how you are suppose to do a Kickstart install with NFS.
There are. Also, you could ask here as there are several active users that do that. That's how I do most of my installs. Actually, most are network boot installs, but I've done some starting from USB as well. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Sat, 11 Apr 2020 at 11:09, Sreyan Chakravarty sreyan32@gmail.com wrote:
There are no tutorials or docs out there laying out how you are suppose
to do a Kickstart install with NFS.
Whoops, I mean USB not NFS.
Ok, I don't mean to rude or flippant, but I these requests mainly don't get answered. I mean dont get me wrong I owe all my progress to Thomas and you.
Anyways can you help me with this issue :
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/...
You can use this method to generate custom installs:
$ sudo dnf install lorax-composer cockpit-composer cockpit composer-cli https://weldr.io/Running-Composer-on-RHEL/
See 'Compose an image from the UI'
Sorry I forgot to attach the dmesg log:
[ 591.907687] loop: module loaded [ 591.916803] loop0: p1 p2 p3 [ 592.293941] ISOFS: unable to read i-node block [ 592.293945] isofs_fill_super: get root inode failed [ 593.806597] ISOFS: unable to read i-node block [ 593.806600] isofs_fill_super: get root inode failed [ 599.155459] loop1: p1 p2 p3 [ 599.319787] ISOFS: unable to read i-node block [ 599.319791] isofs_fill_super: get root inode failed [ 601.444532] ISOFS: unable to read i-node block [ 601.444536] isofs_fill_super: get root inode failed [ 778.629631] ISOFS: unable to read i-node block [ 778.629634] isofs_fill_super: get root inode failed [ 829.781914] ISOFS: unable to read i-node block [ 829.781920] isofs_fill_super: get root inode failed [ 833.738402] ISOFS: unable to read i-node block [ 833.738406] isofs_fill_super: get root inode failed [ 835.787665] ISOFS: unable to read i-node block [ 835.787669] isofs_fill_super: get root inode failed [ 845.880910] ISOFS: unable to read i-node block [ 845.880914] isofs_fill_super: get root inode failed [ 1124.770791] loop2: p1 p2 p3 [ 1125.051865] ISOFS: unable to read i-node block [ 1125.051869] isofs_fill_super: get root inode failed [ 1126.924766] ISOFS: unable to read i-node block [ 1126.924770] isofs_fill_super: get root inode failed [ 1134.371004] ISOFS: unable to read i-node block [ 1134.371007] isofs_fill_super: get root inode failed [ 1136.691132] ISOFS: unable to read i-node block [ 1136.691135] isofs_fill_super: get root inode failed [ 1138.549453] ISOFS: unable to read i-node block [ 1138.549456] isofs_fill_super: get root inode failed [ 1142.381306] ISOFS: unable to read i-node block [ 1142.381311] isofs_fill_super: get root inode failed [ 1204.823811] ISOFS: unable to read i-node block [ 1204.823815] isofs_fill_super: get root inode failed [ 1477.347315] ISO 9660 Extensions: Microsoft Joliet Level 3 [ 1477.347366] ISO 9660 Extensions: Microsoft Joliet Level 3 [ 1477.444637] ISO 9660 Extensions: RRIP_1991A [ 1632.918071] loop3: p1 p2 p3 [ 1633.076736] ISO 9660 Extensions: Microsoft Joliet Level 3 [ 1633.076943] ISO 9660 Extensions: RRIP_1991A [ 1672.464813] loop3: p1 p2 p3 [ 1672.622272] ISOFS: unable to read i-node block [ 1672.622276] isofs_fill_super: get root inode failed [ 1674.471523] ISOFS: unable to read i-node block [ 1674.471527] isofs_fill_super: get root inode failed [ 1688.879386] ISO 9660 Extensions: RRIP_1991A
On Tue, Apr 7, 2020 at 11:10 PM Thomas Schmitt scdbackup@gmx.net wrote:
Hi,
i wrote:
The resulting ISO will grow by the size of the whole ISO directory tree and the size of the data files which get added.
Clarification: "size of the whole ISO directory tree" means the size of the meta-data, not the size of the data files in the tree. The meta-data in Fedora-Workstation-Live-x86_64-31-1.9.iso are very small, because there are very few files in the tree.
Adding a text file of a few hundred bytes yielded a growth of 393216 bytes.
Have a nice day :)
Thomas _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
Hi,
Sreyan Chakravarty wrote:
xorriso -dev Fedora-Workstation-Live-x86_64-31-1.9.iso -boot_image any keep -map /home/sreyan/anaconda-ks.cfg /isolinux/anacondaks.cfg
Looks ok. But see below for a variation that pleases GNOME Disks.
First some diagnosis:
double clicking in GNOME File Manager which uses GNOME Disks to mount ISO files I get the error: Error mounting /dev/loop0p1 at /run/media/sreyan/Fedora-WS-Live-31-1-9: can't read superblock on /dev/loop0p1
"loop0p1" looks unusual. "p" could mean partition. Partition 1 of a Fedora Live ISO should be mountable, nevertheless.
I get "p1" on my elderly Debian by
$ sudo -P -f Fedora-Workstation-Live-x86_64-31-1.9.iso ... $ ls /dev/loop*p* /dev/loop0p1 /dev/loop0p2 /dev/loop0p3 $ sudo mount /dev/loop0p1 /mnt/iso mount: /dev/loop0p1 is write-protected, mounting read-only $ find /mnt/iso ... the expectable file paths of the original with prefix /mnt/iso... $ sudo umount /mnt/iso $ sudo losetup -d /dev/loop0
Now with my grown ISO
$ sudo losetup -P -f test.iso $ ls /dev/loop*p* /dev/loop0p1 /dev/loop0p2 /dev/loop0p3 $ sudo mount /dev/loop0p1 /mnt/iso mount: /dev/loop0p1 is write-protected, mounting read-only mount: /dev/loop0p1: can't read superblock $ find /mnt/iso /mnt/iso $ sudo losetup -d /dev/loop0
So it really did not get mounted.
The problem is probably that the root directory metadata is now outside of partition 1. The complaint about "superblock" is somewhat misleading.
(A partition editor could be used to move the end of partition 1 to the end of the image. But i cannot talk fdisk into doing that.)
As far as i can see it is a deliberate choice of GNOME Disks to use partition 1 rather than the whole image. This is quite unusual. Partition 1 has no particular job in the big isohybrid pile of tricks. Neither on DVD nor on USB stick. It not even has a decent partition type. Most readers ignore it.
You should test your modified ISO whether it boots and whether the booted system sees your added file.
-----------------------------------------------------------------------
If you want to please partition loving readers, then maybe the full orchestra of xorriso boot preparation capabilities can help:
cp Fedora-Workstation-Live-x86_64-31-1.9.iso test.iso
xorriso -dev test.iso \ -map "$file_or_tree_on_disk" "$path_in_iso" \ -boot_image any replay
The difference to your previous run is the -boot_image parameter "replay". Other than "keep" it tries to detect boot equipment, drops it, and runs the xorriso commands to re-create it. We particularly want a new partition 1.
(Further the command -boot_image is now at the end of the arguments list, just in case you do anything significant to the boot image files. You would then want to activate the modified images, not the old ones.)
Now i test the result for loop*p1 usability:
$ sudo losetup -P -f test.iso $ ls /dev/loop*p* /dev/loop0p1 /dev/loop0p2 /dev/loop0p3 $ sudo mount /dev/loop0p1 /mnt/iso mount: /dev/loop0p1 is write-protected, mounting read-only $ find /mnt/iso ... all files including my added one ... $ sudo umount /mnt/iso $ sudo losetup -d /dev/loop0
The -boot_image treatment "replay" is actually meant for a different work mode of xorriso, which copies an old ISO to a new ISO and modifies the new content inbetween:
rm test.iso
xorriso -indev Fedora-Workstation-Live-x86_64-31-1.9.iso \ -outdev test.iso \ -compliance no_emul_toc \ -map "$file_or_tree_on_disk" "$path_in_iso" \ -boot_image any replay
----------------------------------------------------------------------- More or less anecdotal:
Screenshot here: https://imgur.com/a/wLktqsp [imgur.com]
I only see a black rectangle (with some framing ornaments). My web browser is old.
Is there any noteworthy text to see, beyond what is quoted above ?
sudo mount -t iso9660 Fedora-Workstation-Live-x86_64-31-1.9.iso /mnt Weirdly, no errors.
(I'd rather call GNOME File Manager weird, if i have to decide for one option. :))
In Original: El Torito catalog : 42 1 In Modified: El Torito catalog : 942111 1
The ISO got a new El Torito catalog. But since the other "El Torito" lines of the xorriso output do not differ, the new catalog advertises the same boot images as does the old catalog.
Have a nice day :)
Thomas
I only see a black rectangle (with some framing ornaments). My web browser is old.
Is there any noteworthy text to see, beyond what is quoted above ?
Nothing of value. You can ignore it.
I could not be more grateful for your in-depth replies. Not only are you helping me with my problem but I learn a lot of new things every time.
I just have a one question for my curiosity.
xorriso -dev test.iso \ -map "$file_or_tree_on_disk" "$path_in_iso" \ -boot_image any replay
When you instruct xorriso to do a "replay" what you are saying is essentially to re-create the boot image using guidelines from the original boot image. When I mean guidelines I mean using the same boot equipment but pointing to the new ISO file system.
Am I correct in my thinking ?
Previously xorriso was just blindly keeping the boot image from the old disk and it was containing information outdated info about the new file.
I am kind of confused as to the difference/advantage between keeping the old boot image versus rebuilding one.
Thanks so much.
Regards, Sreyan
Is there any noteworthy text to see, beyond what is quoted above ?
No you can ignore it. It was just a screenshot from VirtualBox describing the superblocks problem I typed out.
I can't thank you enough for your in-depth explanations. Not only are you helping me with my problem but I also learn a lot of new things.
I just have a couple questions for my curiosity:
xorriso -indev Fedora-Workstation-Live-x86_64-31-1.9.iso \ -outdev test.iso \ -compliance no_emul_toc \ -map "$file_or_tree_on_disk" "$path_in_iso" \ -boot_image any replay
Firstly, I am confused with difference between recreating the boot image versus blindly copying it, as you were doing with -boot_image any keep.
Correct me if I am wrong, but from what I can understand just blindly copying the boot image will result in partition one having a information that refers to the old image, which is now incorrect. That information is the superblock.
So to rectify this we rebuild the boot image from the information in the new ISO file. We keep the same boot equipment but change all of the metadata one of which is the superblock. So the new boot image has the same boot equipment as the original but points to valid locations on the ISO image now.
Basically this is sort of a record update. Right ?
Am I correct in my thinking ?
Secondly,
-compliance no_emul_toc \
Why aren't you keeping a Table of Contents ? Aren't they required for compatibility reasons ?
Thanks again.
Regards, Sreyan
On Wed, Apr 8, 2020 at 11:54 PM Thomas Schmitt scdbackup@gmx.net wrote:
Hi,
Sreyan Chakravarty wrote:
xorriso -dev Fedora-Workstation-Live-x86_64-31-1.9.iso -boot_image any
keep
-map /home/sreyan/anaconda-ks.cfg /isolinux/anacondaks.cfg
Looks ok. But see below for a variation that pleases GNOME Disks.
First some diagnosis:
double clicking in GNOME File Manager which uses GNOME Disks to mount ISO files I get the error: Error mounting /dev/loop0p1 at /run/media/sreyan/Fedora-WS-Live-31-1-9: can't read superblock on /dev/loop0p1
"loop0p1" looks unusual. "p" could mean partition. Partition 1 of a Fedora Live ISO should be mountable, nevertheless.
I get "p1" on my elderly Debian by
$ sudo -P -f Fedora-Workstation-Live-x86_64-31-1.9.iso ... $ ls /dev/loop*p* /dev/loop0p1 /dev/loop0p2 /dev/loop0p3 $ sudo mount /dev/loop0p1 /mnt/iso mount: /dev/loop0p1 is write-protected, mounting read-only $ find /mnt/iso ... the expectable file paths of the original with prefix /mnt/iso... $ sudo umount /mnt/iso $ sudo losetup -d /dev/loop0
Now with my grown ISO
$ sudo losetup -P -f test.iso $ ls /dev/loop*p* /dev/loop0p1 /dev/loop0p2 /dev/loop0p3 $ sudo mount /dev/loop0p1 /mnt/iso mount: /dev/loop0p1 is write-protected, mounting read-only mount: /dev/loop0p1: can't read superblock $ find /mnt/iso /mnt/iso $ sudo losetup -d /dev/loop0
So it really did not get mounted.
The problem is probably that the root directory metadata is now outside of partition 1. The complaint about "superblock" is somewhat misleading.
(A partition editor could be used to move the end of partition 1 to the end of the image. But i cannot talk fdisk into doing that.)
As far as i can see it is a deliberate choice of GNOME Disks to use partition 1 rather than the whole image. This is quite unusual. Partition 1 has no particular job in the big isohybrid pile of tricks. Neither on DVD nor on USB stick. It not even has a decent partition type. Most readers ignore it.
You should test your modified ISO whether it boots and whether the booted system sees your added file.
If you want to please partition loving readers, then maybe the full orchestra of xorriso boot preparation capabilities can help:
cp Fedora-Workstation-Live-x86_64-31-1.9.iso test.iso
xorriso -dev test.iso \ -map "$file_or_tree_on_disk" "$path_in_iso" \ -boot_image any replay
The difference to your previous run is the -boot_image parameter "replay". Other than "keep" it tries to detect boot equipment, drops it, and runs the xorriso commands to re-create it. We particularly want a new partition
(Further the command -boot_image is now at the end of the arguments list, just in case you do anything significant to the boot image files. You would then want to activate the modified images, not the old ones.)
Now i test the result for loop*p1 usability:
$ sudo losetup -P -f test.iso $ ls /dev/loop*p* /dev/loop0p1 /dev/loop0p2 /dev/loop0p3 $ sudo mount /dev/loop0p1 /mnt/iso mount: /dev/loop0p1 is write-protected, mounting read-only $ find /mnt/iso ... all files including my added one ... $ sudo umount /mnt/iso $ sudo losetup -d /dev/loop0
The -boot_image treatment "replay" is actually meant for a different work mode of xorriso, which copies an old ISO to a new ISO and modifies the new content inbetween:
rm test.iso
xorriso -indev Fedora-Workstation-Live-x86_64-31-1.9.iso \ -outdev test.iso \ -compliance no_emul_toc \ -map "$file_or_tree_on_disk" "$path_in_iso" \ -boot_image any replay
More or less anecdotal:
Screenshot here: https://imgur.com/a/wLktqsp [imgur.com]
I only see a black rectangle (with some framing ornaments). My web browser is old.
Is there any noteworthy text to see, beyond what is quoted above ?
sudo mount -t iso9660 Fedora-Workstation-Live-x86_64-31-1.9.iso /mnt Weirdly, no errors.
(I'd rather call GNOME File Manager weird, if i have to decide for one option. :))
In Original: El Torito catalog : 42 1 In Modified: El Torito catalog : 942111 1
The ISO got a new El Torito catalog. But since the other "El Torito" lines of the xorriso output do not differ, the new catalog advertises the same boot images as does the old catalog.
Have a nice day :)
Thomas _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
Hi,
Sreyan Chakravarty wrote:
I am kind of confused as to the difference/advantage between keeping the old boot image versus rebuilding one.
My first multi-session proposal was to keep as much of the boot equipment as possible. After all, we began with the riddle why your genisoimage produced ISO boots to an ISOLINUX menu but that menu does not work. So "keep" seemed to be better than "replay".
Boot equipment is a manifold topic, even if restricted to x86 machines.
Roughly there are "boot images", which are intervals of data blocks. Either they are executable programs, like isolinux.bin, or they are filesystem images like efiboot.img.
The firmware, PC-BIOS or EFI, expects easy-to-understand pointers to the boot images. These pointers are stored in the El Torito boot sector and El Torito boot catalog (for DVD), or as MBR boot code (for PC-BIOS and USB stick), or as partition table (for EFI and USB stick).
As long as the boot images stay where they are in the original ISO, it is ok to keep the pointers as they are. The only problem you reported so far is that the quite unimportant partition 1 did not grow with the ISO image when you added the new session. The boot pointer in the partition table is partition 2, which is marked as EFI System Partition.
Replaying all boot preparations bears more potential points of failure. xorriso could misunderstand the boot equipment of the original ISO or it could make mistakes when trying to re-create it. But if it works correctly, it will re-create partition 1 with the new size of the ISO. So no part of the ISO filesystem lies outside of it and GNOME Disks will be happy when it tries to mount partition 1.
Secondly,
-compliance no_emul_toc \
Why aren't you keeping a Table of Contents ? Aren't they required for compatibility reasons ?
It's for getting an ISO image with no extra multi-session history. The original ISO doesn't have that history either.
Multi-session is actually a feature of sequential optical media: CD-R, CD-RW, DVD-R, DVD+R, BD-R, unformatted DVD-RW. With these media the Linux convention is to mount the first track of the last session. This track can be found by the medium's Table-Of-Content which tells start addresses of sessions and tracks. Each of the listed sessions can be mounted by Linux mount option sbsector= and will show the disk state from the time when it was the last session. Quite useful for incremental multi-session backups.
Overwritable media (DVD-RAM, DVD+RW, BD-RE, formatted DVD-RW) and data files do not have such a table of content. Linux by default mounts what it finds at the usual offset starting from block 0. ISO 9660 multi-session on such media and files thus has to overwrite the old superblock at this standard location by new content which points to the root directory of the newest session. (Invention of Andy Polyakov for his program growisofs with DVD+RW.)
By this overwriting of the superblock, the old root directory becomes lost in the woods. It is still there and still could be mounted. But no superblock points to it. So only one session is to see. The newest.
That's the reason for my invention of emulated table of content. The first session does not get written to block 0 but rather to block 32. This leaves room for an official superblock at block 0 and thus saves the superblock of the first session from being overwritten by session 2. Now the superblocks of the sessions form a chain, which xorriso command -toc can display. This offset 32 of the new session gets disabled by -compliance no_emul_toc. As said, because mkisofs does not do it and thus xorrisofs doesn't either by default. But xorriso would do it by default. And the new ISO would differ in this way from the old one more than is necessary.
For a motivation of xorriso's default see one of my backup BD-REs which i update daily by a xorriso run with -update_r commands:
$ xorriso -indev /dev/sr4 -toc ... Media current: BD-RE Media status : is written , is appendable Media summary: 138 sessions, 9405258 data blocks, 17.9g data, 5236m free ... TOC layout : Idx , sbsector , Size , Volume Id ISO session : 1 , 32 , 2112020s , HOME_2019_11_24_152510 ISO session : 2 , 2112064 , 68114s , HOME_2019_11_25_160120 ISO session : 3 , 2180192 , 77406s , HOME_2019_11_26_154114 ... ISO session : 136 , 9255008 , 55002s , HOME_2020_04_07_181157 ISO session : 137 , 9310016 , 47622s , HOME_2020_04_08_150526 ISO session : 138 , 9357664 , 49682s , HOME_2020_04_09_155619
If needed i can mount any of these daily backup states by the number in the "sbsector" column. xorriso offers a helper command to mount by session number or a search text for the volume id.
On a BD-R with its hardware table of content, i see without such emulation effort:
Media current: BD-R sequential recording Media status : is written , is appendable Media summary: 55 sessions, 4935104 data blocks, 9639m data, 13.9g free ... TOC layout : Idx , sbsector , Size , Volume Id ISO session : 1 , 0 , 2112619s , HOME_2020_02_15_121306 ISO session : 2 , 2112800 , 44925s , HOME_2020_02_16_110515 ... ISO session : 55 , 4885696 , 49252s , HOME_2020_04_09_111237
The only visible difference is that session 1 starts at block 0. On hardware level, BD-RE and BD-R differ much more.
Have a nice day :)
Thomas
That's the reason for my invention of emulated table of content. The first session does not get written to block 0 but rather to block 32. This leaves room for an official superblock at block 0 and thus saves the superblock of the first session from being overwritten by session 2. Now the superblocks of the sessions form a chain, which xorriso command -toc can display.
Okay, so what you are doing is actually against convention. So basically what you are saying is the convention for overwritable media dictates that only one superblock is needed and if Linux or any other OS finds that then it will mount that. Essentially, the OS assumes that since the device is rewritable multi-session does not need to keep old records.
What you have done is emulated the TOC of sequential media on rewritable media. Am I right ?
This way I have access to all my sessions and not just the current one even if I am on a rewritable media.
This springs another question, though I did not get any resources to research this before asking you :
Is there a limit to the number of sessions a media can store ? I mean is that a fixed number or that is dependent on the capacity itself ?
I can't believe how lucky I am to actually interact with you, I don't think anyone really understands these topics in depth. I really don't know how you wrote a program like xorriso or libburn, I mean where would you even get the implementation details for something so obscure.
Thanks.
Regards, Sreyan
Hi,
Sreyan Chakravarty wrote:
Okay, so what you are doing is actually against convention.
It's fully compliant. Just moving apart the default mountable superblock from the chain of session superblocks which need an extra option to mount(8) in order to get mounted.
Essentially, the OS assumes that since the device is rewritable multi-session does not need to keep old records.
The drive maintains the table-of-content on sequential media. The operating system inquires this table by SCSI commands. SCSI On overwritable media, the commands will report of one single track in one single session, the formatted area.
What you have done is emulated the TOC of sequential media on rewritable media.
Yes.
Is there a limit to the number of sessions a media can store ? I mean is that a fixed number or that is dependent on the capacity itself ?
On overwritable media, data files, or block devices it is only the medium capacity which limits the number of sessions. I have a backup scheme with compressed files which fits about 400 sessions on one BD-RE before it is full.
On sequential media there are limits on the size of the table and also there are substantial gaps wasted between sessions on CD-R, CD-RW, DVD-R, DVD+R, unformatted DVD-RW. Only BD-R store their sessions quite seamlessly.
CD is restricted to 99 tracks, because the numbering is two decimal digits beginning at 01. But their capacity of <= 800 MB does not offer enough room for 99 sessions with drive-chosen gaps inbetween. DVD-R and DVD-RW are restricted to 99 sessions, too. DVD+R take at most 153 sessions. With BD-R it depends on the drive. My LG BH16NS40 and Optiarc BD-5300S do 128 sessions before they close the medium automatically. My ASUS BW-16D1HT does 250+ sessions. For now it refused only when the medium had not enough room for the next session's data.
I really don't know how you wrote a program like xorriso or libburn,
It needed some endurance. I began in 2005, when it was to fear that quarrels between Linus Torvalds and Joerg Schilling would deprive Linux of the program to write CDs in TAO write mode. (Well, Debian forked wodim from cdrecord in 2006. I could have spared my effort if it was only about CD writing. But since then my scope widened.)
I mean where would you even get the implementation details for something so obscure.
It's publicly specified. SCSI volumes SPC, SBC, MMC for optical drives. ECMA-119 aka ISO 9660 for the filesystem. Joliet, SUSP, RRIP for its extra metadata. El Torito for booting from optical media. UEFI for partition tables. Only MBR boot code is pure oral culture. One has to read Wikipedia. (I invented AAIP on base of SUSP to store ACLs, extended file attributes, and self-invented ISO 9660 metadata. Only libisofs can read it, though.)
Hardest part is to find out how to deal with the non-standard features of the various operating systems. Each does SCSI passthrough by a different method.
When in doubt, i looked what growisofs does. Its code is fewly structured which makes it quite easy to spot the work flow of SCSI commands. Sometimes i decided to deviate from Andy's decisions after reading the background in MMC specs.
I wrote down what i learned in the ./doc directories of my library tarballs. See .txt files in https://dev.lovelyhq.com/libburnia/libburn/tree/master/doc https://dev.lovelyhq.com/libburnia/libisofs/tree/master/doc
Have a nice day :)
Thomas
Sorry rather why are you disabling session history ?
Any particular reason?
On Wed, Apr 8, 2020 at 11:54 PM Thomas Schmitt scdbackup@gmx.net wrote:
Hi,
Sreyan Chakravarty wrote:
xorriso -dev Fedora-Workstation-Live-x86_64-31-1.9.iso -boot_image any
keep
-map /home/sreyan/anaconda-ks.cfg /isolinux/anacondaks.cfg
Looks ok. But see below for a variation that pleases GNOME Disks.
First some diagnosis:
double clicking in GNOME File Manager which uses GNOME Disks to mount ISO files I get the error: Error mounting /dev/loop0p1 at /run/media/sreyan/Fedora-WS-Live-31-1-9: can't read superblock on /dev/loop0p1
"loop0p1" looks unusual. "p" could mean partition. Partition 1 of a Fedora Live ISO should be mountable, nevertheless.
I get "p1" on my elderly Debian by
$ sudo -P -f Fedora-Workstation-Live-x86_64-31-1.9.iso ... $ ls /dev/loop*p* /dev/loop0p1 /dev/loop0p2 /dev/loop0p3 $ sudo mount /dev/loop0p1 /mnt/iso mount: /dev/loop0p1 is write-protected, mounting read-only $ find /mnt/iso ... the expectable file paths of the original with prefix /mnt/iso... $ sudo umount /mnt/iso $ sudo losetup -d /dev/loop0
Now with my grown ISO
$ sudo losetup -P -f test.iso $ ls /dev/loop*p* /dev/loop0p1 /dev/loop0p2 /dev/loop0p3 $ sudo mount /dev/loop0p1 /mnt/iso mount: /dev/loop0p1 is write-protected, mounting read-only mount: /dev/loop0p1: can't read superblock $ find /mnt/iso /mnt/iso $ sudo losetup -d /dev/loop0
So it really did not get mounted.
The problem is probably that the root directory metadata is now outside of partition 1. The complaint about "superblock" is somewhat misleading.
(A partition editor could be used to move the end of partition 1 to the end of the image. But i cannot talk fdisk into doing that.)
As far as i can see it is a deliberate choice of GNOME Disks to use partition 1 rather than the whole image. This is quite unusual. Partition 1 has no particular job in the big isohybrid pile of tricks. Neither on DVD nor on USB stick. It not even has a decent partition type. Most readers ignore it.
You should test your modified ISO whether it boots and whether the booted system sees your added file.
If you want to please partition loving readers, then maybe the full orchestra of xorriso boot preparation capabilities can help:
cp Fedora-Workstation-Live-x86_64-31-1.9.iso test.iso
xorriso -dev test.iso \ -map "$file_or_tree_on_disk" "$path_in_iso" \ -boot_image any replay
The difference to your previous run is the -boot_image parameter "replay". Other than "keep" it tries to detect boot equipment, drops it, and runs the xorriso commands to re-create it. We particularly want a new partition
(Further the command -boot_image is now at the end of the arguments list, just in case you do anything significant to the boot image files. You would then want to activate the modified images, not the old ones.)
Now i test the result for loop*p1 usability:
$ sudo losetup -P -f test.iso $ ls /dev/loop*p* /dev/loop0p1 /dev/loop0p2 /dev/loop0p3 $ sudo mount /dev/loop0p1 /mnt/iso mount: /dev/loop0p1 is write-protected, mounting read-only $ find /mnt/iso ... all files including my added one ... $ sudo umount /mnt/iso $ sudo losetup -d /dev/loop0
The -boot_image treatment "replay" is actually meant for a different work mode of xorriso, which copies an old ISO to a new ISO and modifies the new content inbetween:
rm test.iso
xorriso -indev Fedora-Workstation-Live-x86_64-31-1.9.iso \ -outdev test.iso \ -compliance no_emul_toc \ -map "$file_or_tree_on_disk" "$path_in_iso" \ -boot_image any replay
More or less anecdotal:
Screenshot here: https://imgur.com/a/wLktqsp [imgur.com]
I only see a black rectangle (with some framing ornaments). My web browser is old.
Is there any noteworthy text to see, beyond what is quoted above ?
sudo mount -t iso9660 Fedora-Workstation-Live-x86_64-31-1.9.iso /mnt Weirdly, no errors.
(I'd rather call GNOME File Manager weird, if i have to decide for one option. :))
In Original: El Torito catalog : 42 1 In Modified: El Torito catalog : 942111 1
The ISO got a new El Torito catalog. But since the other "El Torito" lines of the xorriso output do not differ, the new catalog advertises the same boot images as does the old catalog.
Have a nice day :)
Thomas _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
-
Anthony F McInerney -
Samuel Sieb -
Sreyan Chakravarty -
Thomas Schmitt