{{Header}} {{Title| title=Image Formats Development Considerations }} {{#seo: |description=Considerations for the default file image format in {{project_name_short}}: Is ISO a required image format, or can it be substituted by RAW images? }} {{dev_image_mininav}} {{intro| Considerations for the default file image format in {{project_name_short}}: Is ISO a required image format, or can it be substituted by RAW images? }} = Technical Information = * persistence: ** full persistence: When installing an operating system such as Debian to the hard drive when all changes persist this is defined here as full persistence. All actions such as package and kernel upgrades are trivially possible. ** partial persistence: For example, Debian supports [https://manpages.debian.org/testing/live-boot-doc/persistence.conf.5.en.html persistence.conf, a persistence volume]. [https://fedoraproject.org/wiki/LiveOS_image#Kernel_updates_for_images_with_a_persistent_overlay Kernel upgrades might be possible] but are not trivial through the normal use of the system's package manager. * ISO read-only: ISOs are primarily a read-only format. There is no way to mount an ISO as read-write and use it normally, persistently. ** Non-alternatives: There is growisofs or [https://wiki.debian.org/RepackBootableISO Repack Bootable ISO] but these cannot be used to write an ISO to USB and use it as a fully-persistent file system. * ISO compression: ** Is an .iso compressed? No, the .iso format itself does not support compression. ** So how are downloadable boot images by Linux distributions usually compressed? Inside the image (usually .iso or .img), there is squashfs.img ([https://en.wikipedia.org/wiki/SquashFS SquashFS]), which is a compressed archive. * ISO image format advantages: ** Most Linux distributions provide ISO images. Therefore, many users know what to do with these. * Non-features of ISO images: ** [[Live Mode]]: Is live mode a feature of ISO images? No. Both ISO and raw images can be booted into live mode. The image becomes read-only thanks to the boot options, the squashfs. Even an installed operating system can be opt-in booted into live mode using [[grub-live]]. = ISO Images vs RAW Images = * Disadvantages of not providing ISO images: ** usability: Some users will be confused. https://forum.torproject.org/t/regards-to-installing-tails-5-8-o-s/6346 * Advantages of RAW images / Advantages of deprecation of ISO images: ** lower development effort: *** Writing build scripts to create bootable ISO images has a high initial development effort. *** Faster build process. *** Even mkosi by the systemd project does not support ISO images yet due to the difficulty of creating (SecureBoot compatible) bootable ISO images. * mkosi: [https://github.com/systemd/mkosi/issues/1220 Support iso9660 as output format] * repart: [https://github.com/systemd/systemd/issues/28798 repart: Support booting via CD-ROM] * [https://github.com/systemd/systemd/pull/28806 repart: Make image ISO bootable if possible] * Advantages of RAW images: ** DVD support: Only ISO images are compatible with optical media. However, DVD drives are rarely used nowadays. ** read-write support: An image written to USB can be fully persistent. = Image Compression Issue = If images are compressed (for example to .tar.gz), this causes a usability issue. At the time of writing, no image to USB writing tool could be found that natively supports compressed RAW images except balenaEtcher, which has privacy issues, see [[Download_Security#balenaEtcher|balenaEtcher]]. The user would have to decompress the image before flashing it, which requires an extra step and is therefore a usability issue. This issue equally applies to ISO images as well as RAW images. The only other solution would be using a SquashFS but that would make the image read-only after it has been booted. Maybe the SquashFS could be persistently decompressed during the first boot? [https://github.com/systemd/systemd/issues/32714 systemd feature request: add option for persistent de-compression of SquashFS during first boot] = Image Encryption Issue = * unencrypted images: If just flashing a RAW image to USB, it would be unencrypted by default. In the ecosystem of Linux desktop operating systems, there is no in-place encryption that users could easily enable after the first boot. Encrypting an already installed system requires difficult sysadmin skills and booting from an external drive. * encrypted images: Images could be encrypted by default with a public, well-known key, and later users could be told to change the password and use cryptsetup-reencrypt. ** However, this could be a security issue if users misunderstand the security properties of such an encrypted-by-default system. ** In theory, the system could boot automatically without password entry as long as the user does not change the default password. ** This approach could confuse users who do not wish to use encryption, as it would complicate data recovery (accessing the internal hard drive after booting from an external USB) and data backups. ** reputation risk: Bad security practice with a hardcoded, public, well-known key. * maintenance load: Most likely, both an unencrypted and an encrypted image would need to be offered for download. * usability issue: When offering both types of images (unencrypted, encrypted), users might be confused. * potential solution: [https://github.com/systemd/systemd/issues/32718 systemd feature request: option to set up full disk encryption during first boot] = Future = * grml-debootstrap, the tool used to create {{project_name_short}} based images, does not support creating encrypted images. upstream feature request: [https://github.com/grml/grml-debootstrap/issues/131 encrypted VM images support] * Porting to mkosi might be an option because it supports encryption, but [[Dev/Derivative-Maker|Derivative-Maker]] has not been ported to mkosi yet. ** Does mkosi support other architectures besides amd64 such as arm64? = Comparison with Others = Tails offers .img and .iso images. Tails has a ticket [https://gitlab.tails.boum.org/tails/tails/-/issues/18055 Stop distributing ISO images]. = Goals = * The differences in the code base for Live Systems vs. Installer Systems vs. Installed Systems should be reduced as much as possible. {{quotation |context=[https://0pointer.net/blog/fitting-everything-together.html Fitting Everything Together] |quote= Live Systems vs. Installer Systems vs. Installed Systems In my model I'd like to remove the distinction between these three concepts as much as possible: each of these three images should carry the exact same `/usr/` file system, and should be suitable to be replicated the same way. So I want to provide a generic image for users to download. The image should be able to be flashed on an internal hard drive, a USB drive, on a server or anywhere else. }} * Installer specific code should be as minimal as possible. = Footnotes = {{reflist|close=1}} [[Category:Documentation]] {{Footer}}