Just a short note to point out that, finally, the ZFS on Linux guys have released a version which works with Fedora 27. There is therefore nothing to stop you upgrading to version 27 now (though the fact there was a month-plus wait for the v27 repository from the ZFS developers is another reminder that using ZFS on a bleeding-edge distro is not the faint-hearted!)
Just as I get Atlas working on Fedora 26, so they go and release a brand new version of it: version 27 was released on November 14th.
There is a ghastly new look (I suggest changing the default jellyfish wallpaper the moment you first log on!), but there is otherwise not a lot listed as being new in the release notes, apart from an upgrade to the latest release of LibreOffice.
Mostly underwhelming, in other words; but still just about the most functional distro out there (imho, naturally). It remains my desktop of choice, anyway. Unfortunately, I can’t actually upgrade my main desktop to version 27 because when I do, I get told:
Error: Problem: package zfs-dkms-0.7.3-1.fc26.noarch requires /bin/ksh, but none of the providers can be installed - ksh-20120801-35.fc26.x86_64 does not belong to a distupgrade repository - problem with installed package zfs-dkms-0.7.3-1.fc26.noarch
As far as I have been able to tell, this is caused by the ZFS on Linux project not having Fedora 27-compatible repositories ready -and, allegedly, they won’t have one until mid-December. So any Fedora 26 users who have committed to using ZFS for their important data won’t be able to upgrade for a few weeks. Fingers crossed for the December timeline.
My laptop doesn’t use ZFS, though, and was able to upgrade without drama.
I’ve also re-jigged Atlas, so Oracle 12c will run on Fedora 27 without too much fuss (the same need to do a software-only install that plagued version 26 also affects version 27, but the workaround previously described works for the new version of Fedora perfectly well):
Way back on July 11th, I welcomed the release of Fedora 26 and noted that Atlas didn’t run on it properly: the Oracle software would link properly, but no executables could then be run. I promised to look into it and see what I could do to come up with a fix.
Unfortunately, I reckoned without the fact that my barely-functional study swiftly thereafter got dismantled by the builders who proceeded to put down a new floor, ruin it, replace it, ruin that and finally installed a third that they managed not to screw around with! Long story short, I’ve been without functioning computers for many weeks and it’s only in the past couple of days that I’ve been able to turn my attention to the Oracle/Atlas/Fedora conundrum. (Which is a bit sad, as Fedora 27 is due to be released imminently! But better late than never, I guess…)
Anyway, it turns out that the problem concerns the new version of glibc that ships with Fedora 26. It interacts with the Oracle compiler in ways that prevent all binaries produced by the linking phase from being able to run correctly (or, indeed, at all).
I had hoped that by now, an updated version of glibc might be shipping that would have meant the linking phase could produce functional binaries, but no such luck. Therefore, I am reduced to having to re-compile all the binaries after a software-only Oracle installation and having first made sure that Oracle’s own versions of libc-related libraries are deleted.
The short story is, therefore, that a new version of Atlas has been released (1.6, if anyone’s counting) that works to allow a software-only install of Oracle 12R1 or 12R2. Fedora 26 users can thereafter run the ~/Documents/atlas-postinstall.sh script to trigger the correct re-linking of all the Oracle binaries and the automated creation of a database (for which the SYS and SYSTEM passwords are set to “oracle”). It isn’t pretty and I wish there were a nicer way of achieving it, but it at least works:
I have updated the Atlas/Fedora-specific documentation shortly to take account of this new way of having to do things.
Fedora 26 has just been released (I downloaded it even before Distrowatch mentioned it was available, so for once my timing was impeccable!) The release notes are available here, explaining what has changed since the previous version. Combining that with the other changes listed here and here, I have to say that most of the changes seem under-the-hood kind of stuff -though the increment in gcc version sounds like it could be trouble, and the default wallpaper is surprising in its bland twee-ness! The icon for the file manager turns blue, as well. Don’t get too excited!!
As usual, the main question in my mind when a new version hits the streets is: does it work with Atlas (and hence Oracle 12cR1 and 12cR2)?
The news on that is both good and bad: the good news is that the linking stage completes entirely without error (meaning that a software-only install works fine). But the bad news -really bad!- is that when the installer tries to create a database… nothing happens. Even if you try and launch the Database Configuration Assistant manually (type: dbca), it pops up its splash screen and then just sits there doing nothing. No errors are either reported or logged, though. The thing simply sits there idle, for no apparent reason.
So, I expect you could do a software-only install and then create a database using good old SQL*Plus and the ‘create database…’ command, but that’s obviously not the Atlas way of doing things… and I’ll therefore be working on this in the next day or two and, hopefully, get things running ‘properly’ once more; but I haven’t had a chance to try and diagnose this as yet, so I make no promises on that score!
Anyway: despite this failure to run Oracle, and with something approaching sheer recklessness, I nevertheless decided to do an in-place upgrade of my existing Fedora 25 desktop. It’s easy enough to do. First, I made sure everything on my version 25 PC was up-to-date:
sudo dnf upgrade --refresh
Next, I had to allow DNF to do system upgrades by installing a plugin that gives it the necessary functionality:
sudo dnf install dnf-plugin-system-upgrade
After that, just check that an in-place upgrade is actually possible:
sudo dnf system-upgrade download --refresh --releasever=26
If that reports unresolvable dependencies, then the upgrade won’t actually take place (unless you add the –allowerasing option, but then you will lose some software that’s already been installed, which may or may not be acceptable. I had to agree to lose my installation of the Chromium browser, for example: no great hardship these days, as I generally use Vivaldi, though as it turns out, it re-installs a more up-to-date version in its place anyway). But otherwise, it will download a lot of software (2.6GB in my case) and get your PC in a state ready to upgrade. Before finishing things off, best you take a backup of everything you care about: the next command is the point of no return:
sudo dnf system-upgrade reboot
…which actually does the business (and starts off with a reboot, so that the upgrade process takes place essentially in a command line-only environment). My upgrade took a while (my Internet connection is not great at the moment), but otherwise went well. All my apps appear to be running normally afterwards, too… so, no harm done (that I can tell!)
I recently needed to allow a Windows server to access some files which were stored on my Fedora 25 PC. I could have used NFS, but for reasons passeth understanding, I decided to do it with Samba instead -and immediately discovered that my knowledge (or, rather, recollection) of Samba is a bit rusty these days! Sharing stuff is relatively easy to do… but doing it in the context of a PC that uses a firewall and SELinux was definitely not trivial.
So, on the grounds that Fedora 25 has 2 more days of life in it yet; and recognising that I need to remember this stuff from time to time, I wrote the inevitable short piece on the subject.
Understand, I’m not trying to be subtle about it: I wanted anyone to be able to do anything in the Samba network share, without being asked for usernames or passwords. This isn’t the sort of configuration you are likely to want in any production setting I can think of, but for a home network under my total and sole control, I figured it would do!
In any case, the new short article is here.
Further to my recent post, the good news is that the ZFS team have released a version of ZFS which will work on the latest Fedora:
The 0.6.5.9 version supports kernels up to 4.10 (which is handy, as that’s the next kernel release I can upgrade my Fedora 25 to, so there’s some future-proofing going on there at last). And I can confirm that, indeed, ZFS installs correctly now.
I’m still a bit dubious about ZFS on a fast-moving distro such as Fedora, though, because just a single kernel update could potentially render your data inaccessible until the good folk at the ZFS development team decide to release new kernel drivers to match. But the situation is at least better than it was.
With a move to the UK pending, I am disinclined to suddenly start wiping terabytes of hard disk and dabbling with a new file system… but give it a few weeks and who knows?!
Spot the problem shown in these two screen grabs:
You will immediately notice from the second screenshot that version 0.6.5.8 of whatever it is which happens to have been screenshotted only supports up to 4.8 kernels, whereas the first screenshot shows that a Fedora 25 installation is using kernel version 4.9. Clearly that Fedora installation won’t be able to run whatever is being referred to in the second screenshot.
So what is it that I’ve taken that second screen shot of? This:
Ooops. It happens to be a screenshot of the current stable release number of the world’s greatest file system for Linux.
Put together, and in plain English, the combination of the two version numbers means: I can’t install ZFS on Fedora.
Or rather, I could have done so when Fedora 25 was freshly installed, straight off the DVD (because it ships with a 4.8 kernel, so the 0.6.5.8 version of ZFS would have worked just fine on that). ZFS on 4.8-kernel-using-Fedora 25 works fine, therefore.
But if I had, say, copied 4.8TB of data onto a freshly created zpool and then updated Fedora, I would now not be able to access my 4.8TB of data at all (because the relevant ZFS kernel modules won’t be able to load into the newly-installed 4.9 kernel). Which sort of makes the ZFS file system a bit less than useful, no?!
Of course, once they release version 0.7 version of ZFS (which is currently at release candidate 2 state), then we’re back in business -because ZFS 0.7 supports 4.9 kernels. Unless Fedora go and update themselves to using kernel 4.10, of course… in which case it’s presumably back to being inaccessible once more. And so, in cat-and-mouse fashion, ad infinitum…
But here’s the thing: Fedora is, by design, bleeding edge, cutting edge… you name your edge, Fedora is supposed to be on it! So it is likely to be getting new kernel releases every alternate Thursday afternoon, probably. What chance the ZFS developers will match that release cadence, do you think… given that their last stable release is now 4 months old?
About zilch I’d say. Which gives rise to a certain ‘impedance mismatch’, no? Try running ZFS on Fedora, it seems to me, and you’ll be consigning yourself to quite regularly not being able to access your data at all for weeks or months on end, several times a year. (Point releases of the 4.x kernel have been coming every two or three months since 4.0 was unleashed in April 2015, after all).
It strikes me that ZFS and Fedora are, in consequence, not likely to be good bed-fellows, which is a shame.
Perhaps it is time to investigate the data preservative characteristics of Btrfs at last?!
Incidentally, try installing ZFS on a 4.9-kernel-using-Fedora 25 whilst the 0.6.5.8 version of ZFS is the latest-and-greatest on offer and the error you’ll get is this:
The keywords to look for are ‘Bad return status’ and ‘spl-dkms scriptlet failed’. Both mean that the spl-dkms package didn’t get installed, and the net effect of that is the ZFS kernel modules don’t get loaded. In turn, this means trying to issue any ZFS-related commands will fail:
Of course, you will think that you should then do as the error message tells you: run ‘/sbin/modprobe zfs’ manually. It’s only when you try to do so you see the more fundamental problem:
And there’s no coming back from that. 🙁
No practical ZFS for a distro? That’s a bit of a deal-breaker for me these days.
On the whole, Fedora is a nice operating system. But installing the damn thing is a pain in the butt and makes my eyes bleed. Here’s a typical example of the horrors that await:
I mean, seriously?
They couldn’t manage to align the ‘C’ of “configuration” with the ‘U’ of “user settings”?
They were amused at the idea of putting the ‘U’ of “user settings” so far off to the left of the screen that it practically walks off the set?
They thought a progress bar that appears to disappear off either side of the screen was a good idea?
They broke open the tin of fonts, so that all the fonts above the progress bar are completely different to those underneath it?
They couldn’t consistently find the ‘Bold’ option, so ‘CONFIGURATION’ is and ‘FEDORA 19 INSTALLATION’ isn’t?
They thought spewing all manner of entirely disparate elements all over the screen counted as good design?
It’s possible to go on (at length), but I’ll simply sum up with: what a ghastly, typographically-inept piece of bollocks. The screen screams that if I have a question, “we have answers”. But my question is, “What on Earth were you thinking?”… and I suspect they have no answer to that, other than “we weren’t”.
Shame really. It’s a nice O/S once the hideousness of the installer is forgotten.
Fedora’s recent upgrade to the 3.8.1-201 kernel may have broken VMware Workstation (though now fixed by upgrading that to the latest 9.0.2 release), but it was a good day for networking on my Toshiba P870 laptop.
I mentioned a while ago that neither the wireless nor the gigabit Ethernet adapter worked out-of-the-box on this particular laptop when I first installed Fedora 18. There were some downloads and compilations needed before either would work -and then, those bits of compilation failed to re-compile if the kernel was ever updated, so I had to fiddle with setting default Grub menu options so that only the original 3.6 kernel would ever be used.
Well, as I say, the upgrade to the 3.8.1 kernel has fixed most of that: wireless networking now works without having to recompile or install anything. The gigabit Ethernet adapter still doesn’t work by default, though -which, I think, is the first time I’ve ever heard of wireless networking functioning better on Linux than the wired variety!
cd compat-drivers-3.8-1-u ./scripts/driver-select alx make make install
Finish off when prompted with a modprobe alx and your wired network will be back up and running in no time.
Happily, this means I no longer need to force my laptop to boot the old 3.6 kernel, so it’s time to un-default that particular boot option. As root,
There’ll be a line in there which reads GRUB_DEFAULT=<something>. Just change the “something” to an unquoted zero (i.e., the line should end up reading GRUB_DEFAULT=0), That will now boot whatever the latest kernel happens to be.
If you ever want to re-set a default boot option, then type (as root):
grep menuentry /boot/grub2/grub.cfg
…and copy whichever of the single-quoted menu items displayed is the one you want to be the default, and set the GRUB_DEFAULT in the /etc/default/grub file to that.
VMware Workstation is annoying me. A recent Fedora 18 upgrade took the kernel to version 3.8.1-201, and a change in kernel necessitates a re-compilation of the bits and bobs that make VMware work (kernel modules and the like). Often, that is not a problem -but, far too often, it is, and such was the case this time. I suspect an upgrade to gcc version 4.7.2 is responsible.
So, when you launch VMware Workstation, you get this:
Which is fine: click the [Install] option, which brings up (after a prompt for the root password) this:
The yellow warning triangles are your first clue that this isn’t going as well as you hoped! The next screen just confirms it:
And if you check the log file mentioned there, you’ll see this sort of thing:
2013-03-10T11:19:29.891+10:00| vthread-3| I120: Building module with command "/usr/bin/make -j8 -C /tmp/modconfig-eHRedb/vmci-only auto-build HEADER_DIR=/lib/modules/3.8.1-201.fc18.x86_64/build/include CC=/usr/lib64/ccache/gcc IS_GCC_3=no" 2013-03-10T11:19:30.562+10:00| vthread-3| W110: Failed to build vmci. Failed to execute the build command.
So, that’s the end of that.
It turns out that there’s a newer version of VMware available (9.0.2 instead of the 9.0.0.something I’ve been using), and installing that fixes everything. But it was only about three weeks ago that I downloaded the 9.0.0 version, and it’s 400MB-a-download, which I consider excessive. A product shouldn’t, I think, be so damned fragile as to break every time some libraries change a bit. And slimmer would be better, too.
Meanwhile, VirtualBox has passed through the same upgrade unscathed and fully-functional -and it’s only about 68MB to download. Productivity suggests it’s time for VMware to lift their game -and for me to look elsewhere for all my virtualization needs.