Persistent partition between boots

[shasheene]

Users have regularly called for Rescuezilla to adopt a persistent partition to maintain files between boots.

This could be used to hold network configuration (static IP, wifi passwords etc) to make using Rescuezilla more efficient, particular for use in IT roles.

This is an interesting idea that is worth pursuing. Please post a reaction on this post if you would like this feature, as right now, it's very low priority.

There are security aspects to a persistent partition that need to be deeply considered. Alternative approaches include looking for another storage medium (eg, CD or second USB stick), and checking if contains a file (let's call it rescuezilla.cfg) in the root directory.

[shasheene]

A user named "coth" in a now-unavailable comment on the AlternativeTo website wanted persistent partitions. I suggested to keep all discussion in this GitHub issue to keep the AlternativeTo comment section tidy.

Coth writes:

Then, may be, if possible, some edit mode to boot directly from USB without RAM to preinstall apps.

My response:

Your suggestion is difficult, but possible. Just like other Linux live environments, Rescuezilla's root filesystem is a SquashFS compressed archive, which is not trivial to modify if Rescuezilla is booted. As of writing, the easiest way to "bake in" new applications into a Rescuezilla ISO image is by adding the package to the build script and building a completely new custom ISO image. This is not easy enough for the many home users who have customization requirements but do not have the skills to build an ISO from scratch (and be satisfied that their custom ISO image was made correctly).

The persistent partition goal is achievable with a significant change to Rescuezilla's standard live environment architecture. Instead of an ISO9660 image containing a SquashFS root filesystem, a Rescuezilla image could be very similar to a regular uncompressed Linux hard drive. That is, using an EXT4 root partition. To create an immutable live environment, the typical boot would then have the fsprotect enabled via a kernel parameter in the default boot menu item. This would make the root partition mounted as read-only with a copy-on-write RAM overlay. A second boot menu item without the fsprotect kernel option then boots the system in read/write mode without this overlay.

[regs01]

Well, i said if possible. As there are many reasons for that - ability to save settings, ability to install and update apps right on place. But of course there are far more important things - like stable backup and restore in any conditions and optional EFI boot.

Still, can you point to how "bake in" apps?

[shasheene]

Still, can you point to how "bake in" apps?

The build instructions provides a basic overview on how to build Rescuezilla ISO images from source. Adding a new package requires first git clone'ing the rescuezilla repository, then git checkout the most recent tag (1.0.5 right now), then modifying the package list in the file chroot.steps.part.1.sh (taking care to preserve the use of trailing backslashes to escape the newlines). Then adding your changes to a new git commit, and finally using make to build a brand new ISO.

The resulting ISO image will be the same as the official release, but with slightly newer packages (due to a more recent apt-get update). The will also contain a version string like 1.0.5-1-g7db66e, indicating that it is based on a single commit beyond the v1.0.5, and the build associated is with the git commit SHA 7db66e. This version string is currently written into the same directory where a backup is made, and will be processed by future versions of Rescuezilla so it knows "this backup was created by a v1.0.5 compatible version of Rescuezilla". Other than that, it should be identical to the official release.

For thoroughness I will mention that a custom Rescuezilla ISO image can be analysed using the script extract_and_checksum_iso.sh in the root of the git repository, which helps compare it to the official Rescuezilla v1.0.5 with the help of the meld diff'ing tool.

Anyway, the process is relatively involved so I think only IT businesses using Rescuezilla heavily will go to the effort to customize the ISO images. Also to anyone reading this, if something like a new package is useful to the general Rescuezilla userbase then please push your commits to your Rescuezilla fork and then create a Pull Request, so it can be merged in and help everybody.

[shasheene]

(Please ignore the reference to issue 108 immediately above this comment. I mistyped a comment in that issue)

[shasheene]

To re-iterate, the currently officially recommended tool to write Rescuezilla images onto USB sticks is balenaEtcher, which simply directly writes the Rescuezilla ISO image file directly onto a USB stick. Rescuezilla boot media made in this way don't have persistent partitions because the filesystems used internally are read-only and the lack of a partition table means new partitions cannot be added.

In this GitHub task I was suggesting to modify the Rescuezilla build scripts to enable persistence, but a user named Julia has brought to my attention that Rufus is able to create persistent USB sticks from arbitrary Debian/Ubuntu ISO images. From the Rufus ChangeLog.txt:

o Version 3.7 (2019.09.09)
Finalize persistent partition support for Debian and Ubuntu [EXPERIMENTAL]:

• Debian with persistence should work out of the box with any recent "Debian Live" ISO.
• Ubuntu with persistence should also work IF using a post 2019.08.01 ISO. Note that,
  because of bug #1489855, trying to use persistence with Ubuntu ISOs that were released
  before August 2019 will only result in rescue mode during boot - You have been warned!
• Other distros may work with persistence as long as they use a Debian-like or Ubuntu-like
  method, and, in the case of Ubuntu-like, if they use casper with the #1489855 bugfix.
• Persistence and ext formatting support should still be considered EXPERIMENTAL at this stage.

This Rufus feature effectively implements this issue but without modifying the build scripts: Rufus creates a FAT32 root filesystem on the USB stick and extracts the Rescuezilla files, and a storage partition with an ext3 filesystem, then installs GRUB to make the stick bootable.

However, as of writing, the Rufus persistent partition is not usable by the Rescuezilla v2.0 frontend because the ext3 filesystem is being automatically mounted as the /var/log folder (task #130).

It's also worth noting that Rufus is only available on Windows systems, and for Windows/macOS user reading this, I should probably highlight the method described above is creating an ext3 filesystem, which is not recommended for non-Linux users because it won't be easily accessible on Windows/macOS systems without using a third-party filesystem implementation (which is risky).