TP-Link TL-WN821N v2 on Raspbian Bullseye

Having updated to bullseye, my Wifi dongle stopped working with the error 

[ 2270.938923] usb 1-1.4: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[ 2270.938940] usb 1-1.4: Product: USB2.0 WLAN
[ 2270.938959] usb 1-1.4: Manufacturer: ATHER
[ 2270.938997] usb 1-1.4: SerialNumber: 12345
[ 2271.050454] usb 1-1.4: reset high-speed USB device number 8 using dwc_otg
[ 2271.218098] usb 1-1.4: Direct firmware load for carl9170-1.fw failed with error -2
[ 2271.218139] usb 1-1.4: firmware not found.

Solution

sudo apt install firmware-linux-free

sudo apt install firmware-linux-nonfree

Unplug/plug the dongle

Use iwlist scan to find the SSID for my wifi network

Use raspi-config to set the SSID and password

Connection is established in a few seconds

Note - ensure you have a decent USB power supply and cable to the RPi as the dongle draws some extra current.

Integrity Measurement Architecture (IMA) on Raspian

What is IMA?

Linux Integrity Measurement Architecture (IMA) is a subsystem in the Linux kernel that provides mechanisms for ensuring the integrity of files, directories, and critical system components. IMA is part of the Linux kernel's security infrastructure and is used to detect and prevent unauthorized changes to the system.

What is EVM?

Linux Extended Verification Module (EVM) is a security feature in the Linux kernel designed to enhance the integrity of the system by protecting extended attributes (xattrs) of files. These attributes often include security-related metadata, such as those used by the Integrity Measurement Architecture (IMA), Linux Security Modules (LSMs) like SELinux or Smack, and other extended attributes.

Exploring some use cases

Enable IMA, EVM and build kernel

$ diff defconfig ./arch/arm/configs/bcm2709_defconfig

672a673

> CONFIG_TCG_TPM=m

1499,1500d1499

< CONFIG_IMA=y

< CONFIG_EVM=y

Boot with the kernel and check that IMA, EVM are present

root@raspberrypi:~# find /sys/kernel/security/

/sys/kernel/security/

/sys/kernel/security/evm

/sys/kernel/security/ima

/sys/kernel/security/integrity

/sys/kernel/security/integrity/evm

/sys/kernel/security/integrity/evm/evm

/sys/kernel/security/integrity/ima

/sys/kernel/security/integrity/ima/policy

/sys/kernel/security/integrity/ima/violations

/sys/kernel/security/integrity/ima/runtime_measurements_count

/sys/kernel/security/integrity/ima/ascii_runtime_measurements

/sys/kernel/security/integrity/ima/binary_runtime_measurements

/sys/kernel/security/lsm

Test digital signature validation of immutable files

The package ima-evm-utils was not available for my version of Raspian

$ apt-cache search ima-evm-utils

$

Download, configure, build, install

$ git clone https://github.com/stefanberger/ima-evm-utils.git

$ cd ima-evm-utils/

$ ./autogen.sh

$ ./configure

$ make

$ sudo make install

$ sudo ldconfig

Generate a key pair

pi@raspberrypi:~ $ openssl genrsa -out rsa_private.pem 2048

Generating RSA private key, 2048 bit long modulus (2 primes)

.............................................+++++

.....................+++++

e is 65537 (0x010001)

pi@raspberrypi:~ $ openssl rsa -pubout -in rsa_private.pem -out rsa_public.pem

writing RSA key

Import public key into keyring

pi@raspberrypi:~ $ sudo evmctl import --rsa rsa_public.pem $(keyctl newring _ima @u)

Importing public key F0D70A9FC543B7FD from file rsa_public.pem into keyring 348838330

keyid: 975180608

975180608

Test on hello world executable

pi@raspberrypi:~ $ cat hello.c

#include <stdio.h>

int main()

{

        printf("Hello world\n");

        return 0;

}

pi@raspberrypi:~ $ gcc hello.c -o hello

pi@raspberrypi:~ $ sudo evmctl ima_sign --key rsa_private.pem hello

hash(sha1): c7a17949155c2e35f0065551f4cc04adaf466eb3

evm/ima signature: 264 bytes

0302029bd7cf87010025f8f15ce309bb25dc27409dce375f01545d7ed7c7096e382ffe7bc1c92faa86056f6d145895a4372bdbe9fd2167475b0be45562d7ffdb3e7d4197263b384087fbb4be62074bff604b8404144de692011ea18d0e8109526500bd07d9e47a9a3192f1c6ffde86d317fd8bebb0d67360785520490b6fa80b358762afce1d11398ddd32a0ae7385921342174110447ccecea0ad1eea663f4acc98fbcfb31db1e7d56fa476ef118021341437511753e1530acd33c0b04875598983aea04cf4c74f5a7cf94419dc3fba0ca60850b3df8fc731c2bf399b7efbf5ccea4bb4d5a6cda0828a688837a709678d41eeeca8d47a3b3808279aae36b489dd0582199b5393b5ce

pi@raspberrypi:~ $ getfattr -m . -d ./hello

# file: hello

security.ima=0sAwICm9fPhwEAJfjxXOMJuyXcJ0CdzjdfAVRdftfHCW44L/57wckvqoYFb20UWJWkNyvb6f0hZ0dbC+RVYtf/2z59QZcmOzhAh/u0vmIHS/9gS4QEFE3mkgEeoY0OgQlSZQC9B9nkepoxkvHG/96G0xf9i+uw1nNgeFUgSQtvqAs1h2Kvzh0ROY3dMqCuc4WSE0IXQRBEfM7OoK0e6mY/SsyY+8+zHbHn1W+kdu8RgCE0FDdRF1PhUwrNM8CwSHVZiYOuoEz0x09afPlEGdw/ugymCFCz34/HMcK/OZt++/XM6ku01abNoIKKaIg3pwlnjUHu7KjUejs4CCearja0id0FghmbU5O1zg==

dm-integrity, dm-crypt, luks

Build dm-integrity for RPI

dm-integrity was not included in my Raspian kernel, built as per -

https://www.raspberrypi.com/documentation/computers/linux_kernel.html

and load (as a module)

dm-integrity (no encryption)

Create an image file as backing for a loop device

$ dd if=/dev/zero of=./file.img bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 2.28869 s, 45.8 MB/s

Create the loop device

$ sudo losetup --find --show ./file.img

/dev/loop0

Create key, format, open using integrity setup

$ dd if=/dev/urandom bs=32 count=1 of=./keyfile

$ sudo integritysetup format /dev/loop0 --tag-size 32 --integrity hmac-sha256 --integrity-key-file ./keyfile --integrity-key-size 32 --batch-mode

$ sudo integritysetup open /dev/loop0 testinteg --integrity hmac-sha256 --integrity-key-file ./keyfile --integrity-key-size 32 --batch-mode

$ sudo integritysetup status testinteg

/dev/mapper/testinteg is active.

  type:    INTEGRITY

  tag size: 32

  integrity: hmac(sha256)

  device:  /dev/loop0

  loop:    /home/pi/dm-integrity/file.img

  sector size:  512 bytes

  interleave sectors: 32768

  size:    190920 sectors

  mode:    read/write

  failures: 0

  journal size: 811008 bytes

  journal watermark: 50%

  journal commit time: 10000 ms

$ lsblk /dev/loop0

NAME        MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT

loop0         7:0    0  100M  0 loop

└─testinteg 254:0    0 93.2M  0 crypt

Format with ext4, mount, test

$ sudo mkfs.ext4 /dev/mapper/testinteg 

$ sudo mkdir /mnt/testinteg 

$ sudo mount /dev/mapper/testinteg /mnt/testinteg 

Create a test file

$ sudo dd if=/dev/zero of=/mnt/testinteg/zero bs=1M count=50

$ sudo hexdump /mnt/testinteg/zero

0000000 0000 0000 0000 0000 0000 0000 0000 0000

*

3200000

Tamper

$ dd if=/dev/random of=./file.img bs=1 seek=40M count=512

$ sudo umount /mnt/testinteg

$ sudo integritysetup close testinteg

Remount and check

$ sudo integritysetup open /dev/loop0 testinteg --integrity hmac-sha256 --integrity-key-file ./keyfile --integrity-key-size 32 --batch-mode

$ dmesg |tail

[  514.542274] device-mapper: integrity: dm-0: Checksum failed at sector 0x2e900

[  514.542773] device-mapper: integrity: dm-0: Checksum failed at sector 0x2e900

[  514.542802] Buffer I/O error on dev dm-0, logical block 23840, async page read

$ sudo integritysetup status testinteg

/dev/mapper/testinteg is active.

  type:    INTEGRITY

  tag size: 32

  integrity: hmac(sha256)

  device:  /dev/loop0

  loop:    /home/pi/dm-integrity/file.img

  sector size:  512 bytes

  interleave sectors: 32768

  size:    190920 sectors

  mode:    read/write

  failures: 2

  journal size: 811008 bytes

  journal watermark: 50%

  journal commit time: 10000 ms

dm-integrity finds the 'corrupt' data when mapping

$ sudo fsck.ext4 -a /dev/mapper/testinteg 

$ sudo mount /dev/mapper/testinteg /mnt/testinteg 

$ sudo hexdump /mnt/testinteg/zero

0000000 0000 0000 0000 0000 0000 0000 0000 0000

*

hexdump: /mnt/testinteg/zero: Input/output error

01bf800

dm-crypt (no integrity)

Create key and format, open using cryptsetup

$ dd if=/dev/urandom bs=32 count=1 of=./keyfile

$ sudo cryptsetup luksFormat --type luks2 /dev/loop1 --cipher aes-xts-plain64 --key-file ./keyfile --batch-mode

$ sudo cryptsetup open /dev/loop1 testcrypt --key-file ./keyfile

$ sudo cryptsetup status testcrypt

/dev/mapper/testcrypt is active and is in use.

  type:    LUKS2

  cipher:  aes-xts-plain64

  keysize: 512 bits

  key location: keyring

  device:  /dev/loop1

  loop:    /home/pi/luks2wip/file.img

  sector size:  512

  offset:  32768 sectors

  size:    172032 sectors

  mode:    read/write

$ lsblk /dev/loop1

NAME        MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT

loop1         7:1    0  100M  0 loop

└─testcrypt 254:0    0   84M  0 crypt

Format with ext4, mount, test

$ sudo mkfs.ext4 /dev/mapper/testcrypt

$ sudo mkdir /mnt/testcrypt

$ sudo mount /dev/mapper/testcrypt /mnt/testcrypt

$ sudo umount /mnt/testcrypt

Unmount

$ sudo cryptsetup close testcrypt

$ file file.img

file.img: LUKS encrypted file, ver 2 [, , sha256] UUID: 3f01b422-6a29-4d58-a9f4-ffbe992790b6

Tamper and check

$ dd if=/dev/zero of=./file.img bs=1 seek=40M count=1

$ sudo cryptsetup open /dev/loop1 testcrypt --key-file ./keyfile

$ sudo fsck.ext4 -a /dev/mapper/testcrypt

$ sudo mount /dev/mapper/testcrypt /mnt/testcrypt

dm-integrity + dm-crypt

https://archive.fosdem.org/2018/schedule/event/cryptsetup/

Create key and format, open using cryptsetup

$ dd if=/dev/urandom bs=32 count=1 of=./keyfile

$ sudo cryptsetup luksFormat --type luks2 /dev/loop2 --cipher aes-xts-plain64 --integrity hmac-sha256 --key-file ./keyfile --batch-mode

$ sudo cryptsetup open /dev/loop2 testintegcrypt --key-file ./keyfile

$ sudo cryptsetup status testintegcrypt

/dev/mapper/testintegcrypt is active.

  type:    LUKS2

  cipher:  aes-xts-plain64

  keysize: 768 bits

  key location: keyring

  integrity: hmac(sha256)

  integrity keysize: 256 bits

  device:  /dev/loop2

  loop:    /home/pi/dm-integ-crypt/file.img

  sector size:  512

  offset:  0 sectors

  size:    160200 sectors

  mode:    read/write

$ lsblk /dev/loop2

NAME                 MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT

loop2                  7:2    0  100M  0 loop

└─testintegcrypt_dif 254:1    0 78.2M  0 crypt

  └─testintegcrypt   254:2    0 78.2M  0 crypt

Format with ext4, mount, test

$ sudo mkfs.ext4 /dev/mapper/testintegcrypt

$ sudo mkdir /mnt/testintegcrypt

$ sudo mount /dev/mapper/testintegcrypt /mnt/testintegcrypt

Create a test file

$ sudo dd if=/dev/zero of=/mnt/testintegcrypt/zero bs=1M count=50

$ sudo hexdump /mnt/testintegcrypt/zero

0000000 0000 0000 0000 0000 0000 0000 0000 0000

*

3200000

Unmount

$ sudo umount /mnt/testintegcrypt

$ sudo cryptsetup close testintegcrypt

Tamper and check

$ dd if=/dev/random of=./file.img bs=1 seek=40M count=512

$ sudo cryptsetup open /dev/loop2 testintegcrypt --key-file ./keyfile

The 'corrupt' data isn't found until it is accessed

$ sudo fsck.ext4 -a /dev/mapper/testintegcrypt

Error reading block 32769 (Input/output error).

/dev/mapper/testintegcrypt: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

        (i.e., without -a or -p options)

$ sudo mount /dev/mapper/testintegcrypt /mnt/testintegcrypt

$ sudo hexdump /mnt/testintegcrypt/zero

0000000 0000 0000 0000 0000 0000 0000 0000 0000

*

hexdump: /mnt/testintegcrypt/zero: Input/output error

0b38000

Yocto - building a dmverity/squashfs ro-rootfs

Configure the kernel with dm-verity support

$ bitbake linux-yocto -c kernel_configme -f

$ bitbake linux-yocto -c menuconfig

Using menuconfig select -

Device Drivers / Multiple device drivers support / Device Mapper Support / DM "dm-mod.create=" parameter support = [*]

Verity target support = [*]

Verity data device root hash signature verification support = [*]

Cryptographic API / Certificates for signature checking / Additional X.509 keys for default system keyring = ("${HOME}/keys/verity_cert.pem")

Generate a config fragment and check the content

$ bitbake linux-yocto -c diffconfig

$ cat tmp/work/qemux86_64-poky-linux/linux-yocto/*/fragment.cfg

CONFIG_DM_INIT=y

CONFIG_DM_VERITY=y

CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG=y

# CONFIG_DM_VERITY_FEC is not set

CONFIG_SYSTEM_TRUSTED_KEYS="${HOME}/keys/verity_cert.pem"

$ mv tmp/work/qemux86_64-poky-linux/linux-yocto/*/fragment.cfg ../meta-mylayer/recipes-kernel/linux/linux-yocto/dmverity.cfg

Add a reference to the fragment in your kernel recipe - meta-mylayer/recipes-kernel/linux/linux-yocto_%.bbappend

SRC_URI += "file://dmverity.cfg"

Create the certificate

Parameter explanation

-nodes

No DES (i.e. don't encrypt the private key with Data Encryption Standard) 

-days

Specifies the number of days to make a certificate valid for. 

-set_serial

Specifies the serial number to use. 

In a certificate, the serial number is chosen by the CA which issued the certificate. It is just written in the certificate. The CA can choose the serial number in any way as it sees fit, not necessarily randomly (and it has to fit in 20 bytes). A CA is supposed to choose unique serial numbers, that is, unique for the CA.  

-subject

https://en.wikipedia.org/wiki/X.509#Sample_X.509_certificates

Command -

$ openssl req -x509 -newkey rsa:1024 -keyout verity_key.pem \

    -out verity_cert.pem -nodes -days 7300 -set_serial 01 -subject /CN=bugwhine.blogspot.com

Move them somewhere safe

$ mv verity_cert.pem ${HOME}/keys

$ mv verity_key.pem ${HOME}/keys

Build the kernel

$ bitbake linux-yocto -c clean

$ bitbake linux-yocto 

Confirm that it was configured correctly -

$ grep -i verity tmp/work/qemux86_64-poky-linux/linux-yocto/*/*/.config

CONFIG_DM_VERITY=y

CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG=y

# CONFIG_DM_VERITY_FEC is not set

# CONFIG_FS_VERITY is not set

CONFIG_SYSTEM_TRUSTED_KEYS="${HOME}/keys/verity_cert.pem"

Setup yocto to generate verity metadata for the rootfs image

$ git clone git://git.yoctoproject.org/meta-security

$ cd meta-security

$ git checkout --track remotes/origin/dunfell

$ cd ..

$ git clone https://github.com/openembedded/meta-openembedded.git

$ git checkout --track remotes/origin/dunfell

Add these layers to conf/bblayers.conf -

  meta-security \

  meta-openembedded/meta-oe \

  meta-openembedded/meta-python \

  meta-openembedded/meta-networking \

  meta-openembedded/meta-perl \

Create a wic kickstart file (recipes-core/images/my-image-verity-wic.wks) containing -

part / --source rootfs --ondisk sda --fstype=squashfs

part /media/rfs/rw --ondisk sda --fstype=ext4 --label rwoverlay --size 100M

part / --source rawcopy --ondisk sda --sourceparams="file=${IMGDEPLOYDIR}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_IMAGE_TYPE}.verity"

Create a new image recipe (recipes-core/images/my-image-verity-wic.bb) containing -

DESCRIPTION = "A console-only image with more full-featured Linux system \

functionality installed."

SRC_URI = "file://${FILE_DIRNAME}/${BPN}.wks"

IMAGE_FEATURES += "splash ssh-server-openssh"

IMAGE_INSTALL = "\

    packagegroup-core-boot \

    packagegroup-core-full-cmdline \

    ${CORE_IMAGE_EXTRA_INSTALL} \

    initscripts-readonly-rootfs-overlay \

    cryptsetup \

    "

DM_VERITY_IMAGE = "my-image-verity-wic"

DM_VERITY_IMAGE_TYPE = "squashfs"

IMAGE_CLASSES += "dm-verity-img"

IMAGE_FSTYPES = "squashfs squashfs.verity wic"

WICVARS_append = " DM_VERITY_IMAGE DM_VERITY_IMAGE_TYPE"

inherit core-image

WKS_FILE = "my-image.wks"

WKS_FILE_DEPENDS = "dosfstools-native mtools-native gptfdisk-native squashfs-tools-native"

WKS_FILE_DEPENDS_append_x86 = " syslinux-native syslinux"

WKS_FILE_DEPENDS_append_x86-64 = " syslinux-native syslinux"

WKS_FILE_DEPENDS_append_x86-x32 = " syslinux-native syslinux"

QB_KERNEL_CMDLINE_APPEND += "root=/dev/vda1 rootrw=/dev/vda2 rootrwoptions=rw,noatime init=/init"

QB_DEFAULT_FSTYPE = "wic"

QB_FSINFO = "wic:no-kernel-in-fs"

#QB_KERNEL_ROOT = "/dev/vda1"

Patch meta-security/classes/dm-verity-img.bbclass adding squashfs support -

VERITY_TYPES = "ext2.verity ext3.verity ext4.verity btrfs.verity squashfs.verity"

Build and note the verity parameters needed to map it

$ bitbake my-image-verity-wic

$ cat tmp/work-shared/qemux86-64/dm-verity/my-image-verity-wic.squashfs.verity.env

UUID=abcab4c0-3187-4b91-bcb5-d804229456e2

HASH_TYPE=1

DATA_BLOCKS=26760

DATA_BLOCK_SIZE=1024

HASH_BLOCK_SIZE=4096

HASH_ALGORITHM=sha256

SALT=5ac714319ab03dfad686c5563dc78b3be03c802c0f62477a423a56148a32c417

ROOT_HASH=6b4478922104f14b6ca6f463dab26b9a4c653e6b2507e493cf2c95f687b19fc8

DATA_SIZE=27402240

Boot in qemu

At this stage we have both the original squashfs image, and squashfs image with verity metadata appended in partitions 1 and 3 of the wic image.

We boot the squashfs image first -

$ runqemu my-image-verity-wic nographic kvm

Poky (Yocto Project Reference Distro) 3.1.24 qemux86-64 ttyS0

qemux86-64 login: root

root@qemux86-64:~#

root@qemux86-64:~# lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT

hdc     22:0    1     4G  0 disk

vda    253:0    0 153.1M  0 disk

|-vda1 253:1    0  26.1M  0 part /media/rfs/ro

|-vda2 253:2    0   100M  0 part /media/rfs/rw

`-vda3 253:3    0    27M  0 part

Then map and mount it -

root@qemux86-64:~# veritysetup --data-block-size=1024 --hash-offset=27402240 open /dev/vda3 root /dev/vda3 \

>  6b4478922104f14b6ca6f463dab26b9a4c653e6b2507e493cf2c95f687b19fc8

root@qemux86-64:~# ls /dev/mapper/root

/dev/mapper/root

root@qemux86-64:~# mkdir /tmp/dmroot

root@qemux86-64:~# mount /dev/mapper/root /tmp/dmroot/

mount: /var/volatile/tmp/dmroot: WARNING: device write-protected, mounted read-only.

root@qemux86-64:~#

and confirm that it is readable

root@qemux86-64:~# file /tmp/dmroot/usr/sbin/veritysetup

/tmp/dmroot/usr/sbin/veritysetup: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-x86-64.so.2, BuildID[sha1]=8035280d420b22091cf8319d4ceda8e6d

Now we'll tamper with the image, reboot -

root@qemux86-64:~# dd if=/dev/zero of=/dev/vda3 bs=1024 skip=10 count=1

1+0 records in

1+0 records out

1024 bytes (1.0 kB, 1.0 KiB) copied, 0.00516249 s, 198 kB/s

root@qemux86-64:~# reboot

And check if we can remap/mount it -

root@qemux86-64:~#

root@qemux86-64:~# veritysetup --data-block-size=1024 --hash-offset=27402240 open /dev/vda3 root /dev/vda3 \

>  6b4478922104f14b6ca6f463dab26b9a4c653e6b2507e493cf2c95f687b19fc8

Verity device detected corruption after activation.

root@qemux86-64:~#

root@qemux86-64:~# dmesg |tail

[   46.457801] Buffer I/O error on dev dm-0, logical block 0, async page read

[   46.459131] device-mapper: verity: 253:3: data block 0 is corrupted

[   46.459468] device-mapper: verity: 253:3: data block 0 is corrupted

[   46.459475] Buffer I/O error on dev dm-0, logical block 0, async page read

[   46.461389] Buffer I/O error on dev dm-0, logical block 0, async page read

[   46.462957] Buffer I/O error on dev dm-0, logical block 0, async page read

[   46.465372] Buffer I/O error on dev dm-0, logical block 0, async page read

[   46.466989] Buffer I/O error on dev dm-0, logical block 0, async page read

[   46.468663] Buffer I/O error on dev dm-0, logical block 0, async page read

[   46.544350] device-mapper: verity: 253:3: reached maximum errors

root@qemux86-64:~#

root@qemux86-64:~# mkdir /tmp/dmroot

root@qemux86-64:~# mount /dev/mapper/root /tmp/dmroot/

mount: /var/volatile/tmp/dmroot: can't read superblock on /dev/mapper/root.

root@qemux86-64:~#

Note it complains about logical block 0 as I used 'skip=10' rather than 'seek=10' in my dd command.

As previously, the files are available at -

https://github.com/bugwhine/meta-mylayer

Kudos to https://www.timesys.com/security/dm-verity-without-an-initramfs/

Next steps will be 

- signing and authenticating the root hash

- boot with authentication

Yocto - read-only rootfs (squashfs) + ext4 overlay (qemu)

Experimenting with a qemu yocto build that models an Embedded system with a read-only rootfs, and writeable overlay.

Basic yocto setup

Clone git://git.yoctoproject.org/poky

Checkout dunfell branch

Clone https://github.com/marcusfolkesson/meta-readonly-rootfs-overlay.git

Update the compatibility in meta-readonly-rootfs-overlay/conf/layer.conf to match your poky branch

LAYERSERIES_COMPAT_readonly-rootfs-overlay = "honister kirkstone dunfell"

source oe-init-build-env

Add meta-readonly-rootfs-overlay to build/conf/bblayers.conf

Create own layer meta-mylayer (git@github.com:bugwhine/meta-mylayer.git)

and add to build/conf/bblayers.conf

Setup meta-mylayer/conf/layer.conf containing the boilerplate -

# We have a conf and classes directory, add to BBPATH

BBPATH .= ":${LAYERDIR}"

# We have recipes-* directories, add to BBFILES

BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \

            ${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "mylayer"

BBFILE_PATTERN_mylayer = "^${LAYERDIR}/"

BBFILE_PRIORITY_mylayer = "5"

LAYERVERSION_mylayer = "4"

LAYERSERIES_COMPAT_mylayer = "dunfell"

Add squashfs support to the yocto kernel

$ bitbake linux-yocto -c kernel_configme -f

$ bitbake linux-yocto -c menuconfig

Use menuconfig to add squashfs support, and customize options as desired

$ bitbake linux-yocto -c diffconfig
$ mkdir -p meta-mylayer/recipes-kernel/linux
$ mv fragment.cfg ../meta-mylayer/recipes-kernel/linux/linux-yocto/squashfs.cfg

Create a bbappend file meta-mylayer/recipes-kernel/linux/linux-yocto_%.bbappend referencing the fragment

FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"

SRC_URI += "file://squashfs.cfg"

Build the kernel 

$ bitbake linux-yocto

And confirm that the configuration is present

$ grep SQUASHFS `find tmp/work/qemux86_64-poky-linux/linux-yocto/ -name '.config'`

CONFIG_SQUASHFS=y

...

CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3

Setup an image (wic)

Create an image recipe meta-mylayer/recipes-core/images/my-image-wic.bb with content (based on core-image-full-cmdline)

DESCRIPTION = "A console-only image with more full-featured Linux system \

functionality installed."

SRC_URI = "file://${FILE_DIRNAME}/${BPN}.wks"

IMAGE_FEATURES += "splash ssh-server-openssh"

IMAGE_INSTALL = "\

    packagegroup-core-boot \

    packagegroup-core-full-cmdline \

    ${CORE_IMAGE_EXTRA_INSTALL} \

    initscripts-readonly-rootfs-overlay \

    "

IMAGE_FSTYPES = "wic"

inherit core-image

WKS_FILE = "my-image-wic.wks"

WKS_FILE_DEPENDS = "dosfstools-native mtools-native gptfdisk-native squashfs-tools-native"

WKS_FILE_DEPENDS_append_x86 = " syslinux-native syslinux"

WKS_FILE_DEPENDS_append_x86-64 = " syslinux-native syslinux"

WKS_FILE_DEPENDS_append_x86-x32 = " syslinux-native syslinux"

QB_KERNEL_CMDLINE_APPEND += "root=/dev/vda1 rootrw=/dev/vda2 rootrwoptions=rw,noatime init=/init"

QB_DEFAULT_FSTYPE = "wic"

QB_FSINFO = "wic:no-kernel-in-fs"

#QB_KERNEL_ROOT = "/dev/vda1"

Create the wks (wick kickstart script) meta-mylayer/recipes-core/images/my-image-wic.wks with content - 

part / --source rootfs --ondisk sda --fstype=squashfs --align 1024

part /media/rfs/rw --ondisk sda --fstype=ext4 --label rwoverlay --size 100M

Build and run

$ bitbake my-image-wic
...

$ runqemu my-image-wic nographic kvm

...

Booting from ROM...

[    0.000000] Linux version 5.4.230-yocto-standard (oe-user@oe-host) (gcc version 9.5.0 (GCC)) #1 SMP PREEMPT Wed Feb 1 15:40:31 UTC 2023

[    0.000000] Command line: root=/dev/vda rw  console=ttyS0 mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 root=/dev/vda1 rootrw=/dev/vda2 rootrwoptions=rw,noatime init=/ini

...

Poky (Yocto Project Reference Distro) 3.1.24 qemux86-64 ttyS0

qemux86-64 login: root

Check the rootfs mounts  

root@qemux86-64:~# lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT

hdc     22:0    1     4G  0 disk

vda    253:0    0 126.3M  0 disk

|-vda1 253:1    0  25.3M  0 part /media/rfs/ro

`-vda2 253:2    0   100M  0 part /media/rfs/rw

root@qemux86-64:~# cat /proc/mounts

...

/dev/root /media/rfs/ro squashfs ro,relatime 0 0

/dev/vda2 /media/rfs/rw ext4 rw,noatime 0 0

overlay / overlay rw,relatime,lowerdir=/media/rfs/ro,upperdir=/media/rfs/rw/upperdir,workdir=/media/rfs/rw/work 0 0

...

Confirm that the overlay is working

root@qemux86-64:~# touch /etc/aaa

root@qemux86-64:~# ls /media/rfs/rw/upperdir/etc/aaa

/media/rfs/rw/upperdir/etc/aaa

root@qemux86-64:~# ls /media/rfs/ro/etc/aaa

ls: cannot access '/media/rfs/ro/etc/aaa': No such file or directory

TP-Link TL WN823N on Raspberry Pi 2B

Although this page  -
https://elinux.org/RPi_USB_Wi-Fi_Adapters
states -
TL-WN823N Works out of box on Raspian using powered USB Hub

For me, although it was identified on USB, wlan0 did not exist.

The procedure from -
https://www.raspberrypi.org/forums/viewtopic.php?p=462982#p462982

resolved it, such that
pi@raspberrypi:~ $ dmesg |grep -E "8192eu|wlan"
[    6.130806] 8192eu: loading out-of-tree module taints kernel.
[    6.282145] RTL871X: rtl8192eu v4.4.1_17696.20160509_BTCOEX20160412-0042
[    6.282164] RTL871X: rtl8192eu BT-Coex version = BTCOEX20160412-0042
[    6.417300] RTL871X: rtw_ndev_init(wlan0) if1 mac_addr=50:3e:aa:86:9d:85
[    6.419838] usbcore: registered new interface driver rtl8192eu
[   11.433648] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   20.945234] RTL871X: rtw_set_802_11_connect(wlan0)  fw_state=0x00000008
[   22.527221] RTL871X: rtw_cfg80211_indicate_connect(wlan0) BSS not found !!
[   23.053309] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

pi@raspberrypi:~ $ lsusb
Bus 001 Device 004: ID 2357:0109 TP-Link TL WN823N RTL8192EU

pi@raspberrypi:~ $ uname -a

Linux raspberrypi 4.19.113-v7+ #1300 SMP Thu Mar 26 16:53:09 GMT 2020 armv7l GNU/Linux

pi@raspberrypi:~ $ cat /etc/os-release

PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"

NAME="Raspbian GNU/Linux"

VERSION_ID="10"

VERSION="10 (buster)"

VERSION_CODENAME=buster

ID=raspbian

ID_LIKE=debian

HOME_URL="http://www.raspbian.org/"

SUPPORT_URL="http://www.raspbian.org/RaspbianForums"

BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

Docker Toolbox (on Windows) cheatsheet

Start with an empty ubuntu container

$ docker run -t -i ubuntu /bin/bash
$ exit

Commit it to a new image
$ docker commit d1dbe5528e65 commitrunning

Open VirtualBox, to configure shared drives

Setup a shared folder named 'd' with path 'd:\"
In the (Linux) shell (docker@default) give the commands
docker@default:~$ sudo mkdir /d
docker@default:~$ sudo mount -t vboxsf d /d

Add the volume to the image

$ docker run -ti -v //d/repo/:/repo commitrunning /bin/bash

Display containers

$ docker ps -a

Display images

$ docker image ls

Display dockerfile for container

$ docker container inspect unruffled_shtern

About dockerfiles, containers, images

https://blog.octo.com/en/docker-registry-first-steps/

Connect to running container

$ docker exec -it unruffled_shtern /bin/bash

Yocto kernel in-tree development work-flows

The Yocto Project Linux Kernel Development Manual, covers at least two flows for kernel development - 'Traditional Kernel Development' and 'devtool'. Here, I'll present some experiences with both these methods, along with a third method that I found convenient.

Traditional Kernel Development
Preparation
- create a layer for holding kernel patches, and configuration fragments
- create an append recipe (eg. meta-mylayer/recipes-kernel/linux/linux-yocto_4.12.bbappend) that identifies the patches and configuration fragments that you wish to apply
- create a local clone of the Yocto Linux Kernel

Development Loop

- Make code and/or configuration changes in local clone of Yocto Linux Kernel

- Stage and commit the changes (note this is necessary to have them included in the build)

- Adjust conf/local.conf to point to your local kernel clone

- Build and test the changes

- Generate a patch/config fragment

- Move the patch file to your layer, and update the .bbappend file to use it

Reflecting on the flow

Despite the efficiency of git's 'amend commit' function, the loop is quite heavy/time consuming.

For example, if you find the need to add a few printk debug statements, for troubleshooting, committing them each time before building seems an unnecessary burden.

Devtool Kernel Development

Preparation
- create a layer for holding kernel patches
- create an append recipe (eg. meta-mylayer/recipes-kernel/linux/linux-yocto_4.12.bbappend) that identifies the patches that you wish to apply
- (build and install an extensible SDK)
- build a clean image
- checkout the kernel source using 'devtool modify linux-yocto'. This step creates a local copy of the kernel source, in the (SDK) workspace, as well a recipe to include it in the build

Development Loop

- Make code changes in the SDK workspace clone of the kernel source tree

- Build and test the changes

- Stage and commit the changes

- Use 'devtool finish' to generate patches, and include them in your layer

Reflecting on the flow

This flow address the burdens of the traditional flow, as the stage/commit/patch steps are moved outside the change-build-test loop. I found this works well for source code changes.

A limitation of the flow, is that configuration fragments and patches are 'locked' during the preparation step of the flow. Ie. if, whilst in the development loop, you wish to add a configuration fragment ('from the shelf'), you should exit the flow, add the fragment, and re-enter the flow by again completing the preparation steps.

Alternatively, one can manually apply the fragments/patches in the workspace - but doing so conflates these changes with those being made in the development loop.

External Source Kernel Development
Preparation

- create a local clone of the Yocto Linux Kernel

- create a layer for holding kernel patches, and configuration fragments
- create an append recipe (eg. meta-mylayer/recipes-kernel/linux/linux-yocto_4.12.bbappend) that identifies the patches and configuration fragments that you wish to apply
- in the .bbappend recipe add the following -
inherit externalsrc
EXTERNALSRC = "/repo/linux-custom"
SRCTREECOVEREDTASKS := "do_validate_branches do_kernel_checkout do_fetch"

Development Loop

- Make code and/or configuration changes in the kernel source tree

- Build and test the changes

- Stage and commit the changes

- Generate a patch/config fragment

- Move the patch file to your layer, and update the .bbappend file to use it

- Remove the references to the local clone of the Yocto Linux Kernel when done

Reflecting on the flow

This flow attempts to combine the best parts of the other two flows.

It 'gives back' the capability to add/remove patches/configuration fragments via the meta layer (aka. recipe), by overriding this definition in the kernel-yocto.bbclass -

SRCTREECOVEREDTASKS += "do_kernel_configme do_validate_branches do_kernel_configcheck do_kernel_checkout do_fetch do_unpack do_patch"

Thus allowing patches and config fragements to be applied by running the 'unpack' task when building. ie.

bitbake -C unpack linux-yocto

It retains the simple change-build-test loop of the devtool flow.

It sacrifices the automated update of the meta data, provided by 'devtool finish'.

Yocto - update kernel command line in image

The kernel command line is part of the machine configuration.

If you wish to add to it 'manually', you can use the APPEND variable, in for example your conf/local.conf

APPEND += "oops=panic panic=5"

Then, depending on which boot mechanism you're using, you will need to force building of the boot configuration, to include the change.

eg.
$ bitbake -C populate_sysroot grub-efi

$ grep panic build/tmp/work/genericx86_64-poky-linux/core-image-minimal/1.0-r0/core-image-minimal-1.0/hddimg/EFI/BOOT/grub.cfg
linux /vmlinuz LABEL=boot root=/dev/ram0 oops=panic panic=5 

Unfortunately, as is sometimes the case with Yocto, the left hand doesn't know what the right is doing.

$ grep cmdline_append  build/tmp/deploy/images/genericx86-64/core-image-minimal-genericx86-64.qemuboot.conf

qb_kernel_cmdline_append = vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1

This likely needs tweaking below -

$ grep QB_KERNEL_CMDLINE_APPEND meta/conf/machine/include/qemuboot-x86.inc

QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=${UVESA_MODE} oprofile.timer=1 uvesafb.task_timeout=-1"

Similarly, the append is not present, in the wic image -

$ bitbake -C image_wic core-image-minimal 

$ sudo losetup -o $((2048*512)) --show -f core-image-minimal-genericx86-64.wic

/dev/loop1

$ mkdir /mnt/loop1

$ sudo mount /dev/loop1 /mnt/loop1

$ cat /mnt/loop1/EFI/BOOT/grub.cfg 

serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1

default=boot

timeout=5

menuentry 'boot'{

linux /bzImage root=PARTUUID=c496bfa5-a796-473c-bb6f-50d7b0161295 rootwait rootfstype=ext4 console=ttyS0,115200 console=tty0

}

This can be tweaked in the 'kickstart' file below -

$ grep append meta-yocto-bsp/wic/genericx86.wks

bootloader --ptable gpt --timeout=5 --append="rootfstype=ext4 console=ttyS0,115200 console=tty0"

Yocto Project - dev manual log

Customizing images
- local.conf
  IMAGE_INSTALL_append
  add strace, rebuild, test - seemed to result in a significant rebuild
  real time to do 'nothing' rebuild = 28 seconds
  real time to add 'pciutils, usbutils' rebuild = 7 minutes
  real time to add 'kbd, kbd-keymaps' rebuild = 5:30 minutes

- IMAGE_FEATURES and EXTRA_IMAGE_FEATURES

  in conf/local.conf "read-only-rootfs empty-root-password allow-empty-password"
- Custom .bb
  Move above changes into meta/recipes-core/images/core-image-steve.bb
  rebuild, test - quick.
  Add image feature ssh-server-dropbear
Writing a new recipe
- Creating the Base Recipe Using devtool add
  Follow the autotools amhello example, to create an application, store in git repo locally
  Run 'devtool add amhello /mnt/ee/repo/amhello' -> recipe in workspace
  Run 'devtool build-image core-image-steve' to build image including recipes from workspace
  deployed in /usr/bin/hello
- Creating a layer in which to put the recipe

  bitbake-layers create-layer ../meta-steve

  bitbake-layers add-layer ../meta-steve

- Move recipe to layer

  devtool finish amhello meta-steve

- Re-build image

  Add amhello to core-image-steve.bb

  gotcha - the recipe is missing the 'S = "${WORKDIR}/git"' line. This results in no build

  see Build an example package based on a git repository

Headless ubuntu server install (EFI)

Installing ubuntu server on a UEFI machine, via serial console only

Create USB stick (real or for qemu)

$ qemu-img create -f raw ubuntu_efi_inst.img 2G
Formatting 'ubuntu_efi_inst.img', fmt=raw size=2147483648

Create an EFI System Partition (ESP) on it

[steve@steve-GA-880GMA-UD2H archlinux]$ gdisk ubuntu_efi_inst.img 

GPT fdisk (gdisk) version 1.0.1

Partition table scan:

  MBR: not present

  BSD: not present

  APM: not present

  GPT: not present

Creating new GPT entries.

Command (? for help): n

Partition number (1-128, default 1): 

First sector (34-4194270, default = 2048) or {+-}size{KMGTP}: 

Last sector (2048-4194270, default = 4194270) or {+-}size{KMGTP}: 

Current type is 'Linux filesystem'

Hex code or GUID (L to show codes, Enter = 8300): ef00

Changed type of partition to 'EFI System'

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING

PARTITIONS!!

Do you want to proceed? (Y/N): y

OK; writing new GUID partition table (GPT) to ubuntu_efi_inst.img.

Warning: The kernel is still using the old partition table.

The new table will be used at the next reboot or after you

run partprobe(8) or kpartx(8)

The operation has completed successfully.

Format it

$ sudo losetup --partscan --show --find ubuntu_efi_inst.img 

/dev/loop3

$ sudo mkfs -t vfat /dev/loop3p1

mkfs.fat 3.0.28 (2015-05-16)

unable to get drive geometry, using default 255/63

Mount it

$ sudo mkdir /mnt/target

$ sudo mount /dev/loop3p1 /mnt/target

Loop mount the installation iso

$ sudo mount -o loop Downloads/ubuntu-16.04.2-server-amd64.iso /mnt/loop/

mount: /dev/loop4 is write-protected, mounting read-only

Copy files needed for EFI boot

$ sudo cp -vr /mnt/loop/EFI /mnt/target/

$ sudo cp -vr /mnt/loop/boot /mnt/target/

$ sudo cp -vr /mnt/loop/install /mnt/target/

Copy the ISO on to it (work-around for installer issues)

Copy the iso file onto the partition, needed during ubuntu install to mount CD

$ sudo cp Downloads/ubuntu-16.04.2-server-amd64.iso /mnt/target/

Patch grub and linux cmd line, to use serial console

$ sudo vi /mnt/target/boot/grub/grub.cfg

#add the lines below, at the top of the file

serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1

terminal_input --append serial

terminal_output --append serial

#subsequent terminal entries need to also use --append eg.

terminal_output --append gfxterm

#edit any wanted linux entries to use console as below

#see also https://www.kernel.org/doc/Documentation/ia64/serial.txt

linux /install/vmlinuz  file=/cdrom/preseed/ubuntu-server.seed earlycon=uart,io,0x3f8 earlycon=uart,io,0x3f8 console=uart,io,0x3f8 ---

Boot from the prepared drive

#now boot using qemu or real system (with mnt/target written to usb storage device)

#for qemu we need to make a destination for the ubuntu install

$ qemu-img create -f qcow2 ubuntu2.qcow2 16G

Formatting 'ubuntu2.qcow2', fmt=qcow2 size=17179869184 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16

#optionally run with -nographic,or switch to serial view (ctrl-alt-3)

sudo qemu-system-x86_64 -smp 2 -enable-kvm -m 1G -hda ubuntu2.qcow2 -drive file="ubuntu_efi_inst.img",index=1,media=disk,format=raw -bios /usr/share/edk2/ovmf/OVMF_CODE.fd -nographic

Ubuntu installation process begins

Complete localization options

# on seeing error "Your installation CD-ROM couldn't be mounted."

# https://askubuntu.com/questions/671159/bootable-usb-needs-cd-rom

# skip retry, exit to shell

# mount disk

~ # mount -t vfat /dev/sdb1 /media

~ # mount -o loop /media/ubuntu-16.04.2-server-amd64.iso /cdrom

~ # exit

# now detect CD-ROM

# don't unmount partitions that are in use (the CD is mounted from here)

# do guided install on other disk (sda in this example)

# after the step 'Install grub bootloader' you should get the 'Installation complete' message

# this is a good point to drop back into the shell, and review what has been done

Review grub setup on target drive

~ # cat /target/boot/efi/EFI/ubuntu/grub.cfg 

search.fs_uuid 6b25fe16-1db7-49c2-91a8-15bd590dade8 root hd0,gpt2 

set prefix=($root)'/boot/grub'

configfile $prefix/grub.cfg

~ # grep terminal /target/boot/grub/grub.cfg 

terminal_input --append serial

terminal_output --append serial

terminal_output --append gfxterm

~ # grep serial /target/boot/grub/grub.cfg 

serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1

terminal_input --append serial

terminal_output --append serial

~ # grep console /target/boot/grub/grub.cfg 

linux /boot/vmlinuz-4.4.0-62-generic.efi.signed root=/dev/sda2 ro earlycon=uart,io,0x3f8 console=uart,io,0x3f8  

#now exit, and reboot

#good luck!

HC-06 Bluetooth Module

Based on http://www.martyncurrey.com/arduino-with-hc-05-bluetooth-module-at-mode/

Default mode

Note, use 'software serial' mode on Arduino, as regular uart (pins 0, 1) are also used for USB communication (needed by the IDE).

In the example use pins 2, 3 for RX/TX.
Use voltage divider to get 5v output from Arduino to 3.3v safe for RX on HC-05.

On power up, 2 blinks per second = disconnected
Connect using android device, with 'Serial Bluetooth Terminal' app
Pair device, then connect.
Now should have a steady led
Use code from - https://github.com/bugwhine/arduino/blob/master/bluetooth/bluetooth.ino
Default baud rate for bluetooth side is 9600
From arduino IDE, run program, and open serial monitor
Should be possible to communicate between arduino serial monitor and bluetooth serial app on phone


[steve Arduino]$ hcitool scan
Scanning ...
98:D3:32:20:87:15 HC-06

[steve Arduino]$ sudo rfcomm bind 0 98:D3:32:20:87:15 1

[steve Arduino]$ sudo minicom -s

Serial Port Setup

A -    Serial Device      : /dev/rfcomm0

E  -    Bps/Par/Bits       

C:   9600

Serial comms should now work between minicom, and the arduino serial monitor.

nodejs

sudo dnf install bluez-libs-devel

sudo npm -g install bluetooth-serial-port

Use example code from https://github.com/eelcocramer/node-bluetooth-serial-port,

or - https://github.com/bugwhine/arduino/blob/master/bluetooth/btserial.js

node btserial.js

connected

Received: Size of data buf = 1

h

Received: Size of data buf = 6

ello

Docker, Jenkins, Github

Ensure that user belongs to docker group

[steve ~]$ id steve
uid=1000(steve) gid=1000(steve) groups=1000(steve),10(wheel),975(vboxusers),1002(docker)

User a persistent volume (to keep data), and the :z option to deal with selinux

[steve ~]$ docker run -p 8080:8080 -p 50000:50000 -v /home/steve/jenkins:/var/jenkins_home:z jenkins

Create repo on github, push code and makefile

https://github.com/bugwhine/hellojenkins

Install gcc and related tools into jenkins container

[steve ~]$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                                              NAMES
04105a89f166        jenkins             "/bin/tini -- /usr/lo"   5 minutes ago       Up 5 minutes        0.0.0.0:8080->8080/tcp, 0.0.0.0:50000->50000/tcp   ecstatic_williams

[steve ~]$ docker exec -u root  04105a89f166 apt-get -y install gcc make

Create job in jenkins

- Source Code Management

  - git

  - Repository URL: git@github.com:bugwhine/hellojenkins.git

  - Credentials: bugwhine (add using dropdown)

- Build

  - execute shell

    - make

Build now

Learning linux driver development with qemu

Linux Drivers

PCI

Based on instructions here -
http://nairobi-embedded.org/linux_pci_device_driver.html

Build yocto guest OS

$ git clone git://git.yoctoproject.org/poky
poky]$ git checkout morty

poky]$ source oe-init-build-env

#for those of us with non-US keyboards (you can also skip this step if using 'nographic' mode for qemu

build]$ echo "IMAGE_INSTALL_append = \" kbd keymaps kbd-keymaps\"" >> conf/local.conf

#this will take a while

build]$ bitbake core-image-sato-sdk

#now run it in qemu

build]$ runqemu qemux86-64 core-image-sato-sdk ext4 nographic qemuparams="-device ivshmem,shm=ivshmem,size=1"

#change keyboard layout if needed

root@qemux86-64:~# loadkeys /usr/share/keymaps/i386/qwerty/sv-latin1.map.gz 

#build guest module
#copy code to guest
[host pci]$ scp -r guest/ root@192.168.7.2:~/

ssh root@192.168.7.2
root@qemux86-64:~# cd /usr/src/kernel

root@qemux86-64:/usr/src/kernel# make modules_prepare

root@qemux86-64:/usr/src/kernel# cd ~/guest

root@qemux86-64:guest # make
root@qemux86-64:~/guest# sudo insmod ne_ivshmem_ldd_basic.ko

root@qemux86-64:~/guest# ls -l /dev/ivshmem0

root@qemux86-64:~/guest# sudo ./ne_ivshmem_shm_guest_usr -w "Dunia, vipi?"

main:169:: writing "Dunia, vipi?"

[host pci]$ hexdump -C /dev/shm/ivshmem

00000000  44 75 6e 69 61 2c 20 76  69 70 69 3f 00 00 00 00  |Dunia, vipi?....|

00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

User mode

Now for user-mode, based on instructions here

http://nairobi-embedded.org/uio_example.html

Fritzing on Fedora 24

Fritzing fails to start as below, when run on Fedora 24.
See also - https://github.com/fritzing/fritzing-app/issues/3245

tar xvf Downloads/fritzing-0.9.3b.linux.AMD64.tar.bz2 
cd ~/fritzing-0.9.3b.linux.AMD64

./install_fritzing.sh

./Fritzing

fritzing-0.9.3b.linux.AMD64/lib/Fritzing: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

This can be resolved by replacing libgit2 as below -

cd lib

rm libgit*

ln -s /usr/lib64/libgit2.so.24 libgit2.so.23 
cd ~/fritzing-0.9.3b.linux.AMD64

./Fritzing

Enlarging an ext2 partition (and filesystem) without data loss on Centos 6

I have tested the procedure using qemu-kvm.

qemu-kvm -boot once=d -cdrom CentOS-6.7-i386-LiveCD.iso -hda centos_2G.img -m 2G

Using a live CD image, to do the resizing, and a USB flash disk image as the test subject.

The general procedure described for doing this is as below -

Check that filesystem is OK
e2fsck /dev/sda1

Use fdisk to delete and recreate the partition, in place, but with increased size
fdisk /dev/sda
p - to show table, note details
d - to delete partition
n - to create new partition, using details from before, increasing the end block as needed
a - to toggle boot flag
w - to write partition table back to disk

Re-check that filesystem is OK
e2fsck /dev/sda1

At this point the process fails for me, with the error -

Superblock invalid

Bad magic number in super-block

and from here I have not found a way to recover the filesystem.

I have tried a similar process using parted, and also failed.

Using gdisk (GPT) instead of fdisk

[root@livecd ~]# e2fsck /dev/sda1

e2fsck 1.41.12 (17-May-2010)

/dev/sda1: clean, 18823/65536 files, 209783/261888 blocks

[root@livecd ~]# yum install gdisk

[root@livecd ~]# gdisk /dev/sda

GPT fdisk (gdisk) version 0.8.10

Partition table scan:

  MBR: MBR only

  BSD: not present

  APM: not present

  GPT: not present

***************************************************************

Found invalid GPT and valid MBR; converting MBR to GPT format

in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by

typing 'q' if you don't want to convert your MBR partitions

to GPT format!

***************************************************************

Command (? for help): p

Disk /dev/sda: 3913728 sectors, 1.9 GiB

Logical sector size: 512 bytes

Disk identifier (GUID): F2EA2B62-4D1C-4D0A-8274-24009DC5353D

Partition table holds up to 128 entries

First usable sector is 34, last usable sector is 3913694

Partitions will be aligned on 2048-sector boundaries

Total free space is 1818557 sectors (888.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name

   1            2048         2097151   1023.0 MiB  8300  Linux filesystem

Command (? for help): d

Using 1

Command (? for help): n

Partition number (1-128, default 1): 

First sector (34-3913694, default = 2048) or {+-}size{KMGTP}: 

Last sector (2048-3913694, default = 3913694) or {+-}size{KMGTP}: 1700M

Current type is 'Linux filesystem'

Hex code or GUID (L to show codes, Enter = 8300): 

Changed type of partition to 'Linux filesystem'

Command (? for help): x

Expert command (? for help): a

Using 1

Known attributes are:

0: system partition

1: hide from EFI

2: legacy BIOS bootable

60: read-only

62: hidden

63: do not automount

Attribute value is 0000000000000000. Set fields are:

  No fields set

Toggle which attribute field (0-63, 64 or to exit): 2

Have enabled the 'legacy BIOS bootable' attribute.

Attribute value is 0000000000000004. Set fields are:

2 (legacy BIOS bootable)

Toggle which attribute field (0-63, 64 or to exit): 

Expert command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING

PARTITIONS!!

Do you want to proceed? (Y/N): y

OK; writing new GUID partition table (GPT) to /dev/sda.

The operation has completed successfully.

[root@livecd ~]# e2fsck -f /dev/sda1

e2fsck 1.41.12 (17-May-2010)

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 3A: Optimizing directories

Pass 4: Checking reference counts

Pass 5: Checking group summary information

/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****

/dev/sda1: 18823/65536 files (0.7% non-contiguous), 209783/261888 blocks

[root@livecd ~]# resize2fs /dev/sda1

resize2fs 1.41.12 (17-May-2010)

Resizing the filesystem on /dev/sda1 to 434944 (4k) blocks.

The filesystem on /dev/sda1 is now 434944 blocks long.

[root@livecd ~]# e2fsck /dev/sda1

e2fsck 1.41.12 (17-May-2010)

/dev/sda1: clean, 18823/114688 files, 212932/434944 blocks

All good, now reboot, and see that the image boots successfully.

[root@usbhda ~]# df -h

Filesystem      Size  Used Avail Use% Mounted on

/dev/sda1       1.7G  804M  783M  51% /

tmpfs           947M     0  947M   0% /dev/shm