Well, That Was Close! (Part 2)

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.

Bother.

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.

FootNote:
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.

Well, That Was Close! (Part 1)

As a user of Mint Linux for many years now, I’ve become somewhat familiar with the upgrade process needed to switch between successive versions.

So when Mint 19.0 was released, the first thing I did was drop a spare SSD in to my PC and install a copy. Effortlessly easy process [done in under 15 minutes] and with a very slick, polished result. Except. One of the applications I tested happened to be my email client of choice, Claws-Mail.

Obscure, old-fashioned in the extreme, this client can’t even handle proportionately-space fonts, never mind HTML or any embedded content. It won’t even launch helper programs to handle attachments without being specifically told what to do. So why use it? Simples: it’s absolutely bullet-proof secure. There isn’t a lot of damage you can do with simple text files – and anything that isn’t simple text is just ignored by Claws.

So I tested Claws under Mint 19 and it worked like a charm. But when I went back to my regular desktop and tried Claws under Mint 18.3, I got an issue whereby any time I tried to do anything, I had to re-enter account passwords. Ulp.

Knowing that I’d allowed the upgrade to 19.0 to make some kind of unknown change to my shared config files, I found my way to the #claws IRC channel and asked politely for help.

Step up the awesome Ticho, who wasn’t just incredibly patient with me, but also had extraordinarily detailed knowledge of the workings of this mail program. The fix required me to back up my key mail folders, make some manual changes to a critical configuration file, then switch permanently to the newer version of Claws that ships with Mint 19.

All told it took an hour or so to fix, but the process was never especially “dangerous” and was completed without so much as a hiccup.

Eternally grateful to Ticho for their wonderful assistance – and, best of all, I am free to carry on using Claws Mail.

Incompetence Comes As Standard

Back in March of this year, Windows 10 updates caused massive disruption to all three of my Windows 10 builds. (All are Pro/64-bit). All are paid-for licenses.

The two with major impact are used for gaming and office tasks on my more powerful, water-cooled “gaming” system.

You can read about the sundry disasters here. They key point to note being that:-

  • The “Office” machine suddenly stopped recognising one of my 3 Dell Monitors. The unit that “vanished” was connected to my nVidia 1080GTX via a “DisplayPort” connector
  • The “Gaming” machine just, well, stopped, with all 3 monitors remaining dark, despite the fact that “windows sounds” indicated that the machine had booted successfully.

But wait! Isn’t that exactly the same ####ing thing that has just happened with the latest update? Why yes, I do believe it is.

So… having completely ####ed up two of my builds in March, causing me extensive down-time and a nightmare of an issue with getting my Omnipage OCR software re-activated [it somehow thought I had installed it twice already, which I hadn’t], it looks as though I could well be left with a repeat of that experience just 4 months later.

It isn’t as though I’m able to telepathically know in advance that the update is going to be applied [and stop it]. With Microsoft’s new updating mechanism, I have no ability to determine what gets updated, or when.

All I’m left with is [literally] a box of bits. With no Operating System, the hardware doesn’t exactly do much. This is entirely, completely and utterly unacceptable. In my case, Microsoft can’t resort to, “Well, it was free…” because I had to pay for both licenses. £200 each, thank you very much.

They don’t even provide direct support – oh no – if you go to their support forums [ “http://support.microsoft.com/”] you are left dealing with volunteer MCPs. Don’t get me wrong – the people I’ve dealt with have been excellent – patient, friendly and helpful. But that doesn’t excuse Microsoft from shipping sh1te product.

Microsoft: Incompetence Comes As Standard.

Scummy Scammers

Yesterday morning I received an email claiming to come from a “WannaCry Hack Team”. WannaCry, you may remember, is the name of the cryptographic malware that locked away files on hundreds of thousands of computers worldwide.

Here is the text of the email I received:-

“Hello! WannaCry is back! All your devices were hacked with our program installed on them. We have perfected operation of our program, so you will not be able to restore your data after the attack.
All the information will be encrypted and then erased. Antivirus software will not be able to detect our program, while firewalls will be marrowless against our unique code.
Should your files be encrypted, you will lose them forever.
Our program also covers the local network, erasing data on all network-connected computers and remote servers, all cloud-stored data, and freezing website operation. We have already deployed our program on your devices.
Deletion of your data will take place on June 22, 2018, at 5:00 – 10:00 PM. All data stored on your computers, servers, and mobile devices will be destroyed. Devices working on any version of Windows, iOS, macOS, Android, and Linux are subject to data erasion.
So as to ensure against data demolition, you can pay 0.1 BTC (~$650) to the bitcoin wallet:16xFDaKkqZ7KMJbUu3aA8ZjMYF3GBywmWw
You must pay at the proper time and notify us about the payment via email until 5:00 PM on June 22, 2018. After payment confirmation, we will send you instructions on how to avoid data erasion and such situations at any time thereafter. In case you try to delete our program yourself, data erasion will commence shortly.
To pay with bitcoins, please use localbitcoins.com or other similar platforms, or just google for other means. After payment write to us: support_wc@bitmessage.ch “

To be clear, this is utter garbage.

WannCry, once it is active, puts up a very large, very clear “lock screen” when a user switches on their computer. You can see an example of it here.

It looks as though this email was being sent in the hope that it could act as a confidence trick… to fool people into sending money to a random bitcoin wallet.

In the event that you get either an email or a warning message on your computer, can I suggest that the first thing that you do is reach out to a computer specialist that you trust, and get them to take a look. It would seem that we’re now moving in to time where people are using psychological tricks into separating you from your cash.

Be careful!

Update: confirmed scam. See here. Bastards.

When It Ain’t Broke – systemd and Unavailable Drives

I’ve been using Mint Linux since some time in late 2013, early 2014, when I saw what a complete and utter disaster ubuntu were making of their distro with the 12.10 and later releases.

I’d been using ubuntu since some time in mid-2005, experimenting with 5.04 Hoary Hedgehog before getting serious with 5.10 Breezy Badger.

Prior to that I had used Mandrake Linux [a Red-Hat based distro] which eventually merged with the Brazilian Connectiva to form Mandriva, but which ultimately whithered and died.

And before that I’d actually bought one of the first packaged versions of Red Hat (2.1 Bluesky, which shipped in 1995 and ran kernel 1.2.13…

So: a while…

I’m a fan of Mint; they have worked hard to take all that is good about ubuntu, but drop the horrible succession of ubuntu desktops [starting with Unity] and made a clean, simple, solution.

All has been well in Mint world. At least, mostly. I first downloaded [and still have the ISO for] “Maya” (Mint 13, released May23rd, 2012) and got terrific stability from all versions up to Mint 17.3, Rosa, released on December 4th, 2016. Then things got weird.

The next major release of Mint (18.0/Sarah, 18.1/Serena and 18.2/Sonya) were all desperately unreliable and buggy [for me, at least]. It turns out that chief among the problems with this latest edition were changes brought by the introduction of systemd, a component of the system which manages the boot process.

Rather than follow the traditional unix philosophy of writing “small, sharp tools”, which “do one thing, but do it well”, the designers of systemd have produced a godawful mess of bloatware that makes a mess of lots of things. It writes binary logs [so if you’re system won’t boot, you need special tools to parse log files]; it over-rides audio settings [because it knows better than you do where your speakers are connected]; and it has unilaterally changed the way that a booting system interprets the contents of the “fstab” file system table file…

In simple terms, if you have a machine which expects to mount a remote nfs partition, systemd will deem that to be “mandatory” unless you tell it otherwise, in complete contradiction to the way that sysvinit [ the old boot manager] works. Which means that migration from sysvinit to systemd requires you to figure out and then edit a bunch of changes in to various configuration files.

Because, of course, the authors of systemd refused to interpret configuration file parameters “as they had been written” and instead unilaterally decided that earlier interpretations of parameters “were wrong” and that they would just fix everything. OK, a tidy-up is understandable. IF said tidy-up comes with a warning, a migration tool, or useful hints. Nope. Zip. Zilch. Nada. Nothing.

You go figure it out. Your computer, meanwhile, won’t boot if any of your declared file systems are missing. Rather than “boot with error message”, the new model is “don’t boot”. Rather than warn you that your file system config needs to be amended, the new model is “go screw yourself.”

for anyone struggling with this issue, the answer is to insert the following text into the parameters of the fstab mount string:-

nofail,x-systemd.device-timeout=5

such that,

192.168.1.41:Public /media/459 nfs rw,hard,intr 0 2

changes to look like this…

192.168.1.41:Public /media/459 nfs rw,hard,intr,nofail,      x-systemd.device-timeout=5 0 2