Categories
System Administration

Native exFAT support on Fedora 32

A lot has changed since 2018 when exFAT was kept out of Fedora due to patent issues and a third-party FUSE-driver needed to be used. Until recently the GPLv2 based driver from Microsoft wasn’t enabled in the kernel as it was based on an older specification and wasn’t fully functional for everyday use.

$ grep EXFAT /boot/config-`uname -r`
# CONFIG_EXFAT_FS is not set

Fedora 32 recently received an upgrade to kernel 5.7 and with that, the native exFAT driver was enabled during compile time. The driver got a lot of updates from Samsung to work correctly to the latest specifications.

# DOS/FAT/EXFAT/NT Filesystems
CONFIG_EXFAT_FS=m
CONFIG_EXFAT_DEFAULT_IOCHARSET="utf8"
# end of DOS/FAT/EXFAT/NT Filesystems

When an SD-card is now plugged into the machine, the kernel module is loaded and the filesystem is mounted by the kernel without the need of a userland driver.

 $ lsmod | grep fat
exfat                  81920  1
vfat                   20480  1
fat                    81920  1 vfat
$ mount | grep fat
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
/dev/mmcblk0p1 on /run/media/user/disk type exfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro,uhelper=udisks2)

The userland tools may come with Fedora 33, but the package exfat-utils from RPMFusion still need to be installed until it ships with Fedora.

Categories
System Administration

Docker on Fedora 31 and 32

For “Developing inside a Container” with Visual Studio Code, one of the requirements is to use Docker Community Editon as the version of Docker that ships with Fedora is too old and misses certain features. Also the new Docker alternative Podman from Red Hat isn’t supported by Visual Studio Code.

After installing Docker CE on Fedora 31, cgroups version 1 needs to be enabled as Linux switched over to cgroups version 2, but Docker still depends on version 1. With the commands below cgroups version 1 can be enabled again and requires a rebooting of the system.

$ sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"
$ sudo systemctl reboot

Now with the upgrade to Fedora 32 something interesting happens as firewalld is switching from iptables to nftables as a new way to do firewalling on Linux. It basically stops all traffic for the docker0 network and made Molecule fail to build container images for the tests. With a simple test as in the example below, the broken situation can be confirmed.

$ docker run busybox nslookup google.com
 ;; connection timed out; no servers could be reached

One of the solutions is to put containers directly into the host network, but this is unwise as it exposes containers to network and directly reachable for others. Another solution that requires fewer changes is to assign docker0 interface to the trusted zone within firewalld.

$ sudo firewall-cmd --permanent --zone=trusted --add-interface=docker0
$ sudo firewall-cmd --reload

Running the test case again, then it gives back the correct result as the container can communicate again via the docker0 interface to the assigned name server.

$ docker run busybox nslookup google.com
 Server:         192.168.178.1
 Address:        192.168.178.1:53
 
 Non-authoritative answer:
 Name:   google.com
 Address: 172.217.19.206

While this solves the problems with Docker for now it is good to know that these changes should be temporary as Docker needs to support cgroups version 2 as support for version 1 may be dropped in the future. Secondly firewalld needs to get propper nftables support as the migration from iptables currently isn’t as smooth as it should be.

Categories
System Administration

Setting a different libvirt uri for Vagrant

HashiCorp Vagrant normally selects the right hypervisor, but the version shipped with Fedora 30 prefers to run within the QEMU user session of the hypervisor. A Vagrantfile it would match the default behavior which doesn’t require any system privileges is shown below.

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.synced_folder ".", "/vagrant", disabled: true
  config.vm.define "test01" do |test01|
    config.vm.box = "centos/7"
    config.vm.box_version = "1902.01"
    config.vm.hostname = "test01.localdomain"
    config.vm.provider :libvirt do |domain|
      domain.uri = 'qemu:///session'
    end
  end
end

In some cases a virtual machine needs to run on QEMU system level and that can be done by changing the domain.uri from “qemu:///session” to “qemu:///system”. Vagrant now creates the virtual machine at the system level of the hypervisor and isn’t depending on any user environment to run.

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.synced_folder ".", "/vagrant", disabled: true
  config.vm.define "test01" do |test01|
    config.vm.box = "centos/7"
    config.vm.box_version = "1902.01"
    config.vm.hostname = "test01.localdomain"
    config.vm.provider :libvirt do |domain|
      domain.uri = 'qemu:///system'
    end
  end
end

Membership of group libvirt maybe required or the right permissions with sudo for example. The first isn’t really advised except on local development system and then even sudo is still advised to reduce any accidental errors.

Categories
System Administration

Using YUM history to see package changes

When you install or update packages on your system, then changes may occur that were not expected. Recent security updates on a server and left Nagios in a failed state, but what exactly happened, and can it be traced back as yum-cron installs all required security updates? Luckily YUM keeps a history database of all actions and with yum history can you list all transactions.

$ sudo yum history list all
Loaded plugins: fastestmirror
ID     | Login user               | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
    15 | root <root>              | 2019-02-02 07:30 | Update         |    2   
    14 | root <root>              | 2019-01-05 07:52 | Update         |   50   
    13 | System ... <sysadmin>    | 2018-11-04 20:45 | I, U           |   62   
    12 | Ansible ... <ansible>    | 2018-11-04 01:36 | Install        |    4   
    11 | root <root>              | 2018-10-20 04:21 | Update         |    2   
    10 | root <root>              | 2018-10-06 07:45 | Update         |    2   
     9 | System ... <sysadmin>    | 2018-09-15 08:06 | I, U           |    9   
     8 | System ... <sysadmin>    | 2018-09-12 03:19 | Install        |    1   
     7 | Ansible ... <ansible>    | 2018-09-09 13:19 | Install        |    1   
     6 | Ansible ... <ansible>    | 2018-09-09 13:14 | Install        |   29   
     5 | Ansible ... <ansible>    | 2018-09-06 14:11 | I, U           |   81   
     4 | Ansible ... <ansible>    | 2018-09-06 13:21 | Install        |    1   
     3 | Ansible ... <ansible>    | 2018-09-06 13:20 | Install        |   51   
     2 | Ansible ... <ansible>    | 2018-09-06 13:14 | Install        |    1   
     1 | System <unset>           | 2018-09-06 03:17 | Install        |  275   
history list

As transaction 15 was the latest and only transaction before the defect occurred it is the one to look into. With yum history info the details of the transaction can be shown. It shows when and who triggered the transaction, but also with which version of RPM, YUM, and which plugins for YUM were used. Most importantly it also shows which package was updated with versions used and from which repository. This narrows the search down to the packages shown as updated and sees what they changed on the system.

$ sudo yum history info 15
Loaded plugins: fastestmirror
Transaction ID : 15
Begin time     : Sat Feb  2 07:30:58 2019
Begin rpmdb    : 450:5f24b4b6a7aaef9f42874d6c8643385133020181
End time       :            07:31:04 2019 (6 seconds)
End rpmdb      : 450:246b0b638aa8b6b851529eb1b040714b7149d0e9
User           : root <root>
Return-Code    : Success
Transaction performed with:
    Installed     rpm-4.11.3-32.el7.x86_64                        @anaconda
    Installed     yum-3.4.3-158.el7.centos.noarch                 @anaconda
    Installed     yum-plugin-fastestmirror-1.1.31-46.el7_5.noarch @updates
Packages Altered:
    Updated nagios-4.3.4-5.el7.x86_64        @epel
    Update         4.4.3-1.el7.x86_64        @epel
    Updated nagios-common-4.3.4-5.el7.x86_64 @epel
    Update                4.4.3-1.el7.x86_64 @epel
history info

Red Hat Linux 8 will be using dnf instead of yum like Fedora 18 and later, but you don’t have to relearning anything as you can use dnf in the same way as yum and with the same parameters for now.

Categories
System Administration

mount: unknown filesystem type ‘exfat’

exFAT has been chosen by the SD Card Association as the standard file system for SDXC cards with 32 GiB or more of storage. Sadly the Fedora Project has chosen not to bundle support for exFAT due to patent issues. A free implementation of exFAT has been made and is available via RPMFusion Free for RPM-based systems.

$ sudo dnf -y install https://download.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm 
$ sudo dnf -y install fuse-exfat

If you now try to mount your SD-card in Nautilus for example it should mount your drive. The performance should also be better than with NTFS as there is less overhead.