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?!
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.
I nearly fell off my chair this week. In my recent and fairly exhaustive trawl through over two dozen distros and their variants, I found one I liked a lot. Which maybe isn’t so chair-topplingly surprising, in and of itself.
The real surprise was that the distro in question was (drum roll, please…): Fedora.
And I nearly fell off my chair backwards when I further found that the desktop environment I liked most in the Fedora context was… Gnome.
It’s clean and uncluttered (especially compared to the busy-ness that is the Fedora KDE spin). It is responsive. And once one has discovered Gnome Shell extensions such as Dash-to-Dock; or used Gnome Tweak Tool to add back Maximize and Minimize buttons to the window decorations… it turns out to be quite highly usable and productive.
All of which surprised me a lot: I have been avoiding anything to do with Gnome in general for quite a few years (since the whole Gnome Shell debacle in 2011) and anything to do with Fedora specifically for some more years than that. But both would appear to have made stealthy progress that impresses this particular traveller from foreign lands (i.e., KDE and Manjaro!) no end. Fedora even looks typographically sane these days. Who would have thought that possible, given their cavalier approach to all things font-y in the past?
The one (quite big) black spot is the lack of an extension that allows Gnome’s windows to wobble or a Desktop Cube to spin (there is one for wobbly windows, but it doesn’t work very well). Can I live without wobbly windows? Possibly, given other things the Gnome environment provides (such as Boxes, which potentially means no more VirtualBox or VMware, though it’s by no means a perfect replacement as yet; and -most impressively- excellent integration with cloud services like Google Drive).
In consequence whereof, I think my days of feeling forced to use KDE might be behind me. I have a spare laptop or two that will become guinea pigs in a ‘transition to Fedora’ experiment this week. We’ll see how it goes…
Just as my playing with the new Linux Mint release begins, so the Fedora team finalise a new version of their distro: Fedora 24 was released on 21st June.
It’s still very blue; it’s still very Gnome-y and therefore pretty awful as far as I’m concerned and I wouldn’t personally touch it with a feathered hat-band, let alone a bargepole.
But it’s out and therefore my Bogart preinstaller script, which makes Fedora a suitable platform for running Oracle Enterprise Edition, needs a run in the park to make sure it still works with the new version. Happily it does without any substantial changes at all.
However, I took the opportunity to do two things with Bogart. One was to remove its ability for preparing for an 11g installation. I know 126.96.36.199 is still supported, but you can’t get hold of that without a support contract; and if you’ve got a support contract, you won’t likely be wanting to run Oracle on an unsupported platform like Fedora! Meanwhile, any other version of 11g you can get your hands on has long-since been de-suppported… so Bogart is now 12c only.
And that means, two: I’ve re-written the Oracle-on-Fedora article to reflect it’s new only-12c-ness.
The revised article is here, and the updated Bogart preinstaller script is here.
Fedora 15 has finally been released and is available in all the usual places, including here.
Naturally, Gladstone has been tested on it (it’s been working on the Alphas and Betas for a while now), and works just fine (with a slight pause when it first runs, because it has to download the lsb_release package before it can really get going).
There is a nasty linking error for 11g, of course, as previously described -and the workaround is exactly the same as before, too. Namely, Gladstone outputs a new shell script in the oracle user’s Desktop directory ahead of time, and this script can then be run when the Oracle Universal Installer linking error occurs, after which you can click the OUI’s ‘Retry’ button and all will be fine. (You run the second shell script as the oracle user, not as root).
The only real problem now, which I mentioned before too, is that in Gnome 3, the contents of the Desktop directory are not displayed on the, er, actual Desktop! So, you have to know that second shell script is there, because you won’t actually be able to see it as such.
If that’s as clear as mud, well… stick with Scientific Linux for an easier ride, I guess!
Also, I noticed an extremely long pause between the conclusion of the linking phase and the start of the Database Configuration Assistant that wasn’t there in the Alpha or Beta versions. The pause happened on three different physical servers, so although your mileage might vary, I think it’s definitely real. You have to be very, very patient therefore -but it does get there eventually.
Anyway, I also have prepared a Kickstart script for Fedora 15 (and a floppy image containing said script for those that don’t have a web server onto which the plain script can be dropped). If you use that script to perform the initial installation (it’s invoked in exactly the same way as for Scientific Linux 6, which I discussed here), you’ll end up with a substantially slimmed-down O/S (no Evolution mail client, for example; and 890-ish packages installed instead of the default 1200+) that’s still Oracle-friendly.
One slight niggle is that Fedora 15 Beta uses the Gnome Shell desktop environment -and that means the desktop you see once logged in is not ‘live’. You can’t, for example, drag-and-drop a file onto it and see it appear as a desktop icon. You do still have a Desktop directory, and it can still have things in it… but visually you won’t be reminded that those files exist:
This is a simple example of what I’m talking about: the Nautilus file manager clearly shows three files and a directory are sitting in my Desktop directory, but nothing is actually showing on the blue stripey desktop itself (you’ll have to trust me that there’s nothing hiding underneath Nautilus, either!)
It’s actually a bit more than a niggle -it strikes me as a bloody stupid way of doing things, and I can only hope that the Gnome devs stop this sort of thing happening whilst they’re on the path to world desktop domination.
Anyway, in the meantime, it means that Gladstone can be a little trickier to run on Fedora 15 Beta than it should be, if you are using it to prepare for an Oracle 11g Release 2 installation. That’s because Fedora still suffers from an ‘error in invoking target’ compilation error during the eventual 11g installation -and Gladstone deals with that by creating a short bash script ahead of time. When you encounter the linking error, you just double-click the ‘fixing script’ and let it run (it takes seconds only), after which you can click ‘Retry’ back in the Oracle installation process, and all will be well.
Except that now, of course, you can’t actually see that a ‘fix me up’ script has been created for you, because Gladstone thoughtfully writes it out to…. the Desktop! If you can’t see it, you tend not to know to double-click it -and that means you’re stuck with a flakey Oracle installation process left hanging!
All I can really do at this point is lament the tide of so-called “progress” in the development of a desktop Linux and encourage any Fedora users trying to install Oracle 11gR2 via Gladstone: do what I’ve done in that screenshot above. Open your Desktop folder in Nautilus before you launch the Oracle installer so that you can double-click the fedora-linking-error-fix.sh shell script when you encounter the agent linking error.