OT: debian live-file-iso change in chroot?

[Hans]

Hi folks,

today I have a little bit OT-question, maybe someone did this before.

I want to change an ISO-file of a livefile (in my case it is a kali-live,
which is based on debian).

Instead of building it from beginning on every time new packages are
available, I had the idea, to boot the ISO in a chroot environment, then
upgrade the booted ISO via apt, and at last save the updated livesystem as an
ISO-file again.

Is this possible?

I want to spare and shorten the time for download, unpacking, installing,
configuring and ISO-creating of the whole system, as I believe, doing as I
imagine will be done in about 15 minutes, whilst creating a fresh one lasts
about several hours.

Did someone do that already or is my idea technical impossible at all?

Thanks for reading this.

Best regards

Hans

[Thomas Schmitt]

Hi,

Hans wrote:
> I had the idea, to boot the ISO in a chroot environment, then
> upgrade the booted ISO via apt, and at last save the updated livesystem as
> an ISO-file again.

This might give you the desired data content or not. I could imagine
stumblestones but have no experience with such an operation.
The booted system might be a wild mix of files from the ISO, from the
initrd, temporarily generated files, and pseudo files like in /proc.

Further you might have to authorize your newly installed packages by
checksums or signatures. For that you will have to ask Kali people.

In any case you will have to pack up your manipulated file tree to the
ISO so that it is bootable. Probably i can help with that aspect. For
Debian ISOs i wrote
https://wiki.debian.org/RepackBootableISO


Let's have a look at the current boot equipment of Kali amd64 ISOs:

wget https://cdimage.kali.org/kali-2022.3/kali-linux-2022.3-live-amd64.iso

xorriso -indev kali-linux-2022.3-live-amd64.iso \
-report_el_torito plain -report_system_area plain

yields

Volume id : 'Kali Live'
El Torito catalog : 2080 1
El Torito cat path : /isolinux/boot.cat
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x0000 0x00 4 2529
El Torito boot img : 2 UEFI y none 0x0000 0x00 1792 2081
El Torito img path : 1 /isolinux/isolinux.bin
El Torito img opts : 1 boot-info-table isohybrid-suitable
El Torito img path : 2 /boot/grub/efi.img
System area options: 0x00000102
System area summary: MBR isohybrid cyl-align-on
ISO image size/512 : 7458904
Partition offset : 16
MBR heads per cyl : 228
MBR secs per head : 32
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x80 0x17 64 7456448
MBR partition : 2 0x00 0x01 7456512 1792

So it boots from DVD on Legacy BIOS and UEFI. For booting from USB stick
i see only the official opportunity to boot via Legacy BIOS and EFI in
legacy CSM mode.
But, as Pete Batard of Rufus relentlessly points out, all known EFI
implementations would boot not only from an MBR partition of type 0xEF
but also from any other MBR partition type which contains a FAT filesystem
with a file \EFI\BOOT\BOOT*.EFI which matches EFI's idea of the present
processor type.
Peeking ahead, it turns out that partition 2 contains BOOTIA32.EFI for
32-bit x86 and BOOTX64.EFI for 64-bit x86.

Kali is so nice to include like Debian a file with the program name and
arguments which were used to pack up the ISO:

sudo mount kali-linux-2022.3-live-amd64.iso /mnt/iso
cat /mnt/iso/.disk/mkisofs

yields (in one single line):

xorriso -as mkisofs -R -r -J -joliet-long -l -cache-inodes -iso-level 3
-isohybrid-mbr /usr/lib/ISOLINUX/isohdpfx.bin -partition_offset 16
-A "Kali Linux"
-p "live-build 20220505kali1; https://salsa.debian.org/live-team/live-build"
-publisher "Kali" -V "Kali Live" --modification-date=2022080415360800
-b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot
-boot-load-size 4 -boot-info-table -eltorito-alt-boot
--efi-boot boot/grub/efi.img
-append_partition 2 0x01 binary/boot/grub/efi.img
-o live-image-amd64.hybrid.iso binary

"binary" was the directory name where the tree of files was prepared.
As stated above, i am unsure which path you should give when packing up
the manipulated Kali system.

/usr/lib/ISOLINUX/isohdpfx.bin is installed by Debian package "isolinux".
But you may also extract the first 432 bytes of the original ISO:

dd if=kali-linux-2022.3-live-amd64.iso bs=1 count=432 of=kali_mbr.img

and then use it by

-isohybrid-mbr kali_mbr.img


We learn that partition 2 holds a copy of the same image efi.img which
is also offered by the El Torito boot catalog.
The latter is a file in the ISO:

sudo mount /mnt/iso/boot/grub/efi.img /mnt/fat
find /mnt/fat

shows
...
/mnt/fat/EFI/boot/bootia32.efi
/mnt/fat/EFI/boot/bootx64.efi
...
/mnt/fat/boot/grub/grub.cfg

So it is very likely that the EFI ifirmware of an amd64 machine will
detect partition 2 as bootable, although it does not have the officially
specified partition type 0xEF.

-------------------------------------------------------------------------

If you would only want to add some files to the ISO's tree, then it
would be possible to do this by a single xorriso run:

xorriso -indev kali-linux-2022.3-live-amd64.iso \
-outdev changed-kali-linux-2022.3-live-amd64.iso \
... xorriso image manipulation commands like -map, -rm, -mv ... \
-boot_image any replay

I tested that xorriso-1.5.0 of Debian 10 and xorriso-1.5.2 of Debian 11
both detect the need of the same xorriso commands for the final replay of
the boot equipment, as the current release xorriso-1.5.4 does.
xorriso-1.4.6 of Debian 9 is too old.

If you can't get xorriso >= 1.5.0 you may download and build

https://www.gnu.org/software/xorriso/xorriso-1.5.4.pl02.tar.gz

according to "Compilation, First Glimpse, Installation" in

https://www.gnu.org/software/xorriso/README_xorriso

Installation is not needed, if you can live with using a long program path
like "$HOME"/experiments/xorriso-1.5.4/xorriso/xorriso .


Have a nice day :)

Thomas

[Hans]

Am Samstag, 22. Oktober 2022, 12:19:31 CEST schrieb Thomas Schmitt:
Hi Thomas,

thanks for the very large and very usefull information. However, it looks not
easy and requires lots of effort.

I thoughtm I could boot a livefile, then update it, then repack it as a new
iso. When thinking it over, I believe, this will not be possible, as a booted
live system is putting a lot into memory by default, and so it would not work.

I also thought of usinng some virtual system, like virtualbox, quemu or
virtual-manager. This would work, but virtualbox for example, can only export
to an OVA-file, not to an ISO. I know, one can convert OVA to ISO, but this
might be create new issues.

Lastly I would stay with live-build, this is lasting a long time, but it
works. Additionally I will contact the kali-people, because there is some
issue with their repo, I believe. As I do not want to download every(!)
package from the repo again and again, I am using apt-cacher-ng. But since
several months thisis not working any more. At not explainable reasons
sometimes I get errors by downloading the packages saying, there is a ggp-key
nismatch of the package. Deleting the whole cached packages on my system and
download them freshly shows no error. Still could not discover, why this
happens. It looks like the package-ggp-keys are not updated. Something with
the repo, that I could not fix.

This above was the reason, that I looked for another way, not to download
everything again and again, and so I came to the idea with the iso.

I could file a bugreport, but the kali-people are very busy and I believe, I
am the only one, who is creating his own kali-live (and mine is not the
standdard one, mine has a lot of packages added, it is in German and there are
third party packages added). And so, and this is very understandable, they do
not much care of the special problem of one single user.

So, thank you very much for your help, I will read this carefully to
understand everything.

Best regards and happy hacking!

Hans