______
TLDR PREAMBLE
In anticipation of possible community questions I included a large amount of background information below the line of Mr Green emogis. My comments above Mr Green regard my ongoing frustrations with backing up in LM and other Linux distros. Maybe it will help others, or at least be internally therapeutic to myself.
My summary of rEFInd installation in the last section ("THIS WEEKEND" below the laughing-blushing emogis) is more condensed than anything else I found on the web for rEFInd. It probably should be a separate post, but I found stepwise instructions were relevant to the earlier parts of this post. rEFInd is terrific for those willing to invest the time in setting it up – a pleasant alternative to GRUB, though the two can easily be made to work in tandem. I find it is useful being able to access GRUB features without seeing GRUB at every boot.
Please accept this wall-of-text as positively intended. We are in a moment when LM 22.x is about to be released. Hopefully 22.x may solve more problems than it creates.
______
THE GRIEVANCE
I have ongoing problems reinstalling Linux Mint onto Clonezilla-cloned LM volumes. Other Linux distros generally do not seem to suffer as badly from this inability, or at least I had better success reinstalling the OS on these two: KDE Neon and Manjaro KDE.
The Linux Mint Installation Guide suggests installing onto a preexisting LM root volume may be possible without destroying its data, but I have not had success doing this with recent .ISO installers:
The LM Guide is vague regarding details, and there don’t seem to be any Youtube videos or other links that I found regarding LM reinstallation. I did find an old YT video for Arch installers. Some screenshots in the article would be helpful.
Fom the installation guide:
My Linux Mint challenge boils down to my inability (or ignorance of how) to reinstall the OS from a live .ISO onto a previously cloned Linux Mint installation, while also preserving its home folder, installed apps, installed libraries, root preferences, etc. This type of reinstallation is accomplished with better success in other distros using the Manual Partitioning option – which is located on the installer screen below “Install Alongside,” “Replace a Partition,” and “Erase Disk.”“Warning – This is not recommended for novice users. A misstep during the installation could wipe all your data. Always make backups, make sure to select the right partitions and to carefully review formatting options.”
I don’t see Manual Partitioning as an option in the LM installer. The “Something Else” option does not seem to work quite the same way as the Manual Partition option in other distros, or at least it did not do that for me. Here is what I have been doing so far, which has NOT been working well…
When I go through the “Something Else” pathway, selecting the volume under “Device” list in the “Installation Type” screen, I bring up the “Change” Box and switch the “Use as:” To Ext4 journaling file system, then set the Mount Point to / . I choose the boot loader installation destination and click the “Install Now” button, then I receive a warning box:
The warnings are legit. I destroyed multiple test volumes.“Do you want to return to the partitioner? The file system on /dev/nvme01n1p3 assigned to / has not been marked for formatting. Directories containing system files (/etc, /lib, /var, …) that already exist under any defined mountpoint will be deleted during the install. Please ensure that you have backed up any critical data before installing.”
I realize Linux Mint is geared toward providing a simple front end for beginners and low intermediates, however in this instance (reinstalling the OS over an existing LM volume) the installer is unhelpful in accomplishing what I perceive is a basic end-user-goal: reliable boot volume replication.
I have tried to adjust my thinking to not wanting a reliable pat to boot volume replication, but I simply cannot find a way to think that way after decades being spoiled as a Mac OS customer... and now a spoiled former Mac OS customer.
By contrast, Mac users have taken for granted for decades a reliable OS upgrade-downgrade pathway, within reason, mostly with data preservation. (Yes, Apple messed up my iTunes library with its Music app a few years ago – but that is another story.) Generally when I download a Mac OS installer and run it, my data is preserved – reliably and through decades of OS updates. Some Mac apps may not run under a particular OS, but the user data and apps are still there and, most importantly, the OS actually boots. This experience lies in stark contrast with transitioning through multiple Linux distro versions (or even reinstalling the Linux same version). Sadly LM seems more adversely impacted for me than other Linux distros I tried.
Before people tell me to use TimeShift, BackInTime, Deja-Dup, Grsync, Foxclone, Kbackup, Butterfly Backup, etc – please know I have tried them and found each one lacking in some important ways. Not wanting to throw stones at people who are doing the best software development they can in a free & open source environment (and lacking the coding skills to do it myself) I find the lack of reliable or simple bootable volume preservation solutions to be the Achilles heel of Linux.
TimeShift, BackInTime and grsync all look wonderful before an actual failure happens. The problem is when the user tries to recover his or her data to another volume after a failure and then suddenly realizes the agony of an unbootable destination volume and effectively unusable “backup” data… extremely frustrating.
Deja-Dup (a duplicity wrapper) comes closest so far to providing a workable solution, but I have not yet found a reliable way with it to get my LM volumes back to how I left them prior to planned or inadvertent destruction of my test-environment volume. At best, Deja-Dup / duplicity recovery requires a lot of monkeying around afterward reinstalling libraries by hand, reinstalling apps, manually changing root preference files… many hours of effort if I can even remember how to do it again (fortunately I keep notes.) Too often, Duplicity puts up permissions warnings for components numbering in the hundreds. Those files and folders don’t get transferred, so for all intents and purposes they are lost.
______
THE RANT - please skip unless you want to know why I am writing so much here – perspective of a Mac OS switcher
I am writing candid and frustrated observations after months of experimenting with Linux distros including LM. I hope I do not make an ass of myself in these comments. I am hoping to help others avoid some of the mistakes I made, or at least know what they are getting into. This LM community has been amazing, and the main reason why I keep coming back to Linux Mint.
I want to be able to preserve my user data through time without jumping through so many hoops, but I am not seeing the hoped-for simplicity or reliability of data preservation in LM. While I may find current versions of other distros slightly better in a particular regard to re-installation, none comes close to the elegance of MacOS backup solutions – such as my all-time favorite MacOS rsync wrapper… SuperDuper! Nothing seems to be like it in the Linux world.
My 2012 Mac Mini keeps running like a perpetual motion machine… but its days are numbered. Bloated web design, lack of modern browser support for old Mac OSes, and increasing numbers of apps no longer supporting it leaves this nine year old computer running on borrowed time.
I would like to complete my Mac OS transition into Linux and repurposes the old Mac Mini as a Linux file server, but I need more reliable Linux backup solutions before I can do so. I already wasted a LOT of time reading and trying everything I could think of (and write about it) to get Linux bootable backups to be a reliable process like SuperDuper!, or anything at all that works consistently-and-reliably, month-in-month-out.
Please excuse this TLDR and likely typos. I am working from memory regarding a convoluted seven month Mac-into-Linux journey:
THE HISTORY OF THIS JOURNEY
Background info #1: I am a Mac OS guy since 1985, and Apple ][ owner starting in early 1980. I became disillusioned with Apple’s business model over the past 15-20 years, with their attitude toward Apple customers, with their destruction of the Mac ownership model, and with leadership’s sketchy philosophy involving individual privacy – especially in parts of the world where it is most critically needed (ie, everywhere).
I joined the Linux community in early November after I bought a HP Dev One laptop. It had a Ryzen 7 CPU, a decent screen, a decent trackpad, reasonable gen 3 NVME bus, usb-c , SK_Hynix 1 TB SSD, 16 GB Samsung RAM, and a decent keyboard with a super key. I upgraded the SK_Hynix to a 2 TB Samsung 970 Ev, which worked reliably without generating excessive heat. I upgraded to 64 GB G-Skill Ripjaws RAM. I installed Linux Mint.
Background #2: The Dev One was an HP Elitebook at a ~ $1000 price in November, with PopOS! preinstalled and no Windows OS. Sadly the Dev One project was axed by HP in January. A lovely machine, it only had a single hardware production run in June, 2022. I have reasonable guesses why HP decided not to continue with a Dev Two… Dev One was a great idea from the buyer’s standpoint but [my conjecture only] it may not have been good for HP’s bottom line. There were probably a bunch of other reasons too.
Background #3: I started my Linux journey a few years ago running Ubuntu in a VM on my Mac, but I quickly abandoned it because it did not do much for me at the time and I was busy. I had some Unix experience in the 1980s - VMS / DEC PDP 11, DEC's shortlived PC, BSD Unix (Mac) then Darwin, but I never became a Unix guru.
Background #4: In November, 2022 I tried PopOS! for about a week before distro hopping, first into Linux Mint, then multi-partition booting into about a dozen other Linux distros. Most distros had one shortcoming or another which made them not worth my time to continue. In the process of distro-hopping, I experienced several wiped volumes, had numerous GRUB issues, hair-pulling over Linux backup methods, black-screen boot, etc. Eventually I learned how to solve most of my booting issues and not destroy my volumes as often. Nothing about it has been particularly life affirming nor life ruining except too much ‘wasted’ time, the famous Linux learning curve.
Background #5: I do not have Widows OS on my current SSD, nor did I ever have Secure Boot. Dev One is a non Windows machine on which I can optionally boot into Windows when I need to update hardware drivers or run Windows only diagnostics. In these situations, I boot from an external SSD using WinToUSB. It makes Windows volumes externally bootable.
Early-2023: I settled on three Linux distros since November-December which I have been running in adjacent partitions, and which I prefer to the others:
(1) LM Cinnamon 21.1
(2) KDE Neon (plasma)
(3) Manjaro KDE (plasma)
I am happy with the plasma development direction and philosophy, and with their software distribution methods. I really like KDE and the Dolphin file browser. Dolphin browser sorta works in LM but it’s kludgy. K apps are easy to add to LM via the repository, but Dolphin browser never fully integrates.
Unfortunately bleeding edge distros such as KDE Neon and Manjaro are fraught with breakage, which is where the updated twice per year LM normally shines.
THIS WEEKEND:
I installed rEFInd Boot Manager by Roderick W Smith. I won’t go pros/cons of rEFInd because it is another subject, but my installation method was straightforward and I am mostly happy with the results – except for an unworkable Linux Mint after step 7:
(1) Booted into Manjaro KDE from an external volume, I formatted a newly installed 2TB Samsung 970 EVO SSD using the Disks app.
(2) In Gparted I created a GPT partition table on the new SSD (Device > Create Partition Table > gpt). Gparted put up a box – “WARNING: This will ERASE ALL DATA on the ENTIRE DISK.” I clicked OK.
(3) In Gparted I created a 194 mb partition #1 named ESP in fat32 format. This is where EFI data & rEFInd was to be located after step #5.
[Some sources claim 250 mb is necessary, however I believe anything over 150 mb is overkill. After many , Disks app reports my 194 mb ESP partition is only 3.3% occupied.]
(4a) Using Mr. Smith’s instructions and other forum guidance, I installed rEFInd from the terminal.
(4b) In retrospect, I found an easier way to install rEFInd –- using Manjaro’s Add/Remove Software repository, I installed the manjaro-refind-installer package (+) refind-drivers package. I cannot say whether the separate refind-drivers package made a difference but it was small, so who cares?
(5) In the terminal I typed:
Mr Smith’s scripts took care of the rest.$ refind-install
(6) I rebooted into my Ventoy USB flash drive and installed Manjaro KDE from the 22.1.3-230529 .iso live image onto my new SSD, then booted into the newly installed Manjaro. I updated the OS, installed Disks app, installed Gparted, installed Deja-Dup, rebooted and cleaned things up. I imported my Manjaro KDE backup using Deja-Dup and manually reinstalled a number of other apps that were missing.
(7) I used Clonezilla live .iso (Ventoy USB) to clone my Linux Mint and KDE Neon volumes from the old SSD to the new SSD.
(8) Rebooting back into the new SSD’s Manjaro KDE, I typed in Terminal:
(9) Repeated attempts to boot into the cloned Linux Mint and KDE Neon from GRUB or from rEFInd on my internal SSD consistently failed. the emergency boot routines were unable to fix problems enough to get to a bootable OS.$ sudo update-grub
(10) I booted back into the Ventoy USB and reinstalled KDE Neon via neon-user-20230602-0716.iso This seemed to work pretty well to bring me a bootable KDE Neon internal volume.
(11) I still have an unbootable Linux Mint clone, which is the main point of this post. Thankfully, I can still boot my original LM volume (slowly over usb-C) on an external SSD.