Having just about recovered from nearly trashing my email setup, I was left with a problem. The machine I use 90% of the time [using it to type this] was running the older Mint 18.3, with a version of Claws-Mail I could not use any more… What to do? Well, the obvious answer was upgrade Mint to 19.0…
And to do this, the Mint Team have produced a helpful and very short, slick automated upgrade utility. So I downloaded and launched it, but the first thing it wanted me to do was to perform a local backup, using “TimeShift”, the integrated system backup utility. I tried. Unfortunately, my system was demanding 19.4Gb of space for a single backup – and the largest ext4 partition on my system is 16Gb. Ain’t gonna happen.
Still… the process looked pretty easy. What could possibly go wrong???
Um: everything? At first the update went very smoothly… All files downloaded and checked out. I ran all the “test” scenarios and saw no issues being flagged. All looked good. But when it came to the “point of no return”: disaster. The upgrade process got itself into a loop because of unfulfilled dependencies and eventually crapped out on me.
This particular machine happens to be a system that dual boots with Windows 10… I needed to have this working properly. Nothing to it, then, except to upgrade the old fashioned way, by using installation media and over-writing the 18.3 system from scratch.
A process which blew up on me just as it was attempting to write the boot-loader [the system startup file] to disk. And, just to make me happy, it did this in a way which trashed not just the Mint system, but Windows 10, too.
Dead system. Deceased. Monty Python Dead Parrot sketch. You get the idea.
Oh crap: now what? Well, it turns out that I wasn’t the first to have this issue with grub. Mint spotted the problem and updated their ISO file… I was trying to use v1, not the later v2. So: boot to another machine; download the v2 image file; attempt another installation using v2 and…. I have a fully recovered, fully working machine.
In fairness, if that had failed, I could have recovered with a complete wipe of the entire SSD, a re-install of Windows 10 and then a clean install of Mint 19.0. But, with much of the licensed software on the Windows image having number-of-installation restrictions, I really didn’t want to have to do that if I could avoid it.
Thanks, Mint Team, that was close.
And: I know trouble comes in threes… but I think two scares is entirely enough for me to be getting along with for now. Thanks.
I dropped a brief email to Tony George, the author of the Timeshift archive utility, to ask him if there was something I was doing wrong that prevented the utility from “seeing” the NTFS partition contained on this particular machine.
It turns out that Timeshift needs and uses meta-data that it obtains from the ext4 file system. NTFS literally doesn’t store the attributes that Timeshift needs, hence Timeshift can’t work with NTFS volumes.
Good to know, although I now need to decide if I’m going to replace the single large NTFS volume in this machine with a pair at half that size, one still NTFS and one as ext4. It kinda makes sense.