> 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 \
> -outdev test.iso \
> -compliance no_emul_toc \
> -map "$file_or_tree_on_disk" "$path_in_iso" \
> -boot_image any replay
> -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@xxxxxxx> 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 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
_______________________________________________
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
Regards,
Sreyan Chakravarty
_______________________________________________ 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
