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