Posts

Showing posts with the label Reviews

Fedora 37 mini-review on the Blackbird and Talos II


It's been kind of a wild ride getting the Talos II and the Blackbird upgraded to Fedora 37, but we're there, so it's finally time for a mini-review to summarize the current state. As I always like to remind folks, Fedora was one of the first mainstream distributions to support POWER9 out of the box, it's still one of the top distributions OpenPOWER denizens use and its position closest to the bleeding, ragged edge is where we see problems emerge first and get fixed (hopefully) before they move further downstream. That's why it's worth caring about it even if you yourself don't run it.

Another important reminder is both my 'Bird and T2 are configured to come up in a text boot instead of gdm and I start GNOME (Blackbird) or KDE (T2) manually from there. I still test GNOME on both systems, but I've pretty much entirely migrated over to KDE Plasma on the T2, so I'll talk about both the GNOME and KDE experience in this and future mini-reviews. I strongly recommend a non-graphical boot as a recovery mechanism in case your graphics card gets whacked by something or other. On Fedora this is easily done by ensuring the symlink /etc/systemd/system/default.target points to /lib/systemd/system/multi-user.target.

As usual, the process is, from a root prompt:

dnf upgrade --refresh # upgrade prior system and DNF
dnf install dnf-plugin-system-upgrade # install upgrade plugin if not already done
dnf system-upgrade download --refresh --releasever=37 # download F37 packages
dnf system-upgrade reboot # reboot into upgrader

I did the Blackbird first, and immediately got a broken packages error because this was the system I had tested Pantheon on for Fedora 36. Just in case you didn't get the memo, new for F37 ain't no more Pantheon in Fedora (though there is a Copr). I just removed them instead (elementary-wallpapers-gnome, gala-libs and switchboard and switchboard-plug-tweaks). It booted into a graphical installer and rebooted without incident. The kernel release as of this writing is 6.0.13.

On the Talos II, which has the Raptor BTO option AMD WX7100 workstation card in it, even with GPU firmware loaded into the PNOR there was once again no graphical installation. If you manually select the kernel from Petitboot, it will at least show a text installation process. Alternatively, you can monitor on the serial port, or from a connected system viewing the serial console over the BMC's web server, or by logging into another VTY with CTRL-ALT-F2 or as appropriate as root and periodically issuing dnf system-upgrade log --number=-1 to watch log updates.

Although installation on the T2 also seemed to successfully terminate and reboot, Petitboot subsequently puked because it couldn't handle the state the updater left it in (the root is XFS and it had a stuck journal log entry). Fortunately the Blackbird was able to rectify the filesystem once the SSD was moved to an external device for recovery.

Both systems failed to update the grub2 configuration, requiring me to do so manually with grub2-mkconfig -o /boot/grub2/grub.cfg. This is a regression from bug 1921479 and can be detected in dnf with the same error message during a kernel package update (/etc/grub.d/10_linux: line XXX: test: XXXXXXX-pXXXXXXX: integer expression expected).

Additional problems were afoot on the Blackbird when starting a GUI, which is a basic 4-core using the ASPEED BMC for graphics. At least on the ASPEED, GNOME was rife with graphical abnormalities, worst of all in Wayland. (Starting Wayland from the command line also got more complex: I had to do something along the lines of XDG_SESSION_TYPE=wayland /usr/libexec/gnome-session-binary --builtin to get it to start; the regular gnome-session bombed out with an argument error.) Wayland is still restricted to 1024x768:

But that wasn't the worst of it. Trying to do even simple tasks yielded a lot of tearing and refresh problems. This is a picture of the screen because I couldn't even get the screenshot utility to work reliably.
So definitely a regression for Wayland. But even Xorg (still starts with startx, may need XDG_SESSION_TYPE=x11) had some unusual problems, like some apps' titlebars being transparent and causing graphical glitches:
Oddly, it wasn't all of them, though the Terminal was most affected. Newer or recently refreshed libadwaita-based apps seemed relatively immune, as did apps like Firefox that adhered to older GTK APIs. I keep the Blackbird as stock Fedora as possible, and I ran another update just prior to writing this up and didn't see any improvement.

KDE was not affected by that issue, though I observed — at least with Firefox and Thunderbird — that I had to grab the window and move it around a bit to get click point coordinates to be correctly reflected when the apps are full screen (then, after giving them a little shake by the titlebar, I could maximize them again and all would be well). I don't know whose bug this is exactly.

That particular irritation persisted on the Talos II, but none of GNOME's graphical problems that I saw on the Blackbird's BMC graphics. In fact, GNOME performed rather well for a change: I didn't need to force a rebuild of libgraphene this time to get improved performance and the UI was very smooth in Xorg. It also appears that the colour management issues I used to have where the screen would get blue-tinged have been rectified. Wayland GNOME had occasional animation stutters and a mild bit of lag but was otherwise useable, which is invariably the most I can say about Wayland.

Also in the positive category is that the bustage churn from the long double update in Fedora 36 is now almost all behind us, and the toolchain successfully built Firefox and other large projects without any new problems.

Overall F37 is a mixed update, more good than bad, but with some unwelcome regressions. In particular, if you are running BMC graphics only, even in Xorg GNOME has picked up some new glitches and in Wayland is once again a big mess. Systems with a GPU will largely be spared these issues — or just don't run GNOME. Likewise, be prepared with a second system to do any filesystem recovery if you're a long-time Fedora user and your root is still XFS; it may be time to convert it over to something else if you get pounded by it every time you do an upgrade.

When Petitboot barfs, everything's vomit


Colourful, no? But it's true. I've not been able to write up my Fedora 37 experience, nor upgrade Firefox (nor do further work on the JIT) because the Petitboot boot menu couldn't stop touching the main NVMe drive and making its older (Linux 5.5) XFS kernel module hang. If Petitboot can't start, your expensive POWER9 system is a brick.

In its most literal sense this article is largely a precautionary tale, because unless you're a long-term Fedora user like me with a continuously updated older installation, it's very unlikely you have an XFS volume in your OpenPOWER box. But if the antique kernel in Petitboot ever starts barfing on your own filesystems or a device you install, you'll be in this state too, so here's how I got the Talos II working again.

It's pretty much been a constant that you need a second system to deal with glitches. For me, this is usually my trusty Quad G5 Power Mac sitting next to the T2 which is connected to its serial port (or to the BMC's), and this works when it's a problem you can resolve from the BMC side, which is many of them. It would be nice to power up a Talos or Blackbird and have the console automatically start up talking to the BMC instead of needing another system to do so but this is what we have, at least until Kestrel develops that capability.

Unfortunately, this wasn't one of those problems:

  [Disk: nvme1n1p2 / 19a5d4e3-19f7-423f-a75b-5b15c8ee0bff]
    Fedora (0-rescue-ee275f6a7d994c9981e4e1436b83172d) 30 (Workstation Edition)
    Fedora Linux (5.18.13-200.fc36.ppc64le) 36 (Workstation Edition)
    Fedora Linux (5.18.18-200.fc36.ppc64le) 36 (Workstation Edition)
(*) Fedora Linux (6.0.12-200.fc36.ppc64le) 36 (Workstation Edition)
  System configuration
  System status log
  Language
  Rescan devices
  Retrieve config from URL
 *Exit to shell


 [fedora-root] Processing new Disk device[    8.041704] XFS: Assertion failed: !
(fields & XFS_ILOG_DFORK) ||
 (len == in_f->ilf_dsize), file: fs/xfs/xfs_log_recover.c, line: 3103
cpu 0x26: Vector: 700 (Program Check) at [c0002007e33171c0]
    pc: c008000008dc46bc: assfail+0x54/0x60 [xfs]
    lr: c008000008dc4694: assfail+0x2c/0x60 [xfs]
    sp: c0002007e3317450
   msr: 900000000282b033
  current = 0xc0002007e32c3180
  paca    = 0xc0002007ff7f5900   irqmask: 0x03   irq_happened: 0x01
    pid   = 649, comm = pb-discover
kernel BUG at fs/xfs/xfs_message.c:110!

After the assertion appeared, Petitboot locked up (at least on the regular console) and the system wouldn't start from any device because Petitboot could not be coerced into ignoring it. I tried holding down the x key from the serial console to force it into the shell, and that worked — but it still tried to mount the volume anyway and died. This did bring up a live kernel debugging session as you can see in the screenshot, but since I wasn't sure what the XFS module would do at this point and didn't want to risk the filesystem, I just powered it down.

Something about the state of the root XFS volume after the Fedora 37 update was making it go wrong, and I haven't been the first to observe this, either. Recovering cleanly would at minimum require a system that can mount and examine the XFS volume, and the G5, which runs Mac OS X Tiger, isn't that system. (Maybe the SGI Fuel next to it with IRIX 6.5.30 is — though that's something to explore some other time when it isn't my primary computer's boot volume at stake.)

Fortunately I've also got a Blackbird that did complete its F37 upgrade successfully. So it's time to do a little shopping.

I picked up two off-the-shelf NVMe-to-USB enclosures, one the Worst Best Buy Insignia store brand NS-PCNVMEHDE for about US$20, and a Sabrent EC-SNVE for about US$30 which also supports SATA. I was pretty sure the Sabrent would work due to their usual diligence about Linux, but I bought the Insignia anyway as a backstop in case the Sabrent was defective, and also because it came with a USB-C to USB-A converter since the Blackbird doesn't currently have any USB-C connectors.

Both devices are USB 3.2 Gen 2 and came up as "SuperSpeed USB" connected to the Blackbird's rear USB ports. The Sabrent is a much nicer unit with high-quality metal construction that folds open and has an integrated heat spreader in the top. The "tool free" part is there's a small clip that rotates to hold the M.2 stick in (with a stopper in the package for smaller-sized sticks). But even though the Insignia was kludgier (pulls out instead of folds open, requires you to stick on a heat spreader, really clumsy turn clip), it supports USB Attached SCSI Protocol; dmesg indicated the Sabrent didn't respond to a UAS probe. If I could have combined the chipset in the Insignia with the case of the Sabrent, we'd have the perfect enclosure.

Both devices also worked in Petitboot — by which I mean having the tainted NVMe SSD plugged in while Petitboot came up would also crash the Blackbird.

Bringing up Fedora first and then connecting the enclosure after, we next get the T2's root volume up so it can be checked. Because both the Blackbird's boot drive and the T2's boot drive have the volume group name fedora, we'll need to rename the T2's. We list the volume groups with vgdisplay; the T2's starts with lO, so the commands are:

vgrename `vgdisplay | grep lO | awk '{print $3}'` tfed
lvchange -ay /dev/tfed/root

But xfs_repair /dev/tfed/root wouldn't try to fix it: it said there was a log entry that had to be replayed first. This can be done simply by mounting it, so

mount /dev/tfed/root /mnt
umount /mnt
xfs_repair /dev/tfed/root

This showed no errors, so I inactivated the root LV again with lvchange -an /dev/tfed/root, disconnected the NVMe stick, put it back in its PCIe carrier and reinstalled it in the T2. Petitboot didn't crash, but Fedora requires the logical volume be named fedora, so we enter the Petitboot shell first and finish up with

vgrename `vgdisplay | grep lO | awk '{print $3}'` fedora

and then boot.

Whose bug was this? Well, arguably, Fedora might not have properly unmounted the drive after the update, but the error appears to be minor in that simply mounting the drive (with a later kernel, admittedly) fixed up the issue. It's more important that Petitboot have a stable, well-tested codebase, so the decision to use an older kernel (though 5.5 is a little excessive) is not an unreasonable one, and this older kernel appears not to be able to do that kind of recovery.

But if Petitboot can't do it, it shouldn't just brick the system. There should be a way for a user to hold down a key and bypass the menu without mounting anything, and try to recover in the shell at that point, which you can do from the console. Similarly, if it barfs on a filesystem or an installed device, it should simply say so and ignore it, not panic. These computers are just too expensive to have vomit everywhere when something goes wrong — and you shouldn't have to have a whole second system around to clean up the mess.

Fedora 36 mini-mini-review on the Blackbird


I said that Fedora 36 was when I was going to jump ship from GNOME, since I'm not happy with the Adwaita-or-nothing ultimatum GNOME 42 poses squarely at heavy themers like me. The problem is what I'm going to jump ship to.

For the past couple weeks I've been experimenting on the Blackbird to see what window managers and desktop environments seem to work well with Fedora on ppc64le before I try to migrate my main Talos II workstation to whatever I end up picking. But I also know a few of you are itching to upgrade and waiting to see if there were any problems, and of course for those of you running a distro other than Fedora, Fedora's going to find problems earliest. So, this will be a mini-mini-review instead of what we traditionally do: what I've been testing on the Blackbird and how well it appears to work, keeping in mind that my Blackbird is a GPU-less machine using only the ASPEED BMC for graphics and a 4-core CPU with 16GB of RAM. I'd call it "low end," at least within the spectrum of practical OpenPOWER desktops.

The upgrade itself went fairly smoothly. You know the steps to this dance by now, but if you're new to the club, here's the fancy footwork:

dnf upgrade --refresh # upgrade prior system and DNF
dnf install dnf-plugin-system-upgrade # install upgrade plugin if not already done
dnf system-upgrade download --refresh --releasever=36 # download F36 packages
dnf system-upgrade reboot # reboot into upgrader

There were no broken packages and no upgrade glitches, at least on the Blackbird (the Talos II has rather more packages installed). Actually, I was surprised, because this is the release that finally fixes 128-bit long double after literally actual years and watching the PowerPC tracker in Redhat Bugzilla has been very busy of late. But, at least for the vanilla install on this Blackbird, there were no problems. In fact, I know the packages available have increased by at least one, and that one's a biggie. More in a second.

The upgrade was on a black screen again, but if you select the kernel manually from Petitboot you should be able to follow along. Alternatively, you can monitor on the serial port, or from a connected system viewing the serial console over the BMC's web server, or by logging into another VTY with CTRL-ALT-F2 or whatev as root and periodically issuing dnf system-upgrade log --number=-1 to watch log updates. I left it to upgrade while I ate lunch and came back to a clean reboot and a Fedora 36 login prompt.

Recall also that I no longer run a display manager directly on either of my running workstations because of past irregularities with gdm (other display managers may work, haven't tried); I boot directly into a text prompt and do a startx from there. If you are running gdm, lightdm or others, you can probably just select the session type on login and avoid some screwing around with ~/.xinitrc. But first, let's get the Wayland Wasteland out of the, uh, way with a quick XDG_SESSION_TYPE=wayland gnome-session and a heavy dose of antiemetics.

I was unable to appreciate really any difference, good or bad, with Wayland in F36 compared to F35. It still won't support resolutions greater than 1024x768 on BMC graphics, and speed was neither better nor worse; llvmpipe-based applications in particular seem to run roughly about the same as previously, which is to say, not great. My verdict is it's not a regression, which is itself a small victory, and that's as much as I did with Wayland. I then brought GNOME 42 up in X11.
On purpose my Blackbird doesn't have any GNOME themes and only the default extensions that Fedora provides as standard, so this is as vanilla as it gets. Tweaks still allows my Mac pointing memory to deal with closing and window buttons on the left. With the usual modeline 1080p works fine over HDMI in X11.

Fedora has various spins and other window managers available. I'm not going to do everything on the list, but I did a few. The first one I started with is Pantheon, the GNOME derivative from Elementary OS, mostly because it seemed more Mac-like to me. It turns out that the current release is unusually difficult to launch without a desktop manager; even gnome-session --builtin --session=pantheon just puts up a blank background. This is the current launcher I put in ~/.xinitrc:

#!/bin/csh

gala-daemon &
io.elementary.greeter-compositor &
io.elementary.greeter &
(sleep 1 && echo '12' && sleep 1 && echo '25' && \
 sleep 1 && echo '37' && sleep 1 && echo '50' && \
 sleep 1 && echo '62' && sleep 1 && echo '75' && \
 sleep 1 && echo '87' && sleep 1 && echo '100') | \
 zenity --progress --title="Autologin in progress" --text="" --no-cancel --auto-close &
sleep 5 && killall io.elementary.greeter
io.elementary.files-daemon &
io.elementary.wingpanel &
plank &
io.elementary.terminal &
exec gala --replace

It's really ugly, but it does properly load the theming — unless I start up the greeter, the GTK themes seem not to stick. However, I have to kill it so it doesn't hang around. This doesn't fix everything because apps don't seem to update in the dock and a few core components still don't start up right, and you can't log out to the shell without opening a terminal window and doing kill -9 -1, but it's good enough to do this:

And it's also good enough to do this:
Yes, sports fans, the proof that the long double issue is fixed is that MAME is now buildable and now even a standard package on ppc64le. Good job, Dan and folks!

Overall I found the Elementary-on-Fedora experience ... plausible. There are still some pitfalls and I'm not sure how many of them are the fault of my own configuration or something specific to ppc64le or various high-level deficiencies in the packages, but at least one person says it worked great in F35, so maybe I just suck.

Moving along, our next port of call was KDE Plasma. This basically works.

You can enable this either with something like switchdesk, which is a little antiquated, or simply putting exec startplasma-x11 into ~/.xinitrc (or, I suppose, startplasma-wayland, or these alternatives). I was able to get a theme that was good enough working. I know of others using it with Fedora, and it's probably the best secondary and supported option other than GNOME.

I don't have any screenshots of Xfce in F36 yet, but I was experimenting with it on the Talos II for F35, so I have high confidence that continues to work as well. The same is likely true for LXDE.

I also did a couple oddball WMs just for fun and for some new ideas. Other than wmx, which was possibly a little too bare, surprisingly these are more functional than you might think. The first was WindowMaker.

If WindowMaker looks like NeXTSTEP, it's no coincidence since it's a deliberate recreation of the interface. I'm very used to it since my SAIC Galaxy 1100 (a HP PA-RISC 9000/712 "Gecko" workstation in a MIL-SPEC portable case) runs NeXTSTEP 3.3. It's also stonking fast and has little baloney compared to most other window managers, but the interface is not designed to be particularly configurable other than individual menu options and cosmetic themes, and it's not very Mac OS X-like (because Rhapsody, Mac OS X and macOS aren't very NeXT-like). There is a Fedora package for it. Put exec wmaker into ~/.xinitrc.

The other oddball window manager I've played with so far is amiwm. Yes, this is an Amiga Workbench clone. There is no Fedora package for it; I built it from the source code on the Lysator FTP site (Lysator brings back memories since NannyMUD was single-handedly responsible for lowering my undergraduate grade point average freshman and sophomore years), though there seem to be a few patched-up versions on Github. In operation it's pretty much exactly what it says on the tin, screens, gadgets, requesters, Workbench menus and all:

And the damn thing not only works, it's even swifter than WindowMaker and does have the close button on the left. Maybe I've found a modern Amiga I do want. Anyway, the upgrade seems to be good. Go to it.

Mini-review: The Clockwork Pi DevTerm R-01, or RISC-V on the go


This blog is unambiguously pro-Power ISA, not least because I'm a long-time PowerPC bigot to start with, but also I think OpenPOWER — POWER9 specifically — is currently the best option for a practical yet truly open computing platform: competitive performance, auditable stack, solid hardware, and good and steadily improving software support, so there. And that remains my official editorial position as I type this on my trusty Talos II.

But that doesn't mean I'm not other-RISC-curious, and RISC-V gets a lot of ink these days. I'll say for the record I believe much of that ink is hype: RISC-V is only a performance threat on the low end, there's a lot of sizzle and little steak in present hardware choices, and while the ISA may be open the actual implementations vary greatly on that point. I've observed that there are two main markets for OpenPOWER workstations, namely people who want to support alternatives to the x86-ARM duopoly, and those who want a truly libre auditable platform (with some natural overlap between these groups). RISC-V can scratch the itch of the first group, but it's arguable whether the ecosystem does so collectively for the second. That said, all hype machines, to borrow a cow-orker's trenchant expression, easily transform into self-licking ice cream cones and that sort of salivary momentum is why RISC-V is here to stay.

One other thing that RISC-V and OpenPOWER have in common, besides a royalty-free ISA, is that workstations are neither architecture's core market. POWER9 (and Power10 even more so) is still primarily a server and big-iron chip, and extant RISC-V cores mostly lurk in embedded applications (especially the "too cheap for MIPS" segment). But Raptor workstations at least have nerd awareness, while only the even-less-frequently-encountered HiFive Unmatched meets the definition of a RISC-V PC, and the others are just glorified evaluation boards. And even some people complain about the price of that.

For me, though, it wasn't the price that was the problem (I mean, I've got two T2 systems and a Raptor Blackbird and I'm saving my pennies for an Arctic Tern, so I'm all in on POWER); it was the form factor. I'm out of KVM slots and I have too many boxes around the office. If I was going to play with RISC-V as a use-it-like-a-computer user, it needed to be something that I could set up to mess with and tear it down to recover the desk space. Why, it could even be portable. That would be nice. There's no portable OpenPOWER option (yet?), so if there's a totable libre system out there other than those old bizarro Loongsons I'd love to rock one.

So when ClockworkPi announced they were making a RISC-V spin of their DevTerm "portable terminal," and for just US$240 to boot, I said, "Take my money. No, seriously, take it." So they took it, and yesterday about two months later it arrived, fresh from off the DHL boat from COVID-infested Hong Kong Hangzhou Manifest Tech Co Ltd (wait, did I buy a car or a computer?). Today I'll tell you about it.

Here's what this review isn't: in general it's not a review of the CPi DevTerm itself, though necessarily I'll mention some things of relevance. There are many of these reviews based on its previous iteration using aarch64 CPUs (mostly Cortex-A53 and A72) and the R-01 is literally just a DevTerm with a core module swap. Everything you'd like or hate about the form factor largely applies to both flavours, so refer to any of those existing reviews to determine whether you'd want a DevTerm at all regardless of what CPU's actually in it. Instead, I'm going to talk about this device specifically as a RISC-V general purpose computer, either if you'd just like a RISC-V machine to play with or to truly use as an alternative system on the road.

So, about that form factor. Although most people liken the DevTerm to the Tandy Radio Shack TRS-80 Model 100 (the most famous member of the Kyotronic 85 family), actually its design cues come more from the Model 100's close relative, the NEC PC-8201A. (Dig the control diamond: don't tell me that's a coincidence. For some reason CPi chose to make its codes separate from the cursor keys.) But I've used my PC-8201A on the road, for an entire month on Penang Island in Malaysia in 2000 where it was my only computer, and its full-size keyboard made it quite liveable. The DevTerm's a bit ... smaller — 65 percent regular size, to be exact. I have thin fingers (even when I was 45 pounds heavier) and wide hands, and I can sort of touch-type on it, or lift it in two hands and two-thumb-type with my hand width allowing my thumbs to just meet in the center of the keyboard. However, if you lack either of these attributes you may not enjoy the experience, though it has enough ports you could still potentially use it as a desktop system with external input devices instead. (The DevTerm keyboard is also not backlit, but I'm not going to ding it for that at this price point.)

Obligatory unboxing:

The box clearly advertises what's in it and, interestingly, the amount of RAM on the board (at 1GB this seems an odd thing to brag about).

Famously, it comes unassembled. Everything is in nice neat trays and it's actually rather fun to unpack. The plastic standoffs and holdfasts on sprues give it a delightful model-kit feel.

What's not included are a USB-C charger and two 18650 Li-Ion batteries. Neither of those is expensive or tough to find, but you'll need one or the other to actually power it up. There is also no paper for the thermal printer (!) it carries onboard, though any office supply store will have that too.

Case design, schematics and connectors are all GPL and on Github. The RISC-V "core," as CPi calls their CPU modules, sits on anti-static foam in one of the compartments:

CPi modules contain basically everything but storage and peripherals. In particular, the CPU/SoC, GPU (if present) and RAM are provisioned on a 200-pin SO-DIMM and can be swapped out (naturally you'd need to change the operating system at the same time, but that can be as simple as another microSD card). This is a strength of the design because if you don't like the experience with one CPU card (too slow? not compatible?), try another. CPi sells them inexpensively; if you already own an ARM DevTerm you can just buy the RISC-V module for US$29 and download the software. CPi kindly included a RISC-V build of their Ubuntu-based OS with this unit.

In this case, the CPU is an Allwinner D1, a single-core 1GHz RV64IMAFDCVU CPU based on the XuanTie C906 with on-board 2D graphics, DSP, audio/video, USB and SDIO. The DevTerm exposes HDMI, audio and USB external ports directly serviced by the D1. This is the same part in the Sipeed Nezha evaluation board and in a forthcoming SBC from Pine64. Impressively the RTL for the C906 core is open source and Apache-licensed, but unfortunately the rest of the design isn't: in particular the onboard graphics, DSP and peripheral controllers are only available as blobs, and only then if you register as a developer with Allwinner. For CPi's purposes this isn't a killer because their other CPU options are also blobularly blobtastic, but it's a minus in our book. The Hynix chip next to it is the RAM, a single gigabyte as stated. I cannot find any L2 cache at all, just the 32K L1 caches each for I+D.

Another minus is that the C906 and related cores, while they advertise vector instructions, predate the current RISC-V vector instruction standard. The instructions are similar but they are neither binary nor source compatible. On the other hand there's hardly anything supporting the current standard anyway, so this may not be a problem in the long run if the install base becomes large enough.

Getting out the clear orange scaffold and installing the screen, here's a size comparison against a DVD case to give you another idea about how big it is:

As you can see they're roughly the same size. If you'd find typing on a keyboard about half the size of a lengthwise DVD case difficult, the DevTerm is probably not for you. Anyway, let's finish putting it together.
Ta-daa! It took me about half an hour and it was pretty easy with no tools required. The manual goes step by step though they use a lot of part code shorthand that needed some flipping back and forth to check exactly what standoff, etc., I was supposed to be using where. While most of it can be taken apart as easily as it came together, some are glued stick-on components like the little on-board speakers and most notoriously the wireless antenna. I also didn't like the fact the flex cables are a little nervewracking to install and it took a little fiddling to convince myself they were properly seated (plus the video cable in particular has "SCREEN" silkscreened on it, but that end does not connect to the actual screen; it connects to the port marked "SCREEN" on the mainboard). Although it directs you to insert tiny screws to affix the core module to the board, there didn't seem to be any holes drilled on my board and the SO-DIMM socket seemed to hold the core just fine anyway. This might be something specific about the RISC-V module because the assembly manual is generic in scope. Finally, a pro-tip: it's easiest to put in the microSD card during assembly; it felt like I was inserting the card into an empty hole when I did it after, even though it did go in securely.

All that aside I give overall high marks to the fit and finish of the case, though it took me a little time to get the top to mate with the front lip of the bottom. And then there's those Frankensteiny Princess Leia earmuff closures on either side of the screen: they're cute and give it some personality, and they do hold the unit together, and I guess they're better than thumbscrews, but you almost expect them to have some sort of input device functionality and they don't. Missed opportunity, in my opinion. Plus, if you reopen the case the two halves of the closures come apart and have to be snapped back together, which is a little irritating. Once it is together, though, the case feels very sturdy. I liked how it felt in my hands; it didn't feel flimsy or fragile, and it was not excessively heavy even with the batteries in. Total weight according to my kitchen scale is 588g, or about a pound and a quarter.

Booting up! The manual warns it may take up to a minute, which wasn't too far off. The screen is very bright and legible, even considering the 1280x480 resolution is a little odd by modern standards (basically two VGA screens side by side), but it's very glossy and picks up hairs and fingerprints like a magnet. You probably want to have a microfibre cloth around in your bag for this thing.

And booted into CPi's bespoke Ubuntu variant, ClockworkOS. Despite the wiki (it's correct in the on-screen readme), the default username and password are both cpi.
Proof of uname:
ClockworkOS is very lightweight, and thank goodness it is for reasons we'll get into. There's no Wayland crap here; this is Xorg, as G-d Himself intended (especially because — as our frustrations with Wayland on our BMC-only 2D framebuffer Blackbird have proven — Wayland generally does not do well without a GPU even though it's doing better these days than it has). If the window manager looks throwback, it's because it's good old school twm. Fortunately the thumb trackball isn't too bad but there are key combinations for several marquee apps, which I found to be a thoughtful touch.

The status monitor on the right is also very handy, but you'll notice the clock is wrong, and the reason the clock is wrong is because it couldn't contact any time servers. Despite manually creating a network configuration for the house Wi-Fi, the DevTerm wouldn't connect from the front of the house (the Wi-Fi access point is in the server room in the middle) even though every other Wi-Fi capable device I own is able to do so. I was so perplexed by the range I ended up disassembling it again to check if I'd damaged the antenna or if it had come loose when I turned it over to put on the bottom, but the antenna was physically intact and the connector was snapped securely onto the mainboard. The only way it would connect was if it were closer to it. Various Wi-Fi issues have been reported with the DevTerm's relative GameShell, which appears to use the same sort of antenna, though I'm not sure if this is the same specific problem.

There are lots of fun pieces of software pre-installed like DOSBox and Chocolate Doom (and things like GIMP, Inkscape and Xfig if you want to do real work), so I fired up Doom because of course it plays Doom to get an idea of performance. The CPU immediately showed as pegged in the status monitor, which was not encouraging. Neither was gameplay:

I mean, the poor thing's even using a smaller viewport (by default: it started up that way) and the CPU is still straining at 99%. The framerate wasn't slide-show-slow and music and sound effects didn't seem to suffer (use Fn+the volume key to turn up the audio), but you could clearly see it painting each frame.

Web browsing was equally disappointing, but also for different reasons. Firefox on RISC-V is still a work in progress, although there was an Fx94 build at one point; there are patches for Chromium 104, though I wouldn't be caught dead using Chrome or anything derived from it, and neither Firefox nor Chromium are installed in any case. But it does have Qutebrowser, so let's try ... uh ...

Um, okay, how about ELinks?
This worked and might even be more appropriate for the display and CPU anyhow. It was very sprightly. Text for the win. I did go back to Qutebrowser and try QtWebKit despite the warning, and that does start, but ...
Besides the bad rendering, it was also just as slow as playing Doom was. At this point it would seem most appropriate to get an idea of how much oomph this thing actually has. For this we'll use CoreMark, since it's simple, easy to port and verifiable, and it's what many RISC-V vendors cite so this gives you comparison points. ClockworkPi kindly included development tools making it as simple as cloning it from Github and running make.
A couple benchmark results first, using default settings and reporting the highest score obtained: my NetBSD Macintosh IIci (25MHz Motorola 68030, no cache card) gets 8.3 iterations/second, my NetBSD Mac mini (1.5GHz PowerPC G4 7447A) gets 6073.9 iterations/second, my M1 MacBook Air gets 31713.3 iterations/second (single thread) and 171848.9 iterations/second (8 threads), and this dual-8 SMT-4 DD2.3 Raptor Talos II gets 14367.8 iterations/second (single thread) and 430078.6 iterations/second (64 threads). The D1 clocks in at ... 2232.5 iterations/second, just over a third of the performance of the G4 Mac mini, and I can run TenFourFox on that.

Another thing that performs badly on this device: shutting down. It takes literal, honest-to-goodness multiple minutes to power off cleanly. A surprise was the loud "click" it makes when it finally finishes. There doesn't appear to be an obvious way to make it sleep or suspend, though there is a screen saver which turns off the display after a period of inactivity.

I imagine some of these software problems will improve in later iterations, but as it stands this was my out-of-the-box user experience right now (in fairness CPi does say it is a "highly experimental" model, and actively steers new users away from it). I suppose you could try other distros but they may not support (fully) the DevTerm's onboard devices.

Now, something positive: battery life and power consumption seemed really good. The CPU may be weaksauce but it doesn't put a lot of power demand on the hardware either, nor is there a GPU to draw more juice, and the backlight can be easily changed with key combinations or terminal commands. And although there's a tiny little fan on the board I never heard it unless I put my ear right up against it and the device never seemed to get hot even when it was being held at its limits (which was a lot of the time). While the status monitor will show battery percentage (second from the bottom, above the uptime), cat /sys/class/power_supply/axp20x-battery/uevent will display a fuller, different set of statistics that don't always agree. Either way it's thrifty enough I'd estimate you can probably get eight, maybe 10 hours of runtime or more out of a full charge depending on load and battery quality. On the Kill-A-Watt the USB-C charger pulled between 11 and 14 watts depending on CPU load, though even with the CPU pegged in Chocolate Doom it only occasionally drew at the upper end of that range. Incidentally, since the batteries are removeable it's probably more efficient just to shut it down, take them out and stick them in a wall charger at the end of the day.

You might think after all the complaints I've made that I don't like this device. That is absolutely not the case; in fact, I've already become rather fond of it. I'll even go so far as to say that if you want an easy way to try RISC-V and want one you can use like a general purpose computer, and you're not already drunk on the Kool-Aid, then the DevTerm R-01 is your ticket. Clockwork Pi should be commended for offering it and charging less for it on top of that. Offered the choice between a HiFive Unmatched system and the DevTerm R-01, even considering the Unmatched will be somewhat more powerful, I'd still pick the DevTerm. Besides its obvious space and price advantages it's at least got enough grunt to serve as a terminal and do some very basic tasks and do it for hours on easily replaceable batteries, and it comes with sufficient developer tools out of the box that you can test your software on actually available RISC-V silicon today. Plus, with HDMI, USB and Bluetooth, you can just dock it as a desktop system if you don't need it to be mobile. While I certainly had my share of software problems, I suspect they are not at all unique to this particular implementation.

No, my objections here are primarily to the Allwinner D1. For as many claims as RISC-V's proponents make about openness, this chip isn't meaningfully so, and its underwhelming performance doesn't make it worth putting up with. I realize it's aggressively low-end but for crying out loud, it's getting its clock cleaned by a value-spec 2005 Power Mac (the U740 in the Unmatched gets by the G5, but by less than you'd think), and some software still doesn't work on the architecture yet — certainly more so than OpenPOWER. About all it's got going for it is that it can clearly do very well in a portable, power-constrained environment, and it's cheaper than ARM would be in that setting, yet despite such obvious shortcomings it and its progeny are the very chips here and in other upcoming products simply because they exist and survive. Is RISC-V going to be perennially bringing up the performance rear? (Hey, Raptor, want to make a souped-up Arctic Tern in this form factor?) Not for nothing but I don't see anyone selling those ballyhooed Micro Magic parts, and they may well be snake oil. Maybe some future RISC-V system will have sufficient performance, low power usage and full auditability to become a new and self-sustaining libre mobile option, but I'm having a hard time seeing any such CPU on the horizon.

The bottom line: the DevTerm R-01 is fun to play with and makes a stellar introductory RISC-V general purpose computer at a decent price that you can, for some values of "use," use. If you're already a DevTerm owner a measly US$29 for an R-01 module is a slam dunk, and even as a first-time buyer I feel my US$240 wasn't ill-spent. But after this first personal taste of RISC-V, I don't think OpenPOWER has much to worry about right now.

Fedora 35 mini-review on the Blackbird and Talos II


Happy American Thanksgiving. While America watches football and eats deep-fried gobbler, we went to the Popeye's drivethru for chicken and I finished updating Fedora on my daily driver, now at version 35 (see our prior review of Fedora 34). As I always point out: while Fedora is a very common distro on OpenPOWER systems, even if you don't necessarily run Fedora yourself the fact that it does run is important, because it tends to be very ahead of most distros and many problems are identified and fixed in it before moving to other less advanced ones. I test it on my 4-core BMC graphics Blackbird and my dual-8 AMD WX7100 GPU Talos II.

F34 was a messy, unpleasant upgrade. I did the update first on my 4-core stock Blackbird, which I try to keep to stock Fedora as much as possible, though I note for the record both the Bird and the T2 are configured to come up in a text boot instead of gdm and I start GNOME manually from there. I strongly recommend this to act as a recovery mechanism in case your graphics card gets whacked by something or other. On Fedora this is easily done by ensuring the symlink /etc/systemd/system/default.target points to /lib/systemd/system/multi-user.target. Once you've logged into the console jump to GNOME with startx (set XDG_SESSION_TYPE to x11 if this isn't already done), or XDG_SESSION_TYPE=wayland dbus-run-session gnome-session if we want to explore the Wayland Wasteland. Since this is a minimal boot I can also do the upgrade at the same text prompt for speed and ensure as little interference as possible. As usual, the process is, from a root prompt:

dnf upgrade --refresh # upgrade prior system and DNF
dnf install dnf-plugin-system-upgrade # install upgrade plugin if not already done
dnf system-upgrade download --refresh --releasever=35 # download F35 packages
dnf system-upgrade reboot # reboot into upgrader

This went much more smoothly than F34, which had some weird conflicts; it was able to get the necessary packages right away and booted into the installer with no issue. Back at the text prompt, we started with Wayland, as I always do to see if it's still going to suck, and I'm still not disappointed. Performance was even worse than F34, it got glitchy just trying to take a grab with gnome-screenshot from the command line (see this Reddit thread) and BMC video (through the on-board HDMI connector) is still stuck at 1024x768. I took this on my Pixel 3 after I got tired of mucking around with it.

As before don't even bother with Wayland on a Blackbird if you don't have a GPU. Xorg worked fine but was still slow like F34 was. I'll get to that in a moment.
Otherwise, in Xorg, the system, Firefox and LibreOffice mostly worked as before modulo the performance problems, which was a relief.

The T2 tends to be a different story because I have this system heavily customized. Additionally, kernel 5.14 has a known problem with AMD Vega cards (add amdgpu.aspm=0 to your kernel command line as a workaround), and 5.15 may have an issue with amdgpu in power saving mode, so watch out for both of these problems depending on your GPU. (At least one user reported having to blacklist the AST BMC, though that wasn't necessary for me.)

The first problem was more elemental, however: after I downloaded the packages and ran the installation, it still came up offering an impossibly old kernel - the same thing I had to work around with updating to F34!

When I selected it, it started Fedora 35, but with this old 5.11-series kernel from Fedora 34. I did a manual grub2-mkconfig -o /boot/grub2/grub.cfg and restarted, and the Petitboot menu (built off the grub configuration) looked sane again. The text boot came up without incident.

Next, the desktop environment. Usually GNOME upgrades break a large number of my cherished extensions. Surprisingly, only Dash-to-Dock broke this time, which I rebuilt from a fork using these instructions. Note, however, that I do have disable-extension-version-validation set to true in dconf-editor which helps avoid a lot of churn.

However, the same GNOME regressions turned up in F35 that were in F34: CTM still makes a mess out of my custom colour profiles (again something like xrandr --output DisplayPort-0 --set CTM 0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1 will fix it, but this changes based on how your monitors are connected, and every time you [re]start GNOME you'll have to do it), colour calibration still crashes with my Pantone huey, and graphics were still awfully slow. This performance problem is once again libgraphene not being properly built to enable SIMD; the fix was made by the maintainer but the Fedora-distributed library doesn't seem to incorporate it properly. I rebuilt it on F35 and put a copy on Github. It will replace the file of the same name in /lib64 (remember to make a backup and don't do this while GNOME is running).

I'll not comment much further about Wayland except to say that it continues to meet my low expectations on the T2, but as it still doesn't support what my work habits require, I still don't use it. But you can, at least if you have a working discrete graphics card and you've updated libgraphene. For me, Xorg forever, I guess.

My conclusion is damning with faint praise: at least it wasn't any worse. And with these tweaks it works fine. If you're on F34 you have no reason not to upgrade, and if you're on F33 you won't have much longer until you have to (and you might as well just jump right to F35 at that point). But it's still carrying an odd number of regressions (even though, or perhaps despite the fact, the workarounds for F35 are the same as F34) and the installation on the T2 was bumpier than the Blackbird for reasons that remain unclear to me. If you run KDE or Xfce or anything other than GNOME, you shouldn't have any problems, but if you still use GNOME as your desktop environment you should be prepared to do more preparatory work to get it off the ground. I have higher hopes for F36 because we may finally get that float128 update that still wrecks a small but notable selection of packages like MAME, but I also hope that some of these regressions get dealt with as well because that would make these updates a bit more liveable. Any system upgrade of any OS will make you wonder what's going to break this time, but the most recent Fedora updates have come off as more fraught with peril than they ought to be.

Fedora 34 mini-review on the Blackbird and Talos II (it sucks)


Once again it's time to upgrade Floodgap's stable of Raptor systems to the latest release of Fedora, which is up to version 34 (see our prior review of Fedora 33). You may not necessarily run Fedora yourself, but the fact that it does run is important, because it tends to be very ahead of most distros and many problems are identified in it and fixed before moving to other less advanced ones. And boy howdy, are there problems this time. I'm going to get it over with and tl;dr myself right now: if you use GNOME as your desktop environment and you haven't upgraded yet, DON'T. F34 and in particular GNOME 40 are half-baked, and the problems don't seem specific to OpenPOWER and the hard work of folks like Dan Horák; these issues are more generalized. There is always that sense of dread over what's going to break during the update, and while I'm finally typing in Firefox on this updated Talos II, it took me hours to get everything glued back together and the desktop performance problems in particular are cramping my ability to use the system well. Fedora 33 will still be supported until a month after F35 comes out; it may be worth sticking with F33 for a couple months for the GNOME team to work on the remaining performance issues.

The problems started from the very beginning, even before actually updating. I do my updates initially on the Blackbird to shake out any major problems before doing it to my daily driver T2. As I explained previously, neither the Blackbird nor the T2 use gdm; they both boot to a text prompt, and we jump to GNOME with startx (or XDG_SESSION_TYPE=wayland dbus-run-session gnome-session if we want to explore the Wayland Wasteland). I do the upgrade at the text prompt so that there is minimal chance of interference. Our usual MO to update Fedora is, as root,

dnf upgrade --refresh # upgrade prior system and DNF
dnf install dnf-plugin-system-upgrade # install upgrade plugin if not already done
dnf system-upgrade download --refresh --releasever=34 # download F34 packages
dnf system-upgrade reboot # reboot into upgrader

If you do this with F34, however, you get a number of downgrades (unavoidable, apparently), missing groups and an instant conflict with iptables when you try to download the packages:

dnf suggests we add --best --allowerasing to deal with that. It doesn't work:
Neither does adding --skip-broken. The non-obvious solution is dnf system-upgrade download --refresh --releasever=34 --allowerasing, and just ignoring the duff package.
The Blackbird does not have a GPU; all video output is on the ASPEED BMC (using the Blackbird's HDMI port). Ordinarily I would select the new kernel from Petitboot when it restarts after the final command above to see a text log of the installation but this time we get an actual graphical install screen.
After the installation completed, the machine rebooted uneventfully and came up to the text prompt. I entered startx as usual and ...
At this point GNOME just plain hung up. There was no mouse pointer, though pressing ENTER on the keyboard triggered the button and put it back to the text prompt. Nothing unusual was in the Xorg logs, and journalctl -e showed only what seemed like a non-fatal glitch (Window manager warning: Unsupported session type). Well, maybe the time for the Wayland Wasteland was now. I did an exec bash (gnome-session doesn't properly handle using another shell, or you get weird errors like Unknown option: -l because it tries to be cute with the options to exec) and XDG_SESSION_TYPE=wayland dbus-run-session gnome-session, and Wayland does start:
However, it still doesn't support 1920x1080 on the Blackbird on-board HDMI, just 1024x768. It also seemed a little sluggish with the mouse. I exited it and tried to start gnome-session --debug --failsafe but it wouldn't initialize.

It then dawned on me that I was setting XDG_SESSION_TYPE manually for Wayland; I previously left it unset for X11. Setting XDG_SESSION_TYPE to x11 finally brought up GNOME 40 in X with a full 1080p display:

I put that into my .cshrc and that was one problem solved. The Applications drawer seemed a little slower to come up, though I have a very vanilla installation on this Blackbird on purpose and few apps are loaded, so I didn't try scrolling through the list or running lots of applications at once. (More on that in a moment.)

Just to see if anything shook out subsequently, I ran dnf upgrade again. This time the missing iptables compatibility packages came up:

That solves that mystery, so just ignore iptables during the initial download and the next time you run dnf after Fedora has been upgraded, it will clean up and install the right components. This whole sordid affair now shows up in the Release Notes.

Upgrading the Talos II is usually a much more complex undertaking anyway because I have custom GNOME themes and extensions installed on it and I always expect there will be some bustage. I don't like it, mind you, but I expect it. Armed with what I had learned from the Blackbird, I installed the packages on the T2 (some other groups also had "no match," though all of my optionally installed packages could and did upgrade) and rebooted.

Unlike the Blackbird, however, the installer still came up in a text screen as in prior upgrades when I selected that kernel from the Petitboot menu.
This machine has the BTO AMD WX7100 workstation card and does not use the ASPEED BMC framebuffer. If you don't select the kernel from the menu and just let the default go, you will get the usual black screen again, and as in prior versions you'll have to pick another VTY with CTRL-ALT-F2 or something, log in as root and periodically issue dnf system-upgrade log --number=-1 to watch.

I rebooted and started X (with XDG_SESSION_TYPE=x11), and GNOME came up, but it looked a little ... off.

If you noticed the weird pink-purple tint, you win the prize. However, my second monitor seemed to have a normal display (so did the Blackbird), and the difference is that my main display is colour-managed. When I selected the default profile, the tint went away but my colours weren't, you know, just right. I spent a few hours regenerating the profile with my Pantone huey manually with dispcal, but the same thing happened with the new profile.

The problem is the new colour transform matrix (CTM) support; the prior profile obviously worked fine in 3.38 but isn't compatible with 40. The proper way to solve this would be by letting GNOME make a new colour profile for you from the Settings app and it even allegedly supports the Pantone huey and other colourimeters. However, it has never (to my knowledge) worked properly on OpenPOWER (it crashes), so I've never been able to do this myself. Instead, my current solution is to just temporarily disable CTM with

xrandr --output DisplayPort-0 --set CTM 0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1

(that's 0, 1, seven zeroes, 1, seven more zeroes, and 1). Adjust DisplayPort-0 to where your colour-managed display is connected. Note that every time you (re)start GNOME or its shell, it will forget this setting and you'll have to enter it again. It would be nice if the colour manager could work with OpenPOWER, but CTM should have never broken working profiles in the first place.

However, that all got solved later, because an even more pressing concern popped up first: the UI was slow as molasses. GNOME 40 defaults to the Activities overview on startup with nothing running. It takes literally several seconds to move from one page of activities/apps to the next. Several seconds. This problem is not unique to OpenPOWER, and occurs on both Wayland and Xorg, but a general fix is apparently months away.

The performance problems are not X11-specific. In fact, Wayland is even worse, because the mouse stutters even just moving it around. This is the first time Wayland is actually worse on the system with the GPU (the T2) rather than the system without one (the Blackbird), though I hardly consider this regression a positive development.

What am I doing about it? Well, what can I do about it, short of trying to fix it myself? GNOME is the default environment for Fedora Desktop, and while I could switch to KDE or Xfce (and I might!), these are serious regressions that are hitting a decent proportion of users and were even evident during the beta phase. Did QA just fall asleep or something? To top it off, even if it were working well, whose freaking bright idea was it to make you go to the upper left corner to click Activities, then back to the bar to click the Show Applications button, just to pull up what you have installed? I've started using the Applications menu that Fedora includes by default; at least that doesn't take a Presidential administration or two or wild sweeping mouse gestures just to show you a list of apps, even though it's still noticeably slower than 3.38.

The slowdowns are entirely specific to GNOME. Once you actually get an app started, like Firefox or a game, display speed is fine, so the problem clearly isn't pushing pixels; it's something higher level in GNOME. Switching all the core scheduling to performance made at most minimal difference. Similarly, (as root) echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level instead of auto made things a little better, but there is still no excuse for how bad it is generally. About the only thing that made more difference than that was simply turning animations off altogether in GNOME Tweaks. Nothing was smooth anymore, but it was about twice as fast at doing anything, so that's how I'm limping along for the time being.

With those significant problems on deck, the usual turmoil with custom themes and extensions is actually anticlimactic. I had to make some tweaks to my custom Tiger-like GNOME shell extension to fix the panel height and a weird glitch with slightly thicker border lines on the edges of the panel, which you can see in the screenshot below. Quite a few extensions could not automatically update to GNOME 40, either:

I've become irritated enough by this that I actually did set disable-extension-version-validation to true in dconf-editor, which made a couple start working immediately, including my beloved Argos custom script driver. For the others I downloaded the most current version of the shell system monitor and this fork of Dash-to-Dock, and manually installed them in ~/.local/share/gnome-shell/extensions/ (you may need to reset the GNOME shell with Alt+F2 and r to get gnome-extensions enable to actually see their UUIDs). A few I should have dispensed with earlier: No Topleft Hot Corner can now be simply replaced by gsettings set org.gnome.desktop.interface enable-hot-corners false, and AlternateTab's switcher behaviour now can be rigged manually from GNOME Settings.

I'm now more or less back where I started from, but working with apps is much less fluid and the desktop experience is undeniably inferior to prior releases, and I can't believe no one thought to blow the whistle during the test phase.

If you use Fedora purely as a command-line server, other than the initial hiccups with downloading packages, it seems to work. If you use KDE or Xfce or anything other than GNOME as your desktop, you're probably okay with F34 too, though I didn't test those (I may later). But if you use the default GNOME on Fedora, especially if you use Wayland, think twice about this update before installing it while you've still got some time with F33. Part of riding the bleeding edge is drawing blood now and then, but F34's wounds seem much more self-inflicted than usual. This is the worst Fedora update since I started using it in F28 and I'm not exaggerating in the slightest.

Fedora 33 mini-review on the Blackbird and Talos II


To avoid watching American election returns, it's time to report back on our traditional mini-review for the newest release of Fedora, F33. If you run it yourself hopefully this will help your upgrade go more smoothly, and even if you don't you should still care about it because bugs in packages and platforms usually pop up in Fedora's cutting edge first (after all, F28 was one of the first out-of-the-box distributions to even run on POWER9). Now that F33 has hit the release channel, F31 will become EOL in less than a month.

We test it on both the Blackbird and Talos II, for which T2 Lite owners will have a similar experience. However, one important configuration change for this review compared to my previous go-around for F32 is that I'm no longer running gdm on the Blackbird either (I've never run it on the T2). This was largely an accident of a F32 reinstall I did, where I installed the server variant and converted it to Fedora Workstation, same as I had originally done for my T2 back with F28. In this setup the system comes up in a text boot, you log in that way, and then manually startx or dbus-run-session gnome-session (with XDG_SESSION_TYPE=wayland or as appropriate) to launch GNOME. Besides speeding startup a bit, you avoid pitfalls with a graphical start and can much more easily recover without having to do an emergency boot into the installer. This and future reviews of Fedora will be done in this configuration which just eliminates a whole class of issues I used to have on the Blackbird in particular.

As before, the general upgrade steps are

sudo dnf upgrade --refresh # upgrade DNF
sudo dnf install dnf-plugin-system-upgrade # install upgrade plugin if not already done
sudo dnf system-upgrade download --refresh --releasever=33 # download F33 packages
sudo dnf system-upgrade reboot # reboot into upgrader

When the system reboots, manually select the kernel directly from Petitboot to get a more verbose boot rather than just waiting for it to automatically start. This let me watch the install in text mode for a change. If you don't do this, your system may go to a black screen; pick another VTY with CTRL-ALT-F2 or something, log in as root and periodically issue dnf system-upgrade log --number=-1 to watch the hot hot action.

The Blackbird is my "early warning" system to catch bad updates before I tank this daily driver T2. However, perhaps because it has a vanilla install of F32 on it, it updated without any problems whatsoever, and all applications that I usually use on it (Firefox, LibreOffice, etc.) ran without issues under Xorg in 1920x1080 with the usual manually specified xorg.conf. I didn't notice much performance improvement or change, but nothing seemed to regress particularly either.

I also usually do a token test of Wayland on the Blackbird as well, which because I run it "stripped" with no GPU and with only the BMC as a framebuffer, is invariably an unusable catastrophe. But, to my surprise, not this time:

I'm a Never Wayland and I acknowledge my biases, but there has been clear improvement in its useability without a GPU, which right now is essential to run these systems "fully libre" (or at least as cheaply as possible). I suspect the LLVM update is responsible and sufficiently juices llvmpipe accordingly, but regardless of the reason the system was much more responsive and all default applications seemed to work.

What didn't, though, was the screen resolution, which remained stuck at 1024x768 because support for the Blackbird's HDMI transceiver is still not in the shipping kernel. I grabbed edid-generator and tried making an EDID out of the known-working Xorg modeline, which was ignored at bootup and dmesg said it didn't even load:

platform VGA-1: Direct firmware load for edid/bmc.bin failed with error -2

(Yes, the port name is VGA-1, despite being connected over HDMI.)

I also tried video=VGA-1:1920x1080@60e on the kernel command line and while the text boot obligingly came up in 1920x1080, when I started the GNOME session it just hung and never jumped to the graphic display, so back to Xorg. But credit where credit is due that it's getting better, whether Wayland or LLVM is responsible for the improvement.

The T2 is more complex because I have a lot more packages installed and a somewhat customized GNOME theme. Although I lost a few packages in F32, no packages were broken or needed to be backed out for F33, and the 5.0GB installation proceeded uneventfully. With fast reboots off it also properly restarts as well.

Restarting into the new installation for the first time is usually where the problems start, though, and that's what happened again this go-around. The first problem was a crapload of SELinux warnings over and over, which turned out to be another permissions clash and was eventually fixed with a restorecon -RFv /var/lib/rpm after a lot of totally family friendly cursing. The second problem is the usual GNOME extension breakage as F33 moves from 3.36 to 3.38; Dash-To-Dock again refused to update and had to be manually reinstalled from the command line as well as User Themes. However, my hacked version of Argos survived without any changes. The drag-to-reorder feature new in 3.38 mostly works as advertised, though I'm used to apps moving to close the gap and that didn't seem to happen, but I do like the changes to Screenshot.

On the T2's BTO WX7100 GPU, GNOME 3.38 under Xorg was nice and snappy as always. I didn't notice really any performance improvement, but it seemed no worse either. Wayland did improve in this iteration and the games it used not to launch now seem to start properly under Xwayland, but it seemed a little less sprightly this time. Likewise, I'm highly reliant on appmodmap for my muscle memory which won't work with any current Wayland compositor, and while GNOME's new ability under Wayland to run multiple displays at different refresh rates is a nice new feature, I don't need it for my two displays. So back to Xorg. (If maintaining Xorg is such a paper cut with hydrochloric acid on it, then why don't we use Wayland for the low-level display stuff and just run everything in Xwayland on top of it? Why must we throw the baby out with the bathwater? I like all the hacks X lets me do.)

Anyway, F33 was a largely uneventful release and I consider that a positive: while the normal little polish issues are still there it didn't seem to require pulling more teeth than usual and overall has been working well for the last couple days. What I really want, though, is for 128-bit long doubles to finally arrive and I'd really like to see a push for this in F34. Me personally I'm tired of having to hack MAME all the time just to play the same games my G5 can with MacMAME, but there are more practical and less first-world-problemy concerns for needing this feature as well. And it would really be a boon to the platform if we weren't still stuck in the Alternative Architectures penalty box every time too.