UEFI has been the official future of x86 PC firmware for a very long time, and for much of that time your machine's UEFI firmware has still been willing to boot your systems the traditional way x86 PCs booted before UEFI, with 'BIOS MBR' (generally using UEFI CSM booting). Some people have no doubt switched to booting their servers with UEFI (booting) years ago, but for various reasons we have long preferred BIOS (MBR) booting and almost always configured our servers that way if given a choice. Over the years we've wound up with a modest number of servers which only supported UEFI booting, bu ..read more

IBM compatible x86 PCs have come with firmware since their first days. This firmware was called (the) BIOS, and so over time 'BIOS' became the generic term for 'IBM compatible x86 PC firmware' (which could come from various companies who carefully reimplemented it from scratch in ways that didn't violate IBM's copyrights). Over time, PC firmware ('BIOS') got more complex and acquired more (boot time) user interface features, like all sorts of splash screens, tuning options, semi-graphical interfaces, and so on. However, the actual BIOS API, primarily used at boot time, stayed more or less unc ..read more

Historically, many filesystems have devoted a significant amount of effort to sophisticated space allocation policies. For example, in Unix one of the major changes from V7 to 4.x BSD was the change to the Berkeley Fast File System (also) with its concept of 'cylinder groups' that drastically improved the locality of file data, directory data, and inodes. Various other (Unix) filesystem allocation related technologies have been developed since, for example the idea of delaying deciding where exactly data will live in the filesystem until it's about to be written out, which allows the filesyst ..read more

Today we discovered something: Apparently our (university) machine room now comes with the bonus of a visiting raccoon. I have nothing against Toronto's charming trash pandas, but I do have a strong preference for them to be outdoors and maybe a bit distant. (There are so far no signs that the raccoon has decided to be a resident of the machine room. Hopefully it is too cool in the room for it to be interested in that.) Naturally there is a story here. This past Monday morning (what is now two days ago), we discovered that over the weekend, one of the keyboards we keep sitting around our ma ..read more

Once upon a time, back a reasonable while ago, I used to routinely configure (in the './configure' sense) and build a fair amount of software myself, software that periodically got updates and so needed me to rebuild it. If you've ever done this, you know that one of the annoying things about this process is keeping track of just what configuration options you built the software with, so you can re-run the configuration process as necessary (which may be on new releases of the software, but also when you do things like upgrade your system to a new version of your OS). Since I'm that kind of p ..read more

In the wake of the XZ Utils backdoor, which involved GNU Autoconf, it has been popular to suggest that Autoconf should go away. Some of the people suggesting this have also been proposing that the replacement for Autoconf and the 'configure' scripts it generates be something simpler. As a system administrator who interacts with configure scripts (and autoconf) and who deals with building projects such as OpenZFS, it is my view that people proposing simpler replacements may not be seeing the features that people like me find valuable in practice. (For this I'm setting aside the (wasteful) cost ..read more

Today, not for the first time, I discovered that one project that we use locally had made a new release (of one component) by updating my local copy of their Git repository and noticing that 'git pull' had fetched a new tag. Like various other projects, this project has an official channel to announce new releases of their various components; in this case, a mailing list. Sadly, the new release had not been announced on that mailing list, although other releases have been in the past. This isn't the only project that does things like this and as a busy system administrator, I wish that they w ..read more

In the sidebar to yesterday's entry I (originally) made a Unix command line mistake by unthinkingly leaving out an ordinary, innocent looking space (it's corrected in the current version of the entry after it was noted by Emilio in a comment). This innocent looking mistake and its consequences are an illustration of something in Unix shell command lines, although I'm not sure of just what, so I'm going to write it up. The story starts with the general arguments of Bash's 'read' builtin: read [-ers] [-a aname] [-d delim] [-i text] [-n nchars] [-N nchars] [-p prompt] [-t timeout] [-u fd] [name ..read more

Suppose that you need to scan your filesystems and pass some files with specific names, ownerships, or whatever, except that you want to exclude scanning under /tmp and /var/tmp (as illustrative examples). Perhaps also you're feeding the file names to a shell script, especially in a pipeline, which means that you'd like to screen out directory and file names that have (common) problem characters in them, like spaces. (If you can use Bash for your shell script, the latter problem can be dealt with because you can get Bash to read NUL-terminated lines that can be produced by 'find ... -print0 ..read more

One of the things that I sometimes need to do with my libvirt-based virtual machines is connect to their 'graphical' consoles. There are a variety of ways to do this, but generally the most convenient way for me has been virt-viewer, followed by virt-manager. Virt-viewer is typically pretty great, but it has one little drawback that surfaces with some of my VMs, especially the Fedora ones that boot into graphics mode. The standard behavior for Fedora machines sitting idle in graphics mode, especially on the login screen, is that after a while they'll blank the screen, which winds up turning o ..read more