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.
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!
It is not difficult to fix, though. Just visit this site and download the 3.8.1 compat-driver file of your choice (I decided to use the bzip2 one). Extract the download, then as root:
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
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.
I’ve been using Fedora 18 on my laptop for a couple of weeks now. As I mentioned a few posts ago, I found Gnome 3 and the Gnome Shell to be a way-better experience than I’d remembered from my previous dabbling with it. It looks pretty good and behaved more-or-less rationally -and that meant I was happy to stick with it, despite me hating it last time I tried.
Unfortunately, it didn’t last!
Gnome 3/Gnome Shell on this particular laptop, anyway, has turned out to be incredibly unstable, locking up at least once a day. The laptop didn’t crash, mind: although my display would freeze (so progress bars, for example, would stop progressing; and application windows would stop being clickable or drag-able), I was able to hit Ctrl+Alt+F2 and switch to a new text console, which would function perfectly well. I was even able to Ctrl+Alt+F3, log on in a third new text console, do a startx and launch an entirely new desktop. So: definitely not hung.
But a pain in the neck, and not conducive to serious productivity.
I toyed with the idea of a new O/S, but in the end decided I liked Fedora 18 well enough to try an alternative approach. I ended up issuing this command:
yum groupinstall "MATE Desktop"
That buys you a few tens of megs of download… and then a desktop that looks exactly like the one which ships with CentOS 6.3 (i.e., a Gnome 2 desktop -though Mate now uses a lot of Gnome 3 libraries, meaning it’s not the programming dead-end it originally appeared to be when it was first forked from Gnome 2).
First thing to say: I really liked it. I thought I liked Gnome 3, but the sense of relief when the MATE desktop appeared was palpable. I will confess that it took me a while to stop mousing into the top left-hand corner of the screen to quickly bring up an overview of all open windows -a Gnome 3 nice touch. MATE has exactly the same functionality, though: it’s just that you mouse into the top right-hand corner!
…and I had my old friends -wobbly windows, desktop cube and some glitzy windows title bars- back where they belong. Call me old-fashioned, I suppose, but the inability to have those particular desktop effects in Gnome Shell was something I definitely missed.
More to the point, though: not only was the new desktop immediately more comfortable and familiar than I’d expected, it also has turned out to be much more stable and reliable. Gone are the lock-ups experienced with Gnome Shell: this thing is still Fedora 18, but hasn’t skipped a beat since it was installed.
My only gripe is that my menus have lots of duplicates in them: two “Archive Managers”, two “Calculators”, two “Disk Usage Analyzers” and so on. Using alacarte to manually prune menus hasn’t altered that, but it is, in any case, just a minor niggle.
All up, then, I thoroughly recommend Fedora 18… just not with the Gnome Shell.
Needing to install Handbrake on Fedora 18, I found a bunch of different instructions in different corners of the Internet, none of which worked without tweaking. Here are the commands that worked for me (done as root, of course):
One of the consequences of tidying up Gladstone before his retirement has been the discovery that installing 11g Release 2 on Fedora 17 is a variable experience, depending on the Oracle version you’re using. This has revealed a bit of a stuff-up on my part regarding the sort of Oracle installations I do!
To explain: my standard advice when installing 11gR2 on Fedora 17 has been that you should expect to experience a linking error (relating to the $ORACLE_HOME/sysman/lib/ins_emagent.mk makefile). Gladstone knows this ahead of time and therefore writes out a little shell script (in your Desktop directory) which you can run the moment the linking error appears. As soon as it has completed its work, you switch back to the Oracle installer, click Retry …and everything will then complete successfully. A perfect installation in the end, then, with just a minor blip on the way.
However, it turns out that this advice is only true if you are installing Oracle 22.214.171.124!
If you are instead using the 126.96.36.199 version, the advice is wrong …because you will experience a completely different linking error much earlier in the piece. This one relates to the …ctx/lib/ins_ctx.mk makefile …and there’s no fix for it (not one I can work out, anyway). The only thing you can do when this particular error appears is to click ‘continue’ in the Oracle installer. The installer will then carry on linking everything else, bump into the “known” ins_emagent problem as before… and you can worked around that with the fix-up shell script previously described. Overall, you’ll experience two linking errors, only one of which can be fixed. You will therefore complete the installation, but you’ll be left with defective Oracle Text functionality, which may or may not matter to you.
Put it this way, then: if you’ve got paid access to My Oracle Support, you can use the latest version of Oracle and you won’t have an ins_ctx.mk problem. If you’re relying on the freebie downloads from OTN, though, you will.
I should have noticed this much sooner than I did. Trouble is, with access to the latest version of Oracle 11g, I inevitably got into the habit of using it when testing Gladstone, so I never noticed the big difference in the way the two versions behave during installation.
This is particularly bad on my part because, of course, the people most likely to be using Gladstone on non-supported Distros are precisely the people least likely to have access to the higher version. (Home learners, basically).
I should have kept “my audience” in mind, and stuck to working things out on the 188.8.131.52 version only, therefore… which is what I’ll definitely be doing in future. Apologies in the meantime: 11g on Fedora 17 will work, but only with slightly defective Oracle Text functionality and a willingness to accept the first of the two linking errors that result, without trying to fix it.
The first alpha release of what will eventually become Fedora 16 has been released -I got my copy from here (update: that link is obviously now to the production release DVD of Fedora 16!).
The default artwork for the release (see left) is, to my eyes, frankly alarming -well, if not alarming exactly, at least not very good! It’s only a wallpaper change away, but I do wish Fedora would stop trying to theme their desktops to match their fairly arbitrary choice of version codename (in this case, Fedora 16 is codenamed Jules Verne, as in Twenty Thousand Leagues Under the Sea. Yeah, I think it’s a bad idea for a desktop theme, too!)
And I’m still not convinced by Gnome 3 (initial horror with Fedora 15′s implementation of it gave way several weeks ago to keen enthusiasm, but that has since been replaced by indifferent dislike… there’s nothing much I’ve seen in Fedora 16′s implementation that counts as a major improvement). Otherwise, there’s the usual software-stack updates (Firefox is at version 6, for example; and you get 3.4.2 of LibreOffice thrown in), but most of the changes are, I think, under-the-hood stuff and aren’t likely to revolutionise your Linux life!
I have successfully tested a Gladstone-prepared 11g Release 2 installation on the new release. There is the usual pile of software the OUI claims doesn’t exist (click Ignore All when prompted, because they do). There is also the expected ‘Error in invoking target agent nmhs of makefile ins_emagent.mk‘ problem during the linking phase. The workaround here is to run the fedora-linking-error-fix.sh script in your Desktop directory which Gladstone will have created for you (just navigate there with Nautilus and double-click the shell script when the linking error occurs, then click Retry in the Oracle Universal Installer. It’s plain sailing after that).
Interestingly, one of the reasonably significant changes made in this release (enough to get a mention in the release notes, anyway) is that, by default, a Desktop directory is no longer created for you during installation. However, Gladstone is hard-coded to write its fix-up script there, so a /home/<username>/Desktop directory needs to exist: create one before you start if you need to.
Of course, there can be no guarantees: what works in an alpha release might be broken by any subsequent beta, let alone the final, finished distro. But since it’s working right now, a revised, Fedora 16-aware, version of Gladstone is downloadable from the usual place.
Incidentally, I have not tested a 10gR2 installation on Fedora 16, and won’t be doing so. As was mentioned in various discussions on this blog lately, 10g Release 2 is out of mainstream Oracle support these days, and I don’t therefore propose to spend any more time on it from now on. So Gladstone may or may not work for 10g: feel free to give it a whirl, I guess.
Installing “proper” ATI drivers is impossible, because ATI don’t support the xorg version used by Fedora
Because K3B is such a good CD ripper (and burner), I investigate KDE-based distros, but can’t stand any of them for long. Discover, however, that living with a mix of KDE and Gnome apps isn’t actually a bad thing but rather gives you the best of both worlds.
CD ripping resolved, therefore, by running a Gnome distro but with some KDE apps installed (like K3B). Still leaves the Stellarium/ATI Graphics problem…
So I install OpenSuse 11.3 -and hate every moment of it! Stellarium works and the ATI drivers install, but the distro sucks in lots of little ways (in addition to the litany mentioned last time, I should add that discovering sshd is not enabled by default was a bit of a surprise!)
After two days with OpenSuse, I reverted to Ubuntu 10.04: Stellarium worked, K3B still does CD ripping. But I’m still bored with Ubuntu. Worse, I find some of its control changes now annoying: I want my Log Out option to be under my System menu, thanks all the same, not a little button tucked over the right-hand side of the top panel. Also, I know I can switch the windows close/minimise/maximise buttons back to the right-hand side of the window, but I don’t see why I should have to -and I know that the developers are cooking things up for 10.10 that will expect the controls to be on the left, where they put them without much consultation. All a bit Microsoft-ish if you ask me.
So, having been through just about every vaguely-plausible distro and desktop environment out there and received only disappointment for his pains, what’s a boy to do??
Buy an Nvidia graphics card is the answer!
Actually, I happened to have one sitting around in a cupboard, so I whipped out the ATI monster and slipped it into the PCI Express slot in its stead. It sounds a tad drastic but it means I’ve been able to re-install Fedora, have no graphics problems, Stellarium works, K3B works, menus are where I expect them to be, ditto windows controls …and it all behaves very like a Red Hat Enterprise distro, so I feel at home at work, if you get my drift.
Everything is thus tickety-boo …if you overlook the minor matter of having to trash more than $300-worth of ATI graphics card to get there. I have said it before, but it bears mentioning once again: ATI (i.e., AMD) should be ashamed of themselves. The quality of their Linux drivers, the convoluted installation process and the tendency of any system fitted with them to crash or otherwise have “interesting” graphical glitches happen at random moments -it all adds up to an abysmal way of doing business. I won’t say that Nvidia are completely blameless (their installation procedure isn’t exactly brilliant -on Fedora, at least, you have to manually disable the open source drivers by editing the grub.conf file before the installation will succeed, which isn’t what I’d call terribly user-friendly), but they make ATI look like a bunch of incompetent amateurs by comparison.
Funnily enough, my PC at work -which I try to keep more-or-less in synch, distro-wise, with my home PC- experienced exactly the same grief with ATI drivers, even though it was running a copy of Centos 5.5 (which is a clone of Red Hat Enterprise Linux, which ATI claims to be a fully-supported distro). I gave in there, too, and did actually go out and buy a $50 Nvidia Geforce 8400GT… which also immediately made all my graphical and stability problems melt away. So it seems to me to be a generic “feature” of ATI cards that they screw up most Linux distros!
I never had that problem with Ubuntu with the ATI card, I will admit -but then I never tried to install my own ATI drivers in that distro, either. Clicking the ‘activate proprietary drivers’ button is all it takes in Ubuntu (and is all it really ought to take anywhere else, Nvidia and ATI included), but I have no idea which drivers it actually causes to be installed. Had such an ‘automated installation’ feature been available in Fedora, I guess none of this saga would have arisen -but ATI haven’t exactly come to the party in terms of supporting Fedora nearly six months after its release, so I still say it’s more ATI’s fault than anyone else’s.
Anyway, I’m a happy Fedora man again -and discovering the joys of KVM virtualisation for the first time (very impressive, is the short version). And if anyone wants a $300 ATI graphics card, feel free to ask.