there is no official linux/arm64 quay image at the moment

Yes, quay is being built for linux/ppc64le in addition to a «default» linux/amd64 one.

ok, solution

I've started building a multiplatform quay docker image that supports both linux/amd64 and linux/arm64. Nothing custom but just an image. This https://do.cr.tokarch.uk/ runs natively on arm64 now.

So if you need one, pull it:

docker pull ghcr.io/mainnika/quay:v3.8.0

This is a place where builds are happening: https://github.com/mainnika/quay-docker/pkgs/container/quay.

pre

RedHat provides several ISO images that let you install a system. They are DD compatible and one can flash an ISO into USB drive by using either DD or Fedora Media Writer.

If you are lucky enough you may boot this USB in a BIOS-legacy mode, but not in the EFI mode. The installation also continues in BIOS-legacy and doesn't create any EFI-compatible partitions. No secure boot at all.

For those who care about UEFI in their system there are no structured information on RedHat docs.

see into an image

An official ISO has a both isolinux bootloader (bios-mode) and grub (efi-mode). The latter one disappear when you DD the image to USB drive. It may be just because of some misconfiguration during the ISO creating process. I tried to repack an ISO but had no luck about EFI mode.

efi-mode easy way

EFI boot was desinged to be very simple. There are no hidden magic stuff (almost) behind the bootloader. EFI-enabled partitions is just a VFAT-formatted partition with a custom PART-GUID. There are some limitations about the size and some others between different platforms, but let's keep it simple for now.
EFI partitions has type code «EF00» and PART-GUID «C12A7328-F81F-11D2-BA4B-00A0C93EC93B».

GPT fdisk (gdisk) version 1.0.9

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk disk.raw: 3104768 sectors, 1.5 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 2A2619EB-3FA6-4C34-A716-1DCA94AD43B7
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 3104734
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         3102719   1.5 GiB     EF00  EFI system partition

Command (? for help): x

Expert command (? for help): i
Using 1
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI system partition)
Partition unique GUID: 2A1143B9-AFE9-48CE-8B47-21535F031770
First sector: 2048 (at 1024.0 KiB)
Last sector: 3102719 (at 1.5 GiB)
Partition size: 3100672 sectors (1.5 GiB)
Attribute flags: 0000000000000000
Partition name: 'EFI system partition'

gdisk util makes everything simple. To prepare an EFI-compatible partition you need to set the type to «EF00» during the creating process, then PART-GUID will be filled automatically:

Command (? for help): n
Partition number (1-128, default 1):
First sector (34-3104734, default = 2048) or {+-}size{KMGTP}:
Last sector (2048-3104734, default = 3102719) or {+-}size{KMGTP}:
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300): ef00
Changed type of partition to 'EFI system partition'

almost it

Let's mount everything we need to make it work. First, locate an RedHat installation ISO, e.g. «rhel-baseos-9.0-x86_64-boot.iso». Then locate a newly created EFI partition, e.g. «/dev/sdc1».

$ realpath rhel-baseos-9.0-x86_64-boot.iso
/home/mainnika/rhel-baseos-9.0-x86_64-boot.iso
$ stat /dev/sdc1
  File: /dev/sdc1

EFI partition needs to be formatted first, please notice a «label» argument «-n RHEL9». This is necessary for the bootloader to find a boot root partition by label.

# sudo mkfs.fat -F 32 -n RHEL9 /dev/sdc1
mkfs.fat 4.2 (2021-01-31)

Now mount everything. Be aware of ephemeral directory I use in exmaples, do not copy them blindly.

# mktemp -d --suffix=-iso-mount
/tmp/tmp.SR9TpfSV5U-iso-mount

# mktemp -d --suffix=-efi-mount
/tmp/tmp.A7IJSAwhHy-efi-mount

# mount -o loop /home/mainnika/rhel-baseos-9.0-x86_64-boot.iso /tmp/tmp.SR9TpfSV5U-iso-mount
mount: /tmp/tmp.SR9TpfSV5U-iso-mount: WARNING: source write-protected, mounted read-only.

# mount /dev/sdc1 /tmp/tmp.A7IJSAwhHy-efi-mount

# mount
/home/mainnika/rhel-baseos-9.0-x86_64-boot.iso on /tmp/tmp.SR9TpfSV5U-iso-mount type iso9660
/dev/sdc1 on /tmp/tmp.A7IJSAwhHy-efi-mount type vfat

Prepare/copy EFI bootloader. The EFI bootloader is just a «EFI» folder located in root.

# cp -r /tmp/tmp.SR9TpfSV5U-iso-mount/EFI /tmp/tmp.A7IJSAwhHy-efi-mount

For some weird reason there is an invalid bootloader in EFI folder, «BOOTX64.EFI». Let's replace it with grub which is right there as well and remove some of leftovers.

# mv /tmp/tmp.A7IJSAwhHy-efi-mount/EFI/BOOT/grubx64.efi /tmp/tmp.A7IJSAwhHy-efi-mount/EFI/BOOT/BOOTX64.EFI
# rm /tmp/tmp.A7IJSAwhHy-efi-mount/EFI/BOOT/mmx64.efi

The most important step is to change a «grub.cfg» and let him use right paths and kernel. You might see here the «label» we've used during formatting.

# sed -i 's/RHEL-9-0-0-BaseOS-x86_64/RHEL9/g' /tmp/tmp.A7IJSAwhHy-efi-mount/EFI/BOOT/grub.cfg
# sed -i 's/images\/pxeboot/isolinux/g' /tmp/tmp.A7IJSAwhHy-efi-mount/EFI/BOOT/grub.cfg

The last step is to copy installation files from ISO media to EFI partition.

# cp -r /tmp/tmp.SR9TpfSV5U-iso-mount/{images,isolinux} /tmp/tmp.A7IJSAwhHy-efi-mount

that's it

Examine a filesystem tree for the EFI partition.

# tree /tmp/tmp.A7IJSAwhHy-efi-mount/
/tmp/tmp.A7IJSAwhHy-efi-mount/
├── EFI
│   └── BOOT
│       ├── BOOTX64.EFI
│       ├── fonts
│       │   └── unicode.pf2
│       └── grub.cfg
├── images
│   ├── efiboot.img
│   └── install.img
└── isolinux
    ├── boot.cat
    ├── boot.msg
    ├── grub.conf
    ├── initrd.img
    ├── isolinux.bin
    ├── isolinux.cfg
    ├── ldlinux.c32
    ├── libcom32.c32
    ├── libutil.c32
    ├── memtest
    ├── splash.png
    ├── vesamenu.c32
    └── vmlinuz

Unmount everything and eject USB drive,

# umount /tmp/tmp.SR9TpfSV5U-iso-mount /tmp/tmp.A7IJSAwhHy-efi-mount
# sync
# eject /dev/sdc

then boot it!

Nowadays code streaming become more popular. There is even Twitch channel with software developing.

Usually for the streaming people use OBS software. Basically it allows you to combine several video/audio/etc sources into the one scene that is being streamed to the service.

Discord is another super popular app. The app let people be connected inside some community. For example the group of graphic illustrators can share their works and discuss in voice chats.

Discord live streaming is not very popular but sometimes can be increadibly useful. But Discord doesn't support custom streaming at the moment and the only choice you have is to stream window or entire screen.

a couple of tiny tricks

I use OBS Studio from the website https://obsproject.com. It is free and open-source!

Let's take a look!

image capture

First I move all controls into floating windows by using «windowed» button at the left of the control:

Now all your controls are separated and floating under the main window. You may want to adust its properties and size to fill the window with the scene:

That's all! The main OBS window can be a source for the discord live stream:

Go live!

sound

Using window source Discord takes sound from the window as well.
By enabling sound monitoring we make the window emit sound that will be captured.
The tricky part here is to avoid loops in the sound. But this part is hardly depends on your requirements and hardware.

As the simple solution to capture everything I can hardly recommend VB-Cable app that is basically a pipe source-sink. See https://vb-audio.com/Cable/ for details.

TL;DR: root is required, use exfat-fuse, patch vold, enjoy.

intro

exFAT was developed by Microsoft in 2006 and most of the time it was proprietary. On the other hand, there were exFAT-fuse implementations for linux by samsung and others. Samsung driver was also closed, but due to conflict with the community about GPL licenses they were forced to publish (keep published) sources.

Despite the fact that the filesystem was developed mostly for flash-memory, there are no restrictions to use it on HDD.

For now exFAT is the best filesystem if you use your disk with different OS. Except Android.

Android devices can use USB devices by connecting them using the OTG-USB adapter. It looks like this:

the problem

Android until «Pie» doesn't have native support for the exFAT drives. Even if exFAT driver is included in the kernel. The only possible option is Vfat.

Vfat is «almost» perfect, but has its own limitations. The biggest one is the file size limit. You can't have files bigger than 4GB on vfat partition. That is pretty sad when you want to save 30GB mp4 video file to the portable HDD.

And there is another issue with exFAT: if you want to play this 30GB mp4 video file from the portable HDD using android tv stick! Android can't mount exFAT natively.

On your device you can use up to two methods to mount exFAT:
- using fuse exFAT;
- using linux kernel module (v5.7 and above).

I'll describe both, but the former is for manual process and the latter is as the vold patch.

mount it manually

For this method we assume we have exfat-fuse tools.
Before you start, ensure your exFAT helpers exist by using the ADB shell:

android-device$ which mkfs.exfat fsck.exfat mount.exfat
/system/bin/mkfs.exfat
/system/bin/fsck.exfat
/system/bin/mount.exfat

Then you can mount them by using mount.exfat tool. This tool uses fuse driver and you don't need exFAT support in your kernel:

android-device# t=`mktemp -d`; mount.exfat /dev/block/sdxX $t && echo $t
FUSE exfat 1.2.7
/data/local/tmp/tmp.PRpALtvJ7f

clever solution

To make this persistent and automatic it is possible to easily patch Vold.
Simply, Vold is the daemon that automatically mount them to make it available through GUI apps.

Here I describe the process as if I have exFAT kernel support.
I will do it according to my own changes in the repository https://github.com/mainnika/vold-exfat.

You can follow steps using this commit diff https://github.com/mainnika/vold-exfat/commit/ca9e34ec92425b416f3f250e2b7d7122782c3f23.

As the easiest way I'll just change vfat mount code to use exfat.

First, I'll remove some unnecessary stuff to simplify the whole process:
- filesystem check;
- disk format.

Then, change fstype for the mount call:

@@ -140,117 +75,16 @@ int Fat::doMount(const char *fsPath, const char *mountPoint,
     }
 
     sprintf(mountData,
-            "utf8,uid=%d,gid=%d,fmask=%o,dmask=%o,shortname=mixed",
+            "utf8,uid=%d,gid=%d,fmask=%o,dmask=%o",
             ownerUid, ownerGid, permMask, permMask);
 
-    rc = mount(fsPath, mountPoint, "vfat", flags, mountData);
+    rc = mount(fsPath, mountPoint, "exfat", flags, mountData);

Build the vold normally and then replace your binary in the system (do not forget about backup!):

android-device# cp /system/bin/vold /system/bin/vold.orig
android-device# cat /sdcard/vold.exfat-patched > /system/bin/vold
android-device# reboot

After the reboot you should see your exFAT disk in the android GUI.

ready-to-use binaries

this is just for Amazon FireTV stick only!

Since I did this work for the FireOS 5.2.7.2 (Amazon FireTV stick), I've prepared some binaries for this system, see the release https://github.com/mainnika/vold-exfat/releases/tag/lollipop-armv7l.
Just replace your vold in the stick.

If you have AOSP-like system you can use this repository https://github.com/null4n/vold-posix to fetch fuse binaries. The repository containes also vold binary for Android 8.1 (aarch64).

Also, feel free to compile your own vold and exfat binaries:
- https://github.com/null4n/system_vold
- https://github.com/LineageOS/android_external_exfat