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