MPD, as the name implies, is a Music Playing Daemon. It can play music but, being a daemon, any piece of software can interface with it and play sounds, including some CLI clients.
One of them is called ncmpcpp, which is an improvement over the pre-existing ncmpc tool. The name change doesn’t have much to do with the language they’re written in: they’re both C++, but ncmpcpp is called that because it’s the NCurses Music Playing ClientPlus Plus.
Installing MPD and ncmpcpp
The ncmpmpcc client can be installed from the official Fedora repositories with DNF directly with
The most painless way to set up MPD is to run it as a regular user. The default is to run it as the dedicated mpd user, but that causes all sorts of issues with permissions.
Before we can run it, we need to create a local config file that will allow it to run as a regular user.
To do that, create a subdirectory called mpd in ~/.config:
$ mkdir ~/.config/mpd
copy the default config file into this directory:
$ cp /etc/mpd.conf ~/.config/mpd
and then edit it with a text editor like vim, nano or gedit:
$ nano ~/.config/mpd/mpd.conf
I recommend you read through all of it to check if there’s anything you need to do, but for most setups you can delete everything and just leave the following:
db_file "~/.config/mpd/mpd.db" log_file "syslog"
At this point you should be able to just run
$ mpd
with no errors, which will start the MPD daemon in the background.
Using ncmpcpp
Simply run
$ ncmpcpp
and you’ll see a ncurses-powered graphical user interface in your terminal.
Press 4 and you should see your local music library, be able to change the selection using the arrow keys and press Enter to play a song.
Doing this multiple times will create a playlist, which allows you to move to the next track using the > button (not the right arrow, the > closing angle bracket character) and go back to the previous track with <. The + and – buttons increase and decrease volume. The Q button quits ncmpcpp but it doesn’t stop the music. You can play and pause with P.
You can see the current playlist by pressing the 1 button (this is the default view). From this view you can press i to look at the information (tags) about the current song. You can change the tags of the currently playing (or paused) song by pressing 6.
Pressing the \ button will add (or remove) an informative panel at the top of the view. In the top left, you should see something that looks like this:
[------]
Pressing the r, z, y, R, x buttons will respectively toggle the repeat, random, single, consume and crossfade playback modes and will replace one of the – characters in that little indicator to the initial of the selected mode.
Pressing the F1 button will display some help text, which contains a list of keybindings, so there’s no need to write a complete list here. So now go on, be geeky, and play all your music from your terminal!
The kernel team is working on final integration for kernel 5.5. This version was just recently released, and will arrive soon in Fedora. This version has many security fixes included. As a result, the Fedora kernel and QA teams have organized a test week from Monday, February 10, 2020 through Monday, February 17, 2020. Refer to the wiki page for links to the test images you’ll need to participate. Read below for details.
How does a test week work?
A test day/week is an event where anyone can help make sure changes in Fedora work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed before, this is a perfect way to get started.
To contribute, you only need to be able to do the following things:
Download test materials, which include some large files
Read and follow directions step by step
The wiki page for the kernel test day has a lot of good information on what and how to test. After you’ve done some testing, you can log your results in the test day web application. If you’re available on or around the day of the event, please do some testing and report your results.
Happy testing, and we hope to see you in the Test Week.
Both Apple and Microsoft offer varying levels of integration of their desktop offerings with your mobile devices. Fedora offers a similar if not greater degree of integration with GSConnect. It lets you pair your Android phone with your Fedora desktop and opens up a lot of possibilities. Keep reading to discover more about what it is and how it works.
What is GSConnect?
GSConnect is an implementation of the KDE Connect project tailored for the GNOME desktop. KDE Connect makes it possible for your devices to communicate with each other. However, installing it on Fedora’s default GNOME desktop requires pulling in a large number of KDE dependencies.
GSConnect is a complete implementation of KDE Connect, but in the form of a GNOME shell extension. Once installed, GSConnect lets you do the following and a lot more:
Receive phone notifications on your desktop and reply to messages
Use your phone as a remote control for your desktop
Share files and links between devices
Check your phone’s battery level from the desktop
Ring your phone to help find it
Setting up the GSConnect extension
Setting up GSConnect requires installing two components: the GSConnect extension on your desktop and the KDE Connect app on your Android device.
First, install the GSConnect extension from the GNOME Shell extensions website: GSConnect. (Fedora Magazine has a handy article on How to install a GNOME Shell extension to help you with this step.)
The KDE Connect app is available on Google’s Play Store. It’s also available on the FOSS Android apps repository, F-Droid.
Once you have installed both these components, you can pair your two devices. Installing the extension makes it show up in your system menu as Mobile Devices. Clicking on it displays a drop down menu, from which you can access Mobile Settings.
Here’s where you can view your paired devices and manage the features offered by GSConnect. Once you are on this screen, launch the app on your Android device.
You can initiate pairing from either device, but here you’ll be connecting to your desktop from the Android device. Simply hit refresh on the app, and as long as both devices are on the same wireless network, your desktop shows up in your Android device. You can now send a pair request to the desktop. Accept the pair request on your desktop to complete the pairing.
Using GSConnect
Once paired, you’ll need to grant permissions on your Android device to make use of the many features available on GSConnect. Click on the paired device in the list of devices to see all available functions and enable or disable them according to your preferences.
Remember that you’ll also need to grant corresponding permissions in the Android app to be able to use these functions. Depending upon the features you’ve enabled and the permissions you’ve granted, you can now access your mobile contacts on your desktop, get notified of messages and reply to them, and even sync the desktop and Android device clipboards.
Integration with Files and your web browsers
GSConnect allows you to directly send files to your Android device from your desktop file explorer’s context menu.
On Fedora’s default GNOME desktop, you will need to install the nautilus-python package in order to make your paired devices show up in the context menu. Installing this is as straightforward as running the following command from your preferred terminal:
$ sudo dnf install nautilus-python
Once done, the Send to Mobile Device entry appears in the context menu of the Files app.
Similarly, install the corresponding WebExtension for your browser, be it Firefox or Chrome, to send links to your Android device. You have the option to send the link to launch directly in your browser or to deliver it as SMS.
Running Commands
GSConnect lets you define commands which you can then run on your desktop, from your remote device. This allows you to do things such as take a screenshot of your desktop, or lock and unlock your desktop from your Android device, remotely.
To make use of this feature, you can use standard shell commands and the CLI exposed by GSConnect. Documentation on this is provided in the project’s GitHub repository: CLI Scripting.
The KDE UserBase Wiki has a list of example commands. These examples cover controlling the brightness and volume on your desktop, locking the mouse and keyboard, and even changing the desktop theme. Some of the commands are specific for KDE Plasma, and modifications are necessary to make it run on the GNOME desktop.
Explore and have fun
GSConnect makes it possible to enjoy a great degree of convenience and comfort. Dive into the preferences to see all that you can do and get creative with the commands function. Feel free to share all the possibilities this utility unlocked in your workflow in the comments below.
Being able to collaborate on task remotely is an increasing need in today’s world. Contributing to Open Source project ? Working remotely ? tmate is a tmux fork that makes it easy to share a terminal session with others. It can save you hours of lonely debugging or programming.
tmate, being a tmux fork, supports all of tmux features and configuration. Also tmux and tmate can co-exist on the same system. To learn more about tmux, you can read the following article
tmate is available in the Fedora repository, making it really easy to install.
$ sudo dnf install tmate
$ tmate
Connecting to ssh.tmate.io… Note: clear your terminal before sharing readonly access web session read only: https://tmate.io/t/ro-F2aK7T ssh session read only: ssh ro-F2aK7TJsEj6b4T@l.tmate.io web session: https://tmate.io/t/H5rPw ssh session: ssh H5rPwR@l.tmate.io
After starting tmate, different ways to share your session will be available. You have the choice between ssh (read-only, read-write) or web (read-only, read-write).
The web client is known to have a few issues and is still work in progress, for example the tmux key bindings are not yet supported.
On the host running tmate, you start a new pane by hitting “Ctrl+b, c”. The new pane will then be available with anyone connected to your session.
You can easily keep track of how many clients are connected to your session, using the tmate control pane. To access it hit “Ctrl+b, 0 (zero)” you will then see something like this.
A mate has joined (109.95.145.251) -- 1 client currently connected
A mate has left (109.95.145.251) -- 0 client currently connected
A mate has joined (109.95.145.251) -- 1 client currently connected
To close a session you can simply close tmate“Ctrl+c, Ctrl+d“.
Running your own server
By default tmate is using a remote server hosted on tmate.io. If you prefer you have the possibility to run your own server. For convenience a container image is provided and instruction are available on tmate.io.
It is important to remember that sharing your terminal session in read-write mode will give full access to your system to the connected client. So make sure you trust the persons you sharing you session with or use the read-only mode.
COPR is a collection of personal repositories for software that isn’t carried in Fedora. Some software doesn’t conform to standards that allow easy packaging. Or it may not meet other Fedora standards, despite being free and open source. COPR can offer these projects outside the Fedora set of packages. Software in COPR isn’t supported by Fedora infrastructure or signed by the project. However, it can be a neat way to try new or experimental software.
This article presents a few new and interesting projects in COPR. If you’re new to using COPR, see the COPR User Documentation for how to get started.
Contrast
Contrast is a small app used for checking contrast between two colors and to determine if it meets the requirements specified in WCAG. The colors can be selected either using their RGB hex codes or with a color picker tool. In addition to showing the contrast ratio, Contrast displays a short text on a background in selected colors to demonstrate comparison.
Installation instructions
The repo currently provides contrast for Fedora 31 and Rawhide. To install Contrast, use these commands:
Pamixer is a command-line tool for adjusting and monitoring volume levels of sound devices using PulseAudio. You can display the current volume of a device and either set it directly or increase/decrease it, or (un)mute it. Pamixer can list all sources and sinks.
Installation instructions
The repo currently provides Pamixer for Fedora 31 and Rawhide. To install Pamixer, use these commands:
PhotoFlare is an image editor. It has a simple and well-arranged user interface, where most of the features are available in the toolbars. PhotoFlare provides features such as various color adjustments, image transformations, filters, brushes and automatic cropping, although it doesn’t support working with layers. Also, PhotoFlare can edit pictures in batches, applying the same filters and transformations on all pictures and storing the results in a specified directory.
Installation instructions
The repo currently provides PhotoFlare for Fedora 31. To install Photoflare, use these commands:
Tdiff is a command-line tool for comparing two file trees. In addition to showing that some files or directories exist in one tree only, tdiff shows differences in file sizes, types and contents, owner user and group ids, permissions, modification time and more.
Installation instructions
The repo currently provides tdiff for Fedora 29-31 and Rawhide, EPEL 6-8 and other distributions. To install tdiff, use these commands:
Nextcloud is a software suite for storing and syncing your data across multiple devices. You can learn more about Nextcloud Server’s features from https://github.com/nextcloud/server.
This article demonstrates how to build a personal cloud using Fedora and Nextcloud in a few simple steps. For this tutorial you will need a dedicated computer or a virtual machine running Fedora 31 server edition and an internet connection.
Step 1: Configure the server
Start by updating your system and rebooting:
$ sudo -i
# dnf upgrade
# reboot
Next, disable SELinux by changing enforcing to disabled in /etc/selinux/config and then rebooting to activate the new setting:
# vi /etc/selinux/config
# reboot
If you don’t want to reboot right away, you can use the setenforce command to disable SELinux in the current session.
# setenforce 0
Alternatively, you can follow the directions here to configure SELinux to work with Nextcloud.
Step 2: Install the prerequisites
Before installing and configuring Nextcloud, a few prerequisites must be satisfied.
First, install Apache web server:
# dnf install httpd
Next, install PHP and some additional modules. Make sure that the PHP version being installed meets Nextcloud’s requirements:
Now that MariaDB is running on your server, you can run the mysql_secure_installation command to secure it:
# mysql_secure_installation NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY! In order to log into MariaDB to secure it, we'll need the
current password for the root user. If you've just installed
MariaDB, and you haven't set the root password yet, the password
will be blank, so you should just press enter here. Enter current password for root (enter for none): <ENTER>
OK, successfully used password, moving on... Setting the root password ensures that nobody can log into
the MariaDB root user without the proper authorization. Set root password? [Y/n] <ENTER>
New password: Your_Password_Here
Re-enter new password: Your_Password_Here Password updated successfully! Reloading privilege tables... ... Success! By default, a MariaDB installation has an anonymous user,
allowing anyone to log into MariaDB without having to have
a user account created for them. This is intended only for
testing, and to make the installation go a bit smoother. You
should remove them before moving into a production environment. Remove anonymous users? [Y/n] <ENTER> ... Success! Normally, root should only be allowed to connect from 'localhost'. This ensures that someone cannot guess at the
root password from the network. Disallow root login remotely? [Y/n] <ENTER> ... Success! By default, MariaDB comes with a database named 'test' that
anyone can access. This is also intended only for testing, and
should be removed before moving into a production environment. Remove test database and access to it? [Y/n] <ENTER> - Dropping test database... ... Success! - Removing privileges on test database... ... Success! Reloading the privilege tables will ensure that all changes
made so far will take effect immediately. Reload privilege tables now? [Y/n] <ENTER> ... Success! Cleaning up... All done! If you've completed all of the above steps, your
MariaDB installation should now be secure. Thanks for using MariaDB!
Step 3: Install Nextcloud Server
Now that the prerequisites for your Nextcloud installation have been satisfied, download and unzip the Nextcloud archive:
Next, create a dedicated user and database for your Nextcloud instance:
# mysql -p
> create database nextcloud;
> create user 'nc_admin'@'localhost' identified by 'SeCrEt';
> grant all privileges on nextcloud.* to 'nc_admin'@'localhost';
> flush privileges;
> exit;
Step 4: Configure Nextcloud
Nextcloud can be configured using its web interface or from the command line.
Using the web interface
From your favorite browser, access http://your_server_ip/nextcloud and fill the fields:
Using the command line
From the command line, just enter the following, substituting the values you used when you created a dedicated Nextcloud user in MariaDB earlier:
I used the http protocol, but Nextcloud also works over https. I might write a follow-up about securing Nextcloud in a future article.
I disabled SELinux, but your server will be more secure if you configure it.
The recommend PHP memory limit for Nextcloud is 512M. To change it, edit the memory_limit variable in the /etc/php.ini configuration file and restart your httpd service.
By default, the web interface can only be accessed using the http://localhost/ URL. If you want to allow access using other domain names, you can do so by editing the /var/www/html/nextcloud/config/config.php file. The * character can be used to bypass the domain name restriction and allow the use of any URL that resolves to one of your server’s IP addresses.
Imagine you bought a new laptop with a shiny new USB-C docking station. You install fresh Fedora, encrypt your hard drive because laptop is a travel equipment and you do not want to travel around with non-ecrypted hard drive. You finish the installation, close the lid because you have external monitor, reboot the machine, and finally you would like to enter the LUKS password using the external keyboard attached using USB 2.0 to the USB-C docking station but it does not work!
The keyboard does not respond at all. So you open the lid, try the built-in keyboard which works just fine and once the machine boots the external keyboard works just fine as well. What is the problem?
What is this Thunderbolt anyway and why would anyone want it?
Thunderbolt is a hardware interface to connect peripherals such as monitors, external network cards [1] or even graphic cards [1]. The physical connector is the same as USB-C, but there is usually a label with a little lightning right next to the port to differentiate “plain” USB-C from Thunderbolt ports.
Of course it comes with very high transmission speed to support such demanding peripherals, but it also comes with a certain security risks. To achieve transmission speed like this, Thunderbolt uses Direct Memory Access (DMA) for the peripheral devices. As the name suggests, this method allows the external device to read and write memory directly without talking to the running operating system.
I guess you can already spot the problem here. If some stranger is walking around my laptop (even with the screen locked), is it really possible to just attach a device and read content of my computer memory? Let’s discuss it in more detail.
User facing solution for Thunderbolt security
In the recent versions, Gnome settings include a tab for Thunderbolt device configuration. You can enable and disable DMA access for external devices and you can also verify identity of the devices.
bolt is the component responsible for managing thunderbolt devices. See man 8 boltd for more information.
CLI tools
Of course it is possible to control the same via command line. I suggest you to read man boltctl or check the upstream repository directly: https://gitlab.freedesktop.org/bolt/bolt
Pre-boot support – solution to the keyboard problem
In pre-boot environment, the situation is slightly different. The userspace service responsible for device verification is not yet running so if a device is to be allowed, the firmware must to it. In order to enable this feature go to your BIOS and look for “support in pre boot environment”. For example this is how it looks on a Lenovo laptop:
Once you enable this feature, bolt will add any verified device to a list of allowed devices. The next time you boot your machine, you should be able to use your external keyboard.
Run boltctl a look for “bootacl”. Make sure that the list of allowed devices contains the one you wish to use.
Also note the “security: secure” line. If you see anything else, for instance “security: user” I recommend to reconfigure BIOS.
Technical details of the pre-boot support
There is one unfortunate technical detail about this solution. Thunderbolt support different security levels. For running Fedora, I recommend you to use “secure” level to verify that the device is indeed the one that it claims to be by using a per-device key generated by the host and stored in the device. Firmware, on the other hand, will only use “user” level which uses simple UUID that is provided by the device. The difference is that a malicious device could claim to be a different one by providing the same UUID as a legitimate one. Anyway this should not be a problem as the memory does not contain any sensitive data yet.
As you can see, in recent enough Fedora version the solution is a simple switch in BIOS. So if you are still opening your laptop during boot, go ahead and configure it so you don’t have to do it next time. Meanwhile check that the default security level is “secure” instead of “user” [5].
You don’t need an internet connection to have an easily searchable and extendable dictionary on your Fedora computer. You can use sdcv (StarDict under Console Version) and the public Stardict files on the default repositories to keep a local record for offline use. This article shows you how.
What is sdcv?
sdcv is a command line variant of Stardict. Stardict is a part of a long legacy of GUI offline dictionaries. The “dic” files it uses are formatted as a colon delimited file, with the word in first column and the definition in the second column. You can have multiple lines with the same word and different definitions. sdcv will provide you with a search function and formatted display of your results.
Installing sdcv
You can get started quickly with sdcv and the English dictionary by installing them from the default repos:
sudo dnf install sdcv stardict-dic-en
sdcv will be ready for use right away. If you want to see what other languages are available, use this command:
dnf search stardict
How to use sdcv
sdcv has an interactive and non-interactive mode. You can perform a quick search on a word or term using this command:
sdcv word
For example, you could search sdcv linux. Alternately, you can run sdcv by itself to activate interactive mode.
Customizing sdcv
sdcv has a –color option that adds coloring to the words and source of the definition. You can also use an alias to enable –color by default. Simply edit your shell resource file (default on Fedora is ~/.bashrc) to add this command:
alias sdcv="sdcv --color"
You can also use a more friendly name like this:
alias describe="sdcv --color"
sdcv references /usr/share/stardic/dic by default, or it uses the path located in the shell variable STARDICT_DATA_DIR. You can also set up a personal dictionary in the file $HOME/.stardict/dic.
Fun facts
Believe it or not, the dict network protocol is still alive to this day. You can use it with the curl command by using a command like this to search for a word:
curl dict://dict.org/d:<word>
This pull definitions straight from the internet via your command line. Enjoy using sdcv!
Operating system distributions try to craft a one size fits all partition layout for their file systems. Distributions cannot know the details about how your hardware is configured or how you use your system though. Do you have more than one storage drive? If so, you might be able to get a performance benefit by putting the write-heavy partitions (var and swap for example) on a separate drive from the others that tend to be more read-intensive since most drives cannot read and write at the same time. Or maybe you are running a database and have a small solid-state drive that would improve the database’s performance if its files are stored on the SSD.
The following sections attempt to describe in brief some of the historical reasons for separating some parts of the file system out into separate partitions so that you can make a more informed decision when you install your Linux operating system.
If you know more (or contradictory) historical details about the partitioning decisions that shaped the Linux operating systems used today, contribute what you know below in the comments section!
Common partitions and why or why not to create them
The boot partition
One of the reasons for putting the /boot directory on a separate partition was to ensure that the boot loader and kernel were located within the first 1024 cylinders of the disk. Most modern computers do not have the 1024 cylinder restriction. So for most people, this concern is no longer relevant. However, modern UEFI-based computers have a different restriction that makes it necessary to have a separate partition for the boot loader. UEFI-based computers require that the boot loader (which can be the Linux kernel directly) be on a FAT-formatted file system. The Linux operating system, however, requires a POSIX-compliant file system that can designate access permissions to individual files. Since FAT file systems do not support access permissions, the boot loader must be on a separate file system than the rest of the operating system on modern UEFI-based computers. A single partition cannot be formatted with more than one type of file system.
The var partition
One of the historical reasons for putting the /var directory on a separate partition was to prevent files that were frequently written to (/var/log/* for example) from filling up the entire drive. Since modern drives tend to be much larger and since other means like log rotation and disk quotas are available to manage storage utilization, putting /var on a separate partition may not be necessary. It is much easier to change a disk quota than it is to re-partition a drive.
Another reason for isolating /var was that file system corruption was much more common in the original version of the Linux Extended File System (EXT). The file systems that had more write activity were much more likely to be irreversibly corrupted by a power outage than those that did not. By partitioning the disk into separate file systems, one could limit the scope of the damage in the event of file system corruption. This concern is no longer as significant because modern file systems support journaling.
The home partition
Having /home on a separate partition makes it possible to re-format the other partitions without overwriting your home directories. However, because modern Linux distributions are much better at doing in-place operating system upgrades, re-formatting shouldn’t be needed as frequently as it might have been in the past.
It can still be useful to have /home on a separate partition if you have a dual-boot setup and want both operating systems to share the same home directories. Or if your operating system is installed on a file system that supports snapshots and rollbacks and you want to be able to rollback your operating system to an older snapshot without reverting the content in your user profiles. Even then, some file systems allow their descendant file systems to be rolled back independently, so it still may not be necessary to have a separate partition for /home. On ZFS, for example, one pool/partition can have multiple descendant file systems.
The swap partition
The swap partition reserves space for the contents of RAM to be written to permanent storage. There are pros and cons to having a swap partition. A pro of having swap memory is that it theoretically gives you time to gracefully shutdown unneeded applications before the OOM killer takes matters into its own hands. This might be important if the system is running mission-critical software that you don’t want abruptly terminated. A con might be that your system runs so slow when it starts swapping memory to disk that you’d rather the OOM killer take care of the problem for you.
Another use for swap memory is hibernation mode. This might be where the rule that the swap partition should be twice the size of your computer’s RAM originated. Ideally, you should be able to put a system into hibernation even if nearly all of its RAM is in use. Beware that Linux’s support for hibernation is not perfect. It is not uncommon that after a Linux system is resumed from hibernation some hardware devices are left in an inoperable state (for example, no video from the video card or no internet from the WiFi card).
In any case, having a swap partition is more a matter of taste. It is not required.
The root partition
The root partition (/) is the catch-all for all directories that have not been assigned to a separate partition. There is always at least one root partition. BIOS-based systems that are new enough to not have the 1024 cylinder limit can be configured with only a root partition and no others so that there is never a need to resize a partition or file system if space requirements change.
The EFI system partition
The EFI System Partition (ESP) serves the same purpose on UEFI-based computers as the boot partition did on the older BIOS-based computers. It contains the boot loader and kernel. Because the files on the ESP need to be accessible by the computer’s firmware, the ESP has a few restrictions that the older boot partition did not have. The restrictions are:
The ESP must be formatted with a FAT file system (vfat in Anaconda)
The ESP must have a special type-code (EF00 when using gdisk)
Because the older boot partition did not have file system or type-code restrictions, it is permissible to apply the above properties to the boot partition and use it as your ESP. Note, however, that the GRUB boot loader does not support combining the boot and ESP partitions. If you use GRUB, you will have to create a separate partition and mount it beneath the /boot directory.
The Boot Loader Specification (BLS) lists several reasons why it is ideal to use the legacy boot partition as your ESP. The reasons include:
The UEFI firmware should be able to load the kernel directly. Having a separate, non-ESP compliant boot partition for the kernel prevents the UEFI firmware from being able to directly load the kernel.
Nesting the ESP mount point three mount levels deep increases the likelihood that an intermediate mount could fail or otherwise be unavailable when needed. That is, requiring root (/), then boot (/boot), then efi (/efi) to be consecutively mounted is unnecessarily complex and prone to error.
Requiring the boot loader to be able to read other partitions/disks which may be formatted with arbitrary file systems is non-trivial. Even when the boot loader does contain such code, the code that works at installation time can become outdated and fail to access the kernel/initrd after a file system update. This is currently true of GRUB’s ZFS file system driver, for example. You must be careful not to update your ZFS file system if you use the GRUB boot loader or else your system may not come back up the next time you reboot.
Besides the concerns listed above, it is a good idea to have your startup environment — up to and including your initramfs — on a single self-contained file system for recovery purposes. Suppose, for example, that you need to rollback your root file system because it has become corrupted or it has become infected with malware. If your kernel and initramfs are on the root file system, you may be unable to perform the recovery. By having the boot loader, kernel, and initramfs all on a single file system that is rarely accessed or updated, you can increase your chances of being able to recover the rest of your system.
In summary, there are many ways that you can layout your partitions and the type of hardware (BIOS or UEFI) and the brand of boot loader (GRUB, Syslinux or systemd-boot) are among the factors that will influence which layouts will work.
Other considerations
MBR vs. GPT
GUID Partition Table (GPT) is the newer partition format that supports larger disks. GPT was designed to work with the newer UEFI firmware. It is backward-compatible with the older Master Boot Record (MBR) partition format but not all boot loaders support the MBR boot method. GRUB and Syslinux support both MBR and UEFI, but systemd-boot only supports the newer UEFI boot method.
By using GPT now, you can increase the likelihood that your storage device, or an image of it, can be transferred over to a newer computer in the future should you wish to do so. If you have an older computer that natively supports only MBR-partitioned drives, you may need to add the inst.gpt parameter to Anaconda when starting the installer to get it to use the newer format. How to add the inst.gpt parameter is shown in the below video titled “Partitioning a BIOS Computer”.
If you use the GPT partition format on a BIOS-based computer, and you use the GRUB boot loader, you must additionally create a one megabyte biosboot partition at the start of your storage device. The biosboot partition is not needed by any other brand of boot loader. How to create the biosboot partition is demonstrated in the below video titled “Partitioning a BIOS Computer”.
LVM
One last thing to consider when manually partitioning your Linux system is whether to use standard partitions or logical volumes. Logical volumes are managed by the Logical Volume Manager (LVM). You can setup LVM volumes directly on your disk without first creating standard partitions to hold them. However, most computers still require that the boot partition be a standard partition and not an LVM volume. Consequently, having LVM volumes only increases the complexity of the system because the LVM volumes must be created within standard partitions.
The main features of LVM — online storage resizing and clustering — are not really applicable to the typical end user. Most laptops do not have hot-swappable drive bays for adding or reconfiguring storage while the system is running. And not many laptop or desktop users have clvmd configured so they can access a centralized storage device concurrently from multiple client computers.
LVM is great for servers and clusters. But it adds extra complexity for the typical end user. Go with standard partitions unless you are a server admin who needs the more advanced features.
Video demonstrations
Now that you know which partitions you need, you can watch the sort video demonstrations below to see how to manually partition a Fedora Linux computer from the Anaconda installer.
These videos demonstrate creating only the minimally required partitions. You can add more if you choose.
Because the GRUB boot loader requires a more complex partition layout on UEFI systems, the below video titled “Partitioning a UEFI Computer” additionally demonstrates how to install the systemd-boot boot loader. By using the systemd-boot boot loader, you can reduce the number of needed partitions to just two — boot and root. How to use a boot loader other than the default (GRUB) with Fedora’s Anaconda installer is officially documented here.
The Fedora CoreOS team is pleased to announce that Fedora CoreOS is now available for general use. Here are some more details about this exciting delivery.
Fedora CoreOS is a new Fedora Edition built specifically for running containerized workloads securely and at scale. It’s the successor to both Fedora Atomic Host and CoreOS Container Linux and is part of our effort to explore new ways of assembling and updating an OS. Fedora CoreOS combines the provisioning tools and automatic update model of Container Linux with the packaging technology, OCI support, and SELinux security of Atomic Host. For more on the Fedora CoreOS philosophy, goals, and design, see the announcement of the preview release.
Some highlights of the current Fedora CoreOS release:
To try out the new release, head over to the download page to get OS images or cloud image IDs. Then use the quick start guide to get a machine running quickly.
In general, the Fedora Project does not make any guarantees around stability. While Fedora CoreOS strives for a high level of stability, this can be challenging to achieve in the rapidly evolving Linux and container ecosystems. We’ve found that the incremental, exploratory, forward-looking development required for Fedora CoreOS — which is also a cornerstone of the Fedora Project as a whole — is difficult to reconcile with the iron-clad stability guarantee that ideally exists when automatically updating systems.
We’ll continue to do our best not to break existing systems over time, and to give users the tools to manage the impact of any regressions. Nevertheless, automatic updates may produce regressions or breaking changes for some use cases. You should make your own decisions about where and how to run Fedora CoreOS based on your risk tolerance, operational needs, and experience with the OS. We will continue to announce any major planned or unplanned breakage to the coreos-status mailing list, along with recommended mitigations.
How do I migrate from CoreOS Container Linux?
Container Linux machines cannot be migrated in place to Fedora CoreOS. We recommend writing a new Fedora CoreOS Config to provision Fedora CoreOS machines. Fedora CoreOS Configs are similar to Container Linux Configs, and must be passed through the Fedora CoreOS Config Transpiler to produce an Ignition config for provisioning a Fedora CoreOS machine.
Whether you’re currently provisioning your Container Linux machines using a Container Linux Config, handwritten Ignition config, or cloud-config, you’ll need to adjust your configs for differences between Container Linux and Fedora CoreOS. For example, on Fedora CoreOS network configuration is performed with NetworkManager key files instead of systemd-networkd, and time synchronization is performed by chrony rather than systemd-timesyncd. Initial migration documentation will be available soon and a skeleton list of differences between the two OSes is available in this issue.
CoreOS Container Linux will be maintained for a few more months, and then will be declared end-of-life. We’ll announce the exact end-of-life date later this month.
How do I migrate from Fedora Atomic Host?
Fedora Atomic Host has already reached end-of-life, and you should migrate to Fedora CoreOS as soon as possible. We do not recommend in-place migration of Atomic Host machines to Fedora CoreOS. Instead, we recommend writing a Fedora CoreOS Config and using it to provision new Fedora CoreOS machines. As with CoreOS Container Linux, you’ll need to adjust your existing cloud-configs for differences between Fedora Atomic Host and Fedora CoreOS.
Welcome to Fedora CoreOS. Deploy it, launch your apps, and let us know what you think!
