The pause() system call is used to make the calling process or thread sleep until one of the following events occurs:

• The calling process receives the signal whose default behaviour is to kill the process. (OR)
• The execution of the signal handler is completed

In both the cases, the pause() system call returns -1.

Behaviour when the process catches a signal

Let’s examine the following program.

file: pause.c

#include <stdio.h>
#include <unistd.h>

int main(void)
{
        int ret = 0;
        ret = pause();
        printf("Pause returned with %d\n", ret);
        return 0;
}

Compile the program using:

gcc pause.c -o pause

Run the program with ./pause. The program sleeps at the line ret = pause();. From another terminal, send signals to this process using the kill command.

Examples:

kill -SIGKILL `pidof pause`	# Kills the process
OR
kill -SIGCHLD `pidof pause`	# Won't have any effect

The signals SIGCHLD, SIGCONT, SIGSTOP won’t terminate the process, as their default behavior is not set to do so. Additionally, the program does not register signal handlers for these signals, so the pause() system call won’t return upon catching these signals.

However, the pause() function returns when it receives signals with default behaviors set to terminate the process, such as SIGKILL, SIGTERM, etc. For more information on signals and their default behaviors, please run the man 7 signal command.

Behavior when the process finishes executing the signal handler

Let’s examine the following program.

file: pause_sigaction.c

#include <stdio.h>
#include <signal.h>
#include <unistd.h>

void signal_handler(int signal)
{
        printf("Signal %d caught\n", signal);
}

int main(void)
{
        struct sigaction act;
        int ret = 0;

        act.sa_handler =  signal_handler;
        sigaction(SIGCONT, &act, NULL);
        ret = pause();
        if (-1 == ret)
                printf("Process exited\n");
        return 0;
}

A signal handler has been registered for the signal SIGCONT. When we pass this signal to the process, the signal_handler function is called. In this case, the pause() returns when the signal_handler completes execution. This holds true for all signals, whether the default behavior of the signal is to terminate the process or not.

Let’s compile the program with:

gcc pause_sigaction.c -o pause_sigaction

Execute the program with ./pause_sigaction in one terminal and in other terminal run the following command to send SIGCONT signal to the process.

kill -SIGCONT `pidof pause_sigaction`

The pause() returns, and the signal number is printed in the signal_handler(), after which the process exits.

Replace SIGCONT with SIGALRM, whose default behaviour is to terminate the process, in the above program. Re-compile and run the program. Pass the SIGALRM signal to the process using the kill command. The same behaviour can be observed.

Different examples of poorly written shell code are presented in the following sections. The utilization of ShellCheck to identify errors, offer suggestions, and issue warnings in these examples is detailed.

The currently supported shells include: bash, dash and ksh.

Installation

To install ShellCheck on Ubuntu/Debian-based Linux systems, use the following command:

sudo apt install shellcheck

Usage of Shellcheck with bad code examples

Create a demo directory to practice the ShellCheck tool with the following commands:

mkdir -p ~/shellcheck_demo
cd ~/shellcheck_demo

Checking quotes

Here is a shell script named quotes.sh that contains various poorly written examples:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#!/bin/bash

# Example 1
print_seed() {
    cat $1
}

echo "animal mammal dinner hot now yesterday" > "Seed Phrase"

print_seed "Seed Phrase"

# Example 2
touch file1.txt file2.txt
find ./ -name *.txt

# Example 3
touch "~/myfile.txt"

# Example 4
echo 'The PATH is $PATH'

Attempt to execute this script and observe if the output aligns with your expectations.

chmod +x ./quotes.sh
./quotes.sh

Checking the script with shellcheck

Now, let’s identify the issues in the above script using the shellcheck command.

shellcheck quotes.sh

Here is the report:

In quotes.sh line 5:
    cat $1
        ^-- SC2086 (info): Double quote to prevent globbing and word splitting.

Did you mean:
    cat "$1"


In quotes.sh line 14:
find ./ -name *.txt
              ^---^ SC2061 (warning): Quote the parameter to -name so the shell won't interpret it.
              ^-- SC2035 (info): Use ./*glob* or -- *glob* so names with dashes won't become options.


In quotes.sh line 17:
touch "~/myfile.txt"
       ^----------^ SC2088 (warning): Tilde does not expand in quotes. Use $HOME.


In quotes.sh line 20:
echo 'The PATH is $PATH'
     ^-----------------^ SC2016 (info): Expressions don't expand in single quotes, use double quotes for that.

For more information:
  https://www.shellcheck.net/wiki/SC2061 -- Quote the parameter to -name so t...
  https://www.shellcheck.net/wiki/SC2088 -- Tilde does not expand in quotes. ...
  https://www.shellcheck.net/wiki/SC2016 -- Expressions don't expand in singl...

Analyzing above report

The output provides a clear explanation of the identified issues. Nevertheless, let’s delve into the details for a better understanding:

In the example 1 - line 5: $1 should be in quotes.
In the example 2 - line 14: Wrap *.txt in the quotes.
In the example 3 - line 17: Tilde won’t exapand inside the double quotes. We can use $HOME
In the example 4 - line 20: $PATH won’t expand in single quotes. Use double quoes.

Here is the updated quotes.sh script after addressing the errors/warnings pointed out by the shell script tool:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#!/bin/bash

# Example 1
print_seed() {
    cat "$1"
}

echo "animal mammal dinner hot now yesterday" > "Seed Phrase"

print_seed "Seed Phrase"

# Example 2
touch file1.txt file2.txt
find ./ -name "*.txt"

# Example 3
touch "$HOME/myfile.txt"

# Example 4
echo "The PATH is $PATH"

Checking conditionals

Here is the conditionals.sh script with examples illustrating various conditional-related issues.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
#!/bin/bash

# Example 1
n=2
if [[ n != 2 ]]; then
    echo "n is not 2";
else
    echo "n is 2";
fi

## `[[ n != 2 ]]` returns true always. And echo statement will not print.

# Example 2
touch file1.txt

if [[ -e *.txt ]]; then
    echo "file1.txt present"
else
    echo "file1.txt not present"
fi

# Example 3
n=3
if [[ ${n}==2 ]]; then
    echo "n is 2";
else
    echo "n is not 2";
fi

# Example 4

n=""
if [[ -n "$n " ]];then
    echo "n is not empty"
else
    echo "n is empty"
fi

Running shellcheck on the script

Run the script and verify if the output aligns with expectations

shellcheck conditionals.sh

Here is the analysis:

In example 1 - line 5: It should be $n instead of n.
In example 2 - line 16: -e can’t be used with *.txt. Either use file path or use for loop to check all the *.txt files.
In example 3 - line 24: There should be spaces around the comparison operator.
In example 4 - line 33: The if condition is always true regardless of n value because there is a space inside the quotes. Remove it.

Shellcheck can identify various types of conditional issues, including the following.

• Comparing numerical values with strings
• Using logical operators inside brackets.
• Accidental backgrounds and piping [[ condition1 ]] & [[ condition 2 ]] | [[ condition 3 ]]

Checking syntax errors

Here are a few examples of syntax issues in shell scripts. Refer to the comments for the corresponding fixes.

n = 42                          # Spaces shouldn't be there around = operator while assignments
$n=42                           # $ should not be used when assigning a value to a variable

# Shouldn't use $ with loop variable (i). Following is wrong
for $i in {1..10};do
    # Do something here
done

n=1
num$n="36"                      # Use arrays instead

arr=(1, 2, 3)                   # Commas can't be used when defining arrays
echo $arr[14]                   # Missing {} in array references

else if condition; then ..      # Using 'else if' instead of 'elif'

func; func() { echo "hello world; }     # Using function before definition

Checking protability between shells

Here are a few examples that may run without issues in one shell variant but pose problems in others. Shellcheck does a good job of detecting these issues.

echo {1..10}                    # Works in bash and ksh. Doesn't work in sh or dash
local var=2                     # local keyword is undefined in sh

Miscellaneous checking

Following are few more bad examples:

echo 'Don't do it'              # Three apostrophes. Unclosed single quote.
cat file1.txt | grep word       # cat is unnecessary. Use - grep word file1.txt
echo "Today date is `date`"     # Use $ instead of backticks for date command
echo $(( $a + 2 ))              # Don't use $ on variables inside the $((..)).
                                # Might not work in all shells.
rm -rf "$PROJECTROOT/"*         # Warns user the possibility of removing root directory if PROJECTROOT is empty

Getting additional help on shellcheck

The shellcheck help command

The shellcheck --help command gives the brief info and options supported for the shellcheck tool.

shellcheck --help

Usage: shellcheck [OPTIONS...] FILES...
  -a                  --check-sourced            Include warnings from sourced files
  -C[WHEN]            --color[=WHEN]             Use color (auto, always, never)
  -i CODE1,CODE2..    --include=CODE1,CODE2..    Consider only given types of warnings
  -e CODE1,CODE2..    --exclude=CODE1,CODE2..    Exclude types of warnings
  -f FORMAT           --format=FORMAT            Output format (checkstyle, diff, gcc, json, json1, quiet, tty)
                      --list-optional            List checks disabled by default
                      --norc                     Don't look for .shellcheckrc files
  -o check1,check2..  --enable=check1,check2..   List of optional checks to enable (or 'all')
  -P SOURCEPATHS      --source-path=SOURCEPATHS  Specify path when looking for sourced files ("SCRIPTDIR" for script's dir)
  -s SHELLNAME        --shell=SHELLNAME          Specify dialect (sh, bash, dash, ksh)
  -S SEVERITY         --severity=SEVERITY        Minimum severity of errors to consider (error, warning, info, style)
  -V                  --version                  Print version information
  -W NUM              --wiki-link-count=NUM      The number of wiki links to show, when applicable
  -x                  --external-sources         Allow 'source' outside of FILES
                      --help                     Show this usage summary and exit

We can make shellcheck ignore certain error codes using the option –exclude=CODE1,CODE2… Useful while deploying the shellcheck in some build system.

Report from the shellcheck output

If you review the Shellcheck output for the quotes.sh script, each error, warning, or suggestion is accompanied by a URL at the end of the report for additional reference. It looks something like the following:

For more information:
  https://www.shellcheck.net/wiki/SC2061 -- Quote the parameter to -name so t...
  https://www.shellcheck.net/wiki/SC2088 -- Tilde does not expand in quotes. ...
  https://www.shellcheck.net/wiki/SC2016 -- Expressions don't expand in singl...

Feel free to open those URLs in the browser and read the detailed info about the issue there.

Page consisting of all error codes

You can find the all shellcheck error codes here. If this link is broken, you can find the modified web page link here

Let’s generate two partitions: the first utilizing the fat32 filesystem and the second utilizing the ext4 filesystem. This partition combination is commonly employed for constructing a fully bootable operating system. The fat32 partition is designated for storing bootloader-related files, while the ext4 filesystem is employed for housing Linux files.

Insert the USB drive / SD card reader

When you insert a USB drive or SD card reader into the system’s USB port, it’s usually identified as sdX (e.g., sda, sdb), while an SD card appears as mmcblkX (e.g., mmcblk0). To identify the USB device from the kernel log, run:

journalctl  -ke

Correspondingly, partitions are created in the format sdXY (e.g., sdb1, sdc1) or mmcblkXpY (e.g., mmcblk0p1) respectively.

Check connected storage devices using the lsblk command. A typical output might look like this:

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sdc           8:32   1  14.8G  0 disk
`-sdc1        8:33   1  14.8G  0 part
nvme0n1     259:0    0 476.9G  0 disk
|-nvme0n1p1 259:1    0   512M  0 part /boot/efi
|-nvme0n1p2 259:2    0 475.5G  0 part /
`-nvme0n1p3 259:3    0   976M  0 part [SWAP]

Here is another one:

sda           8:0    0 223.6G  0 disk
├─sda1        8:1    0   512M  0 part /boot/efi
├─sda2        8:2    0  93.1G  0 part /
├─sda3        8:3    0   7.5G  0 part [SWAP]
└─sda4        8:4    0 122.5G  0 part
sr0          11:0    1  1024M  0 rom
mmcblk0     179:0    0    29G  0 disk
└─mmcblk0p1 179:1    0    29G  0 part /media/nayab/8D39-59F7

Storage device names in Linux

Typical naming of storage devices are as follows:

Unmount the partitions

Before using the fdisk tool, ensure that the storage device partitions are unmounted.

sudo umount /dev/<device_partition>

or

sudo umount /dev/mmcblk0p1

Partitioning with fdisk

Now run the fdisk command with the device name.

sudo fdisk /dev/<dev_name>

Replace <dev_name> with USB device name (ex: /dev/sdb or /dev/mmcblk0).

Delete partitions

Press p to display the available partitions. Type d multiple times until all partitions are deleted, then type p again to confirm the changes.

Welcome to fdisk (util-linux 2.39.3).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/mmcblk0: 29.81 GiB, 32010928128 bytes, 62521344 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device         Boot Start     End Sectors  Size Id Type
/dev/mmcblk0p1 *     2048   34815   32768   16M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      34816 1083391 1048576  512M 83 Linux

Command (m for help): d
Partition number (1,2, default 2):

Partition 2 has been deleted.

Command (m for help): d
Selected partition 1
Partition 1 has been deleted.

Command (m for help): d
No partition is defined yet!

Command (m for help): p

Disk /dev/mmcblk0: 29.81 GiB, 32010928128 bytes, 62521344 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Command (m for help):

Create FAT32 partition

Now, let’s create a primary partition of 1GB to store bootloader files. Press n followed by p for primary partition. Press Enter for the default Fist sector followed by +1G when asked for Last sector.

Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1):
First sector (2048-62521343, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-62521343, default 62521343): +1G

Created a new partition 1 of type 'Linux' and of size 1 GiB

Change the partition type to FAT32 by typing t and then selecting b.

Command (m for help): t
Selected partition 1
Hex code or alias (type L to list all): b
Changed type of partition 'Linux' to 'W95 FAT32'.

Create Linux partition

Create another partition with the remaining size. Type n and keep pressing Enter until the prompt repeats. Then type t, followed by 2 for the partition number, and set the Hex code to 83 when prompted to specify the Linux type.

Command (m for help): n
Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p):

Using default response p.
Partition number (2-4, default 2):
First sector (2099200-62521343, default 2099200):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2099200-62521343, default 62521343):

Created a new partition 2 of type 'Linux' and of size 28.8 GiB.

Command (m for help):


Command (m for help):


Command (m for help): t
Partition number (1,2, default 2): 2
Hex code or alias (type L to list all): 83


Changed type of partition 'Linux' to 'Linux'.

Write changes to device

Type w to save the partition changes to the disk.

Command (m for help): w

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

Verify the newly written partition information with the following command:

sudo fdisk /dev/<dev_name>

Here is an example:

$ sudo fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 29.81 GiB, 32010928128 bytes, 62521344 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device         Boot   Start      End  Sectors  Size Id Type
/dev/mmcblk0p1         2048  2099199  2097152    1G  b W95 FAT32
/dev/mmcblk0p2      2099200 62521343 60422144 28.8G 83 Linux

Build file system with mkfs tool

Build fat32 filesystem for partition 1:

sudo mkfs.vfat /dev/mmcblk0p1 -n boot

Build Linux filesystem for partition 2:

sudo mkfs.ext4 /dev/mmcblk0p2 -L rootfs

Check the partitions

Remove the USB/Card device and then reinsert it to verify the partitions using the lsblk command.

You can install b4 tool in the Debian based Linux systems with the following command:

sudo apt install b4

Below are the commands illustrating the development workflow for developers.

b4 prep

Creating separate work branch

b4 assumes that you create a new branch before starting to work on a patch (series). To create a branch for your work:

b4 prep -n <patch_series_name>

You can also create a branch from a specific commit ID.

b4 prep -n <patch_series_name> -f <commit_id>

These commands create a new branch and checkout to newly created branch automatically. Now, as usual, you modify and create commits using standard Git commands like git add, git commit, git commit --amend, etc.

Preparing the cover letter

The following command can be used to prepare the cover letter. For single commit submissions, you can simply delete the first line that starts with EDITME.

b4 prep --edit-cover

This command can also be utilized to edit the list of recipients for the patch series. See the next section for details.

Retrieve recipients’ email addresses

Linux kernel developers used to execute the script get_maintainer.pl against the patch to retrieve the recipients’ email addresses to which the patch needs to be sent. Then, they would manually use these email addresses as arguments to the git send-email command to send the patches to the list. The following command simplifies the process of gathering the relevant addresses from the commits themselves.

b4 prep --auto-to-cc

If your project lacks a MAINTAINERS file or any b4 configuration at its core, you may not find a list of recipient emails from the above command. In that case, refer to the last section.

Set the email subject prefixes

You may want to add a prefix such as RFC or RESEND to the email subject. Use the following command to set the prefix. By default, b4 prep adds the prefixes PATCH and a version number such as v2 or v3. These default prefixes cannot be removed.”

b4 prep --set-prefixes "RFC RESEND"

You can reset the prefixes with:

b4 prep --set-prefixes ""

b4 send

Verify the patch before sending

Here are a few commands you can try to verify before sending the patch to the list.

# Writes raw messages to /tmp/presend directory.
b4 send -o /tmp/presend

# Send the patch only to yourself. The the e-mail looks like as if you sent to the actual list of recipients.
b4 send --reflect

Sending the patch

Execute the following command to send the patch to the list.

b4 send

Addressing review comments and sending the next patch version

Once b4 has sent patch v1 to the list, it increments the current version number by 1, and you can continue working on the patch based on the received review comments. As usual, modify the files, use commands like git add, git commit –amend, etc. Now, run b4 prep --edit-cover again to write the changes in the current version. b4 maintains a template for changes in the current version and also remembers the version changes history, so you don’t have to copy-paste every time you send a new iteration of the patch. Verify the patch, once ready resend it using b4 send.

If, for some reason, you want to resend the same patch, you can do so without incrementing the version number by using the following command with b4.

b4 send --resend v2 # v<version_number>

b4 trailers

If someone has provided a Reviewed-by or Acked-by or any other tag, you can gather all those trailers into your commit using the following command:

b4 trailers -u

This command is applicable only when the project utilizes an archived mailing list service such as https://lore.kernel.org/. It retrieves trailers from the archive.

Some popular projects leveraging this service include Linux, Buildroot, and certain Yocto meta layers.

Cleaning up

After your patch is merged into the upstream, you can delete the development branch with:

b4 prep --cleanup <branch_name>

A simple b4 config file

Here is a sample .b4-config file that can be placed in the root directory of your project. This example utilizes the Gmail SMTP server to send patches using b4.

[b4]
  prep-cover-strategy = branch-description
  send-no-patatt-sign = yes
# If your project doesn't have MAINTAINERS file, use send-series-to or
# send-series-cc to add recipients email or list address
  send-series-to = <e-mail_id>
  send-series-cc = <e-mail_id>

[sendemail]
  smtpServer = smtp.gmail.com
  smtpServerPort = 587
  smtpEncryption = tls
  smtpUser = <gmail_id>
  smtpPass = appPassword

References

• Linux Kernel b4 docs
• Do more with lore and b4 - Video

According to Buildroot’s documentation, there are few ways to expedite the build process for the Buildroot system. The analysis that follows was conducted by building a target image for the Raspberry Pi 4 using it’s default configuration on a 16 thread AMD machine.

The typical steps for building an embedded Linux image for the Raspberry Pi 4 using Buildroot are as follows:

git clone https://gitlab.com/buildroot.org/buildroot.git
cd buildroot/
make raspberrypi4_64_defconfig
make -j`nproc`

The build process took approximately 37m12s to complete.

Speeding up the initial build

Using top level parallel build

By default, using make -jN isn’t effective in Buildroot. However, there’s an experimental feature that can be enabled to make it effective. To do this, run make menuconfig, search for the string BR2_PER_PACKAGE_DIRECTORIES, enable it, and save the configuration.

Now, run make clean && make -j`nproc` to perform a top-level parallel build.

The build process took approximately 26m7s to complete. For this testing purpose, intentionally I deleted download directory so that all the sources will be downloaded again.

Using the external SDK

You have the option to instruct Buildroot to use an external toolchain. If you don’t have one available, Buildroot can even create one for you.

Buildroot SDK creation steps

• First, Be sure to make a record of the toolchain settings from make menuconfig -> Toolchain. You can also take a screenshot for future reference.
• In the System configuration -> Init system section, choose None.
• In the System configuration -> /bin/sh section, choose none.
• Disable Target packages -> Busybox section.
• Disable File system images -> tar the root filesystem
• Run make sdk

The SDK/toolchain will be generated in the output/images directory. In my case, it’s located at output/images/aarch64-buildroot-linux-gnu_sdk-buildroot.tar.gz. Make sure to copy this file to another location.

Using the external toolchain

Go to make menuconfig -> Toolchain,

• Set Toolchain type to External toolchain
• Set Toolchain to Custom toolchain
• Set Toolchain origin to Toolchain to be downloaded and installed
• Set Toolchain URL to the SDK downloaded path. In my case it is: file:///home/nayab/aarch64-buildroot-linux-gnu_sdk-buildroot.tar.gz
• Set External toolchain gcc version -> Taken from above step. (ex: 11.x)
• Set External toolchain kernel headers series -> Taken from above step. (ex: 5.10.x)
• Set External toolchain C library -> Taken from above step (ex: glibc)
• Set Toolchain has C++ support? -> Taken from above step. (ex: Enabled in my case)
• Set Toolchain has RPC support? -> Disabled.

After pointing Buildroot to the external toolchain, run the command make clean && make -j`nproc` .The build process took approximately 14m47s to complete. For this testing purpose, intentionally I deleted download directory before running make command.

Speeding up incremental/parallel builds

Using the compiler cache (ccache)

To enable ccache, navigate to make menuconfig -> Build options -> Enable compiler cache. With ccache enabled, the build process stores object files created from source files in the default cache directory $HOME/.buildroot-ccache. Any subsequent or incremental builds with ccache enabled will reduce build time nicely.

In my case, when I initiated an incremental build using the commands make clean and make -j`nproc`, the entire build process only took 5 minutes and 24 seconds. That’s incredibly fast. Now also, the dl directory was deleted manually before building.

Note that, make clean won’t delete compiler ccache directory. This need to be deleted manually if you want to get rid of it.

The compiler cache can be shared among multiple parallel builds, resulting in a significant reduction in build times, no matter how many builds are concurrently taking place.

Re-using the download directory

This is especially useful when you need to build for multiple targets simultaneously. In Buildroot, there’s a configuration option, BR2_DL_DIR, where you can set the value to use a shared downloads path for all target builds. I configured this to use the downloads directory where all the files were already downloaded.

The build process took approximately 3m4s to complete.

Sharing the Buildroot source tree

Buildroot Building out of tree feature lets you construct images for multiple targets using the same Buildroot source tree. This way source cloning (ex: git clone) time will be saved.

For instance, assuming the current working directory is the Buildroot source tree:

In one Terminal tab, run:

mkdir rpi; make O=rpi raspberrypi4_64_defconfig

In another Terminal tab, run:

mkdir mchp; make O=mchp microchip_sam9x60ek_mmc_defconfig

Now there are two output directories, named rpi and mchp, for each target, all utilizing the same Buildroot source tree.

Comparison table

Miscellaneous

• Investing in better hardware can significantly reduce build times. Consider getting a faster SSD and increasing RAM.
• Building within a virtual machine can lead to notably poor performance.

References

• https://buildroot.org/downloads/manual/manual#faq-speeding-up-build
• https://buildroot.org/downloads/manual/manual.html#top-level-parallel-build
• https://buildroot.org/downloads/manual/manual.html#build-toolchain-with-buildroot
• https://buildroot.org/downloads/manual/manual.html#ccache
• https://buildroot.org/downloads/manual/manual.html#download-location
• https://buildroot.org/downloads/manual/manual.html#_building_out_of_tree

The initial Flatpak setup process varies for each family of Linux distributions. However, once set up, the procedure for downloading, installing, and using Flatpak apps is consistent across all distributions.

This post illustrates the process for Debian/Ubuntu-based Linux distributions. For other distributions, please refer to https://flathub.org/setup.

Installing flatpak

Installing Flatpak on Debian/Ubuntu is straightforward. Simply use the ‘apt’ command to install Flatpak.

sudo apt update && sudo apt install flatpak

Installing software manager plugin

Install the plugin to search for Flatpak apps directly from the Software Center.

For those using the KDE desktop environment, use the following command:

sudo apt install plasma-discover-backend-flatpak

For those using the GNOME desktop environment, use the following command:

sudo apt install gnome-software-plugin-flatpak

Add flatpak app repositories

Adding the Flatpak repositories is crucial because they host Flatpak apps, allowing you to download apps from these repositories. You can add multiple Flatpak repositories and choose which one to use when downloading packages.

The most popular flatpak repository out there is Flathub. To add Flathub to your list of Flatpak repositories, use this command:

flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

Besides Flathub, there are other popular repositories as well. Please find below a table of popular Flatpak repositories and the corresponding commands to add them:

Finding, installing and unistalling the flatpak app

After adding the repositories, the most convenient way to discover and install Flatpak apps is through your system’s software center. For KDE, use ‘Discover,’ and for GNOME, use ‘GNOME Software Center.’

Simply search for your desired app, and once the results are displayed, click on the ‘Install’ button in the app list. You can easily identify Flatpak packages by the Flatpak symbol located at the top right corner of the list items. You can uninstall a Flatpak package in the same manner.

Using the flatpak cli

You can also utilize a command-line interface (CLI) for Flatpak, enabling you to perform all of the aforementioned tasks and a wide range of additional functions.

Here are a few essential Flatpak commands:

See the list of added flatpak remote repositories

flatpak remotes --columns=name,url

Add the flatpak remote repository

See Add Flatpak repostories section.

Remove the flatpak remote repository

flatpak remote-delete <remote_name>

An ex: flatpak remote-delete flathub

List available software packages on the remote

flatpak remote-ls <remote_name>

Search for an app in the repositories:

flatpak search <search_pattern> --columns=name,application,description

As an example, let’s locate the Microsoft Teams package and install it. Execute the following command to search for teams using Flatpak:

flatpak search teams --columns=name,application,description

The output may be extensive, but we have successfully identified the accurate entry for Microsoft Teams:

Please make a note of the Application ID provided above. We will be using this value in the subsequent commands. For teams-for-linux, the Application ID is com.github.IsmaelMartinez.teams_for_linux.

Install the app

flatpak install <Application ID>

To install the Microsoft Teams:

flatpak install com.github.IsmaelMartinez.teams_for_linux

Run the application

flatpak run <Application ID>

See installed applications

flatpak list

Uninstall the applicaiton

flatpak uninstall <Application ID>

Update the packages to latest versions

flatpak update

Please refer Flatpak Command Line Reference for full list of commands.

1. The build process can take hours to complete, and if my internet connection is interrupted, the shell session may be disrupted, potentially causing the build to fail.
2. I would like to power off my local systems and return later to monitor the compilation progress.
3. I intend to resume my work right where I left off.

Fortunately, there exists a Linux tool called tmux, which can accomplish much more than the requirements I initially had in mind.

Tmux serves as a terminal multiplexer, enabling you to create and manage multiple shell sessions within a single local system terminal or within a single remote SSH connection. Especially during an SSH session, you don’t need to start another SSH connection to have two terminals open side by side on the remote server.

Let’s explore how to utilize tmux for the management of terminal sessions.

Starting a new session

Launch the terminal on your local system or log in to your remote server via SSH. To create a tmux session, employ the following command:

tmux new -s <sessionName>

An example of this:

tmux new -s buildroot_build

Detaching a tmux session

Pressing Ctrl+d will terminate a tmux session. To detach from the current session while keeping it running, use the following key sequence: Ctrl+b followed by d

List the tmux sessions

The command tmux ls displays all the tmux sessions currently running on the system.

$ tmux ls  
buildroot_build: 1 windows (created Sat Sep  9 21:29:31 2023)  
yocto_build: 1 windows (created Sat Sep  9 21:29:59 2023)

buildroot_build and yocto_build are two tmux sessions alive.

Attaching to a tmux session

From the output of the tmux ls command, you can identify all the tmux session names. To attach to a specific tmux session and resume your work from where you left off, use the following command:

tmux a -t <sessionName>

Let’s say one of tmux session name is yocto_build then to attach to that terminal session, use the command:

tmux a -t yocto_build

Splitting the Terminal pane

This is the best part of working with tmux. If you prefer not to disrupt your current terminal session and need another terminal session on your remote system, you can achieve this without initiating a new SSH session.

To split the terminal pane vertically, press the shortcut Ctrl+b followed by % ( Shift+5)

To split the terminal pane horizontally, press the shortcut Ctrl+b followed by " (Shift+').

Switching between the panes

Employ Ctrl+b in conjunction with the arrow keys to navigate between panes.

• To move the cursor to the right pane, use Ctrl+b followed by → (Right Arrow).
• To move the cursor to the left pane, use Ctrl+b followed by ← (Left Arrow).
• To move the cursor to the top pane, use Ctrl+b followed by ↑ (Up Arrow)
• To move the cursor to the bottom pane, use Ctrl+b followed by ↓ (Down Arrow)

Resizing the panes

Hold Ctrl+b, don’t release it and hold one of the arrow keys.

Creating new window

Use the shortcut Ctrl+b followed by c.

Switching between windows

Use the shortcut Ctrl+b followed by n to move to next window. And use Ctrl+b followed by p to move to previous window.

Scrolling in tmux

By default, in tmux, mouse scrolling or Page Up/Down keys do not work. To enable scrolling, press Ctrl+b, followed by [. Now you can use the vim editor navigation keys (j, k, l, h, g etc.) or simple arrow keys and PageUp/Down keys to navigate around terminal text.

While in scrolling mode, you can’t use any other keys

Quit scrolling

Press q to quit scrolling.

I hope this tutorial is helpful. For more information, you can refer to the man page by using the command man tmux.

Installing Inkscape

To install Inkscape on Debian/Ubuntu-based systems, execute the following command in the terminal:

sudo apt update && sudo apt install inkscape

Starting the app

Launch the Inkscape application from the Applications launcher. In the Quick Setup tab, you’ll find three fields to configure. I prefer the Dark Canvas, so I’ve changed it to that and saved the configuration. Click on Thanks in the Supported by You tab. In the Time to Draw tab, click the New Document button to start drawing an SVG image.

Draw a rectangular region

The recommended dimensions for a blog post feature image are 1200x628 pixels. Let’s create a rectangular region with those dimensions. The steps are as follows:

Click on the images to expand the view.

• Click on the Rectangle icon located in the toolbox on the left side (Shortcut - R).

• Draw a rectangle of any size by dragging the mouse on the canvas.

• You’ll find the Width and Height parameters in the Tool Controls Bar. Manually enter the width as 1200 and the height as 628 as shown in the below picture.

• Resize the Canvas page to match the drawing. This ensures that when you save the image, it will have exact dimensions of the rectangle you’ve drawn. You can use the shortcut Ctrl+Shift+R to do it automatically or follow the below procedure.
• Go to File -> Document Preperties… -> Resize page to drawing or selection (Ctrl+Shift+R)

Choose color and gradient

• You can change the color of your rectangle by selecting one of the colors from the palette below.

• I’ve chosen the green color, as you can see in the picture below. Let’s apply the Mesh gradient to the rectangle.
• Open the Fill and Stroke panel by pressing the shortcut Ctrl+Shift+F. Alternatively, you can open the same by clicking on Object -> Fill and Stroke… from the menu.

• Once the Fill and Stroke pane is opened, click on the Mesh gradient icon.

• As you can see the picture has turned out nicely. I’ve also adjusted the Blur effect to be 10%, as you can see in the bottom right.

• Navigate to the ‘Stroke style’ tab in the ‘Fill and Stroke’ pane. Change the width to 0.5.

Add the images

• Drag the images onto the canvas that you want to add to the feature image. Inkscape works seamlessly with SVG images. I imported ‘inkscape.svg’ onto the canvas, and during import, I selected the option ‘Include SVG Image as editable object(s) in the current file’.

• The image may be difficult to see if it’s small. However, you can adjust the dimensions of the image in the ‘Tool Controls Bar’. Use the ‘Select’ tool (Shortcut S) to drag and adjust the image’s position.

Add the text

• Now it’s time to add the post title to the image. Select the Text icon (Shortcut T).

• Click on the canvas where you want your blog post title to appear. Type the title. Pressing Ctrl+A now selects the whole title. You can change the font properties, such as font type, font size, etc., from the Tool Controls bar. I’ve discovered a few fonts that I believe will look appealing for the titles. Chilanka font, Dyuthi, Liberation Serif, Noto Serif Display and Purisa.

• To move the text to the desired location on the canvas, employ the select tool, click on the title, and then drag it to the desired position.

• Let’s enhance the text now. In Inkscape, fonts have both a ‘Fill’ and ‘Stroke.’ We can change the ‘Fill’ color by clicking on a color (I used 50% grey) from the palette. To modify the ‘Stroke’ color, press and hold the Shift key and then click on a color (I used 80% grey).
• Additionally, in the ‘Stroke style’ section of the ‘Fill and Stroke’ pane, we can fine-tune the ‘Width’ and ‘Dashes’ for further decoration.

Add brand

• You can also import PNG images onto the canvas, although SVG images are recommended. If you choose to import a PNG image, select Image DPI: as From file and set the Image Rendering Mode to None (auto).
• I have my blog address as a PNG image, which represents my brand. I’ve positioned it in one corner of the canvas.

Export to png image

• Finally, go to ‘File’ -> ‘Export PNG Image’ -> ‘Export As…’ from the Export PNG Image pane.

The final blog feature image

• Here is the final blog post feature image generated using the above steps in Inkscape.

Resetting the inkscape

Navigate to Edit -> Preferences -> System -> Click on Reset Preferences

Most blogs offer RSS or Atom feeds, which allow you to subscribe without giving out your email address. However, you still need a feed aggregator to scan for updates. A good option is to use the rss2email utility, which can deliver all of your blog/Youtube channel updates directly to your inbox. You can even set up rss2email to run as a system daemon, so it will automatically scan for updates at regular intervals.

This post will show you how to install, configure, and run rss2email as a system daemon on Ubuntu. This will allow rss2email to scan for feed updates at regular intervals and deliver them to your inbox.

Installing rss2email

To install rss2email utility on Debain/Ubuntu based systems, run the following command

sudo apt update && sudo apt install rss2email sendmail

From this point onwards, we will be running commands as the root user. Otherwise, we may encounter problems when configuring rss2email as a daemon later on.

sudo su -

Add recipient e-mail address

This is the e-mail address that will receive all the feed updates from rss2email utility. This step is one time configuration.

r2e new <recipient_mail_id> 

Configuring the rss2email

Edit the configuration file $HOME/.config/rss2email.cfg as follows.

vi $HOME/.config/rss2email.cfg

In the from field, I use my Gmail address as the sender_mail_id. This is different from the recipient_mail_id mentioned above. Therefore, when there is a blog update, you will receive an email to the recipient_mail_id that appears to have come from the sender_mail_id

from = <sender_email_id>
force-form = True
to = <recipient_mail_id>

Configuring SMTP settings to send the email through rss2email

Let’s use ssmtp utility to configure SMTP settings on Ubuntu. First, let’s install the sstmp.

sudo apt install ssmtp

Edit the ssmtp configuration file /etc/ssmtp/ssmtp.conf according to your email provider’s SMTP settings. As I have been using Gmail as my sender_mail_id, the configuration looks like the following:

root=<your_gmail_id>
mailhub=smtp.gmail.com:587
AuthUser=<your_gmail_id>
AuthPass=<gmail_pass or app_pass>
UseTLS=YES
UseSTARTTLS=YES

If you have two-factor authentication (2FA) enabled for your Gmail account, you may need to create an app password to use with rss2email.

Using the rss2email

Let’s learn how to add a blog feed to rss2email, so it can scan for new blog posts and send you updates in your email.

You can find RSS/Atom feed URL of any blog/YouTube using this guide. Once you get the URL of the feed, use the following command to add it to rss2email.

r2e add <feedName> <feedURL>

Give the feedName a value such as name of the blog. An example is give below.

r2e add NayabSDBlog https://www.nayab.dev/feed.xml

You can add as many feeds as you like using the same command.

Scan for new blog posts

Once you are satisfied with the number of feeds you have added, you can start sending all feed updates to your inbox by running the following command:

r2e run

Beware that if the feed has many posts, you may receive a lot of emails.

If your RSS feed has a lot of posts, and you don’t want to receive all of them in your inbox, run the following command. This command only needs to be run once per addition of blog feeds. And any subsequent blog/YouTube updates, you will get by running above command.

r2e run --no-send # Just scans but won't send e-mails.

Create a systemd timer for automatic periodic updates

We can use systemd timers to get periodic updates from the rss2email daemon service. To do this, we first need to create a systemd service file that the systemd timer can use.

cat << EOF >> /lib/systemd/system/rss2email.service
[Unit]
Description=Fetches RSS feeds and send them to email
Wants=rss2email.timer

[Service]
ExecStart=/usr/bin/r2e run

[Install]
WantedBy=multi-user.target
EOF

Enable the rss2email service with the below command. This step is optional as we invoke this service anyways with the systemd timers.

systemctl enable rss2email.service

This creates a symbolic link /etc/systemd/system/multi-user.target.wants/rss2email.service that points to the target file in /lib/systemd/system/rss2email.service. This ensures that the service will be started when the system boots.

Now, let’s write a rss2email.timer file.

cat << EOF >> /lib/systemd/system/rss2email.timer
[Unit]
Description=calling rss2email peridically
Requires=rss2email.service

[Timer]
Unit=rss2email.service
OnCalendar=*-*-* 00/6:00:00

[Install]
WantedBy=timers.target
EOF

Start and enable the timer with the following commands. Enabling timer will start the service when the system boots.

systemctl start rss2email.timer
systemctl enable rss2email.timer

The above rss2email.timer invokes the rss2email.service for every 6 hours. You can see that from the line OnCalendar=*-*-* 00/6:00:00

Once the timer triggers the rss2email service, all the blog and YouTube channel updates that you have enrolled with rss2email will be automatically sent to your inbox.

You can read more about systemd timer here

Commands for troubleshooting

Checking the service/timer status

systemctl status rss2email.service
systemctl status rss2email.timer

Checking the service/timer logs

journalctl -u rss2email.service
journalctl -u rss2email.timer

You can read more about journalctl here

Commands to start and stop the services

# For rss2email.service
systemctl start rss2email.service
systemctl stop rss2email.service

# For rss2email.timer
systemctl start rss2email.timer
systemctl stop rss2email.timer

Example logs of rss2email.service

Aug 15 05:39:39 dosing r2e[9960]: 2023-08-15 05:39:39,720 [INFO] fetch NayabSDBlog (https://www.nayab.dev/feed.xml -> basha@nayab.dev)
Aug 15 05:39:39 dosing r2e[9960]: 2023-08-15 05:39:39,766 [INFO] process NayabSDBlog (https://www.nayab.dev/feed.xml -> basha@nayab.dev)
Aug 15 05:39:39 dosing r2e[9960]: 2023-08-15 05:39:39,769 [INFO] send message for NayabSDBlog (https://www.nayab.dev/feed.xml -> basha@nayab.dev)
Aug 15 05:39:39 dosing sSMTP[9964]: Creating SSL connection to host
Aug 15 05:39:40 dosing sSMTP[9964]: SSL connection using ECDHE_RSA_AES_256_GCM_SHA384
Aug 15 05:39:42 dosing sSMTP[9964]: Sent mail for root@dosing (221 2.0.0 closing connection p21-20020aa78615000000b00687260020b1sm8792938pfn.72 - gsmtp) uid=0 username=root outbytes=1450
Aug 15 05:39:42 dosing r2e[9960]: 2023-08-15 05:39:42,880 [INFO] send message for NayabSDBlog (https://www.nayab.dev/feed.xml -> basha@nayab.dev)
Aug 15 05:39:42 dosing sSMTP[9969]: Creating SSL connection to host
Aug 15 05:39:43 dosing sSMTP[9969]: SSL connection using ECDHE_RSA_AES_256_GCM_SHA384
Aug 15 05:39:45 dosing sSMTP[9969]: Sent mail for root@dosing (221 2.0.0 closing connection k17-20020aa78211000000b0063b898b3502sm8800095pfi.153 - gsmtp) uid=0 username=root outbytes=1298
Aug 15 05:39:45 dosing r2e[9960]: 2023-08-15 05:39:45,891 [INFO] send message for NayabSDBlog (https://www.nayab.dev/feed.xml -> basha@nayab.dev)
Aug 15 05:39:45 dosing sSMTP[9970]: Creating SSL connection to host

Running rss2email on Ubuntu server

There are several benefits to running rss2email on a cloud server. First, it is more scalable. If you want to subscribe to a large number of RSS feeds, or if you want to have rss2email scan for updates more frequently, a cloud server will be able to handle the load. Second, it is more reliable. A cloud server is less likely to experience outages than a personal computer.

If you are looking to register for a cloud provider, Digitalocean is great option. You get $200 credit over 60 days period.

References

https://www.linuxbabe.com/ubuntu/install-use-rss2email-ubuntu-18-04 https://www.freedesktop.org/software/systemd/man/systemd.time.html https://unix.stackexchange.com/questions/126786/systemd-timer-every-15-minutes https://silentlad.com/systemd-timers-oncalendar-(cron)-format-explained

ANSI escape codes can be used to style the output of echo or printf. An escape code is a sequence of characters start with an ESC(033 in Octal representation) character, followed by second character in the ASCII range 64 to 95. This sequence can be of different length.

The general format of escape code for styling the terminal text is -

ESC [ {attr1};{attr2};....{attrn)m.

The ASCII equivalent of ESC character is 033(in Octal) or 0x1b(in Hexadecimal). We use 033 because it works for all operating systems.

Some examples for escape codes are -

'\033[0m'       #Reset text
'\033[0;33m'    #Yello color text
'\033[42m'      #Green background
'\033[1;42m'    #Bold text with Green background

Note that above escape code sequeces ends with m and there is no ; before that.

If we examine the code ‘\033[1;42m’,

Usage with echo

echo -e '\033[1;42m'This is text with green background

Don’t forget to use -e option along with echo command. Any text following the above code sequence will print with green background color.

Usage with printf

printf '\033[1;42m'This is text with green background

Text formatting

Text Color

Background color

Random text stype attributes

One or more attributes can be clubbed together for more styling.

A simple color echo solution for shell scripts

Save the following code in a file, let’s say cecho.sh

cecho() {
	local code="\033["
	case "$1" in
		black  | bk) color="${code}0;30m";;
		red    |  r) color="${code}1;31m";;
		green  |  g) color="${code}1;32m";;
		yellow |  y) color="${code}1;33m";;
		blue   |  b) color="${code}1;34m";;
		purple |  p) color="${code}1;35m";;
		cyan   |  c) color="${code}1;36m";;
		gray   | gr) color="${code}0;37m";;
		*) local text="$1"
			esac
			[ -z "$text" ] && local text="$color$2${code}0m"
			echo -e "$text"
}

Including the above file in any shell script will allow us to print color text on terminal.

Let’s say file display.sh has the following content.

#!/bin/sh
. /path/to/cecho.sh

cecho red "This is red text"

Now executing second shell script will display output in red color.

bash display.sh

References

bash:tip_colors_and_formatting

Stackoverflow: Change echo output

Terminal color escape sequences