Translate

Archives

List ACPI Tables From UEFI Shell

This post demonstrates a small UEFI shell utility which list out the ACPI tables in your firmware.

Installing Google Chrome 38 on Fedora 21 Alpha

Download the current stable Google Chrome RPM. As of today’s date this is revision 38.0.2125. You also need to install two package to get libXss.so and lsb (Linux Standards Base) compatibility. # yum install libXScrnSaver redhat-lsb # rpm -Uvh google-chrome-stable_current_x86_64.rpm One of the major new features in this version of Chrome is support for a security key such as the Yubico FIDO U2F for two-factor authentication. Note that FIDO U2F devices do not currently work with Fedora 21 Alpha. Such devices work perfectly well on the Windows build of the Google Chrome browser. However, on the alpha version of Fedora

Unix Domain Sockets

Unix domain (UD) sockets are an inter-process communication (IPC) mechanism that allows bidirectional data exchange between processes running on the same platform. They are sometimes called local sockets. Communication occurs entirely within the operating system kernel. The closest IPC mechanism to a UD socket is probably a Unix pipe or a Linux Netlink socket. Note that the term domain in UD has nothing to do with DNS, NIS, LDAP, or Active Directory, and instead refers to the file system. A UD socket is uniquely identified by a filesystem pathname. Obviously, both processes have to agree on the pathname for them

Anaconda Fails When BIOS RAID Metadata Encountered

Anaconda (the RHEL, CentOS and Fedora installer) does not handle disks which were previously used in a BIOS or software RAID very well. Typically, it will refuse to install an OS on such disks. This is because it finds metadata relating to the RAID on the disk. The term BIOS RAID (or Fake RAID) denote a system with a BIOS that is able to do basic RAID operations on an array of disks. Such a system has no actual RAID controller. Instead, an OS driver is required. One metadata format commonly found on modern RAID systems (real as well as

Systemd and /etc/fstab

Once again Lennart Poettering and Kay Sievers have managed to complicate things and broken the simple model that served the Unix and Linux communities well for over 30 years, i.e. that details of filesystem mounts that should persist across a reboot are listed in /etc/(v)fstab. With systemd, mount units may either be configured via unit files, or via /etc/fstab. Mounts listed in /etc/fstab are converted into native units dynamically using systemd-fstab-generator at boot time or when the system manager configuration is reloaded. In general, configuring mount points through /etc/fstab is the preferred approach. A systemd unit configuration file whose name