Hi,
Vijay Kirpalani wrote:
> Step1:
> grub-mkrescue --modules="part_msdos part_gpt gzio ext2 iso9660" \
> -o final1.iso -d img0
> Step2:
> xorriso -as mkisofs \
> -o final.iso -c boot.catalog -volid "MY_CUSTOM_LINUX" \
> -b boot/grub/i386-pc/eltorito.img -no-emul-boot -boot-load-size 4 \
> -boot-info-table -append_partition 2 0x83 disk.img \
> -partition_cyl_align all=1 out-combine
This is still quite a mislead method.
I already advised you to combine both steps to a single grub-mkrescue run
with additional xorrisofs arguments.
Roughly guessed:
grub-mkrescue ...as.above... \
-append_partition 2 0x83 disk.img -partition_cyl_align \
out-combine
The resulting ISO will have disk-like boot equipment in addition to
the CDROM boot equipment of your step2 ISO.
In a coarse experiment on Debian 12, the appended (rather small) disk.img
shows up as GPT partition 4.
$ grub-mkrescue -o test.iso -append_partition 2 0x83 disk.img ./dummy_dir
...
ISO image produced: 7027 sectors
...
$ /sbin/fdisk -l test.iso
...
Disklabel type: gpt
...
Device Start End Sectors Size Type
test.iso1 64 203 140 70K Microsoft basic data
test.iso2 204 5963 5760 2.8M EFI System
test.iso3 5964 25543 19580 9.6M Apple HFS/HFS+
test.iso4 25544 27459 1916 958K Microsoft basic data
test.iso5 27460 28059 600 300K Microsoft basic data
With GPT partitions, the desired partition number is not always possible.
grub-mkrescue normally creates partitions 1 to 4. An appended partition
has its storage after partition 3 and before the usually present
partition 4. So disk.img will become number 4 and the usual 4 will become
number 5.
No mountable ISO 9660 partition will emerge, but a HFS+ partition will
show the same files as the ISO filesystem. Further (hd0) without partition
should show the ISO 9660 filesystem.
> > What do the following commands report ?
> > xorriso -indev "$path_to_iso" -report_el_torito plain -report_system_area
> > plain
> See the attached text file command_output.
As expected from the xorriso run in step 2, the ISO is only equipped for
booting via Legacy BIOS from optical medium (CD, DVD, BD):
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x0000 0x00 4 48
El Torito img path : 1 /boot/grub/i386-pc/eltorito.img
El Torito img opts : 1 boot-info-table
No EFI System Partition and no workable GRUB Isohybrid MBR are reported.
So it looks much like a CDROM-only image.
Possibly Virtual Box took this as reason to represent the image as virtual
CD device rather than as virtual hard disk.
You could try to give Virtual Box a stronger hint that your ISO is to be
handled as hard disk. But without boot equipment for hard disk, it might
be that Virtual Box will not believe you.
Further i read in
https://www.virtualbox.org/manual/ch05.html
that it expects a virtual disk format for hard disk images.
"Hard disk images, either in Oracle VM VirtualBox's own Virtual Disk
Image (VDI) format, or in the third-party formats listed in Section
5.2, “Disk Image Files (VDI, VMDK, VHD, HDD)”."
But this might be too narrow a description, as you see a Debian ISO as
hd0. On the other hand you report to see ext2 on Debian's (hd0,msdos1)
which is very strange, because Debian amd64 ISO images mark their
ISO 9660 filesystem in partition 1 and their EFI FAT filesystem in
partition 2. ext2 is not included in theses iamges:
Drive current: -indev 'debian-12.2.0-amd64-netinst.iso'
...
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x80 0x00 0 1286144
MBR partition : 2 0x00 0xef 4476 18976
MBR partition path : 2 /boot/grub/efi.img
So my best guess is still that Virtual Box concludes from the bootable
MBR for Legacy BIOS and the EFI System partition that the Debian ISO
is to be handled as virtual hard disk.
Consider to try with an original grub-mkrescue ISO whether Virtual Box
is willing to present it as (hd0).
> When I do an "ls" on hd0 in the grub prompt it is gives a message No
> known filesystem type detected, as I indicated in the earlier part
> of the mail, that hd0 was created by virtual box.
So (hd0) has nothing to do with the ISO.
We should ignore it for now and hope that it will not appear if you
manage to talk Virtual Box into handling the ISO as hard disk.
----------------------------------------------------------------------
Now for the partition riddle with your ISO.
Your attached file has these lines:
Drive current: -indev 'final.iso'
...
Media summary: 1 session, 14808 data blocks, 28.9m data, 51.5g free
...
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x00 0x83 0 59232
MBR partition : 2 0x00 0x83 59232 2097152
Partition number 1 is obviously the ISO 9660 filesystem.
You did not append it but implicitely allowed it to exist by appending
disk.img as partition 2.
The sizes match: 14808 * 2048 = 30326784 = 59232 * 512
You see it in GRUB as (cd,msdos1).
Partition number 2 is most probably your appended disk.img.
If you look at it by GRUB i expect that you see the files of your ext2
filesystem.
Please verify that this expectation is true.
----------------------------------------------------------------------
Debian aspects:
> for a debian ISO that i downloaded, i see that there is an appended
> partition that is appended to hd0 --> (hd0,msdos1) an "ls" on
> (hd0,msdos1) reveals it is a ext* partition.
> i guess this is where it stores the root file system.
Original Debian ISOs have no ext2 filesystem.
The root directory after booting is the root of the ISO 9660 filesystem.
> i am trying to build an ISO for my application environment that uses a
> much older version of Debian and it has dependency on Ruby, mysql....
> etc dependent libraries that i need to include along with the OS.
Off topic idea as last resort, maybe not suitable for your goal:
If nothing else works for you, consider repacking a Debian ISO of that
old version with its original boot equipment and further software added
by you.
See
https://wiki.debian.org/RepackBootableISO
Old ISOs are at
https://cdimage.debian.org/mirror/cdimage/archive/
Have a nice day :)
Thomas
