"CLI APPS"

Here are a list of command line apps that could be useful

Magika

A very fast file type detection.

You can start using Magika by installing it as a Python package: pip install magika

s-tui

The Stress Terminal UI: s-tui

s-tui, monitors CPU temperature, frequency, power and utilization in a graphical way from the terminal.

You can start using s-tui by installing it as a Python package: pip install s-tui

if you have install the stress program, you can activate it within s-tui to monitor the system activities created by stress.

GDU

A fast disk usage analyzer written in Go.

Gdu is intended primarily for SSD disks where it can fully utilize parallel processing.

ps_mem

A utility to accurately report the core memory usage for a program

You can start using ps_mem by installing it as a Python package: pip install ps_mem

"miniPC - OS Test"

Installed Almalinux 9 with no issues. All hardware detected and working. Browsing performance was adequate and YouTube streamed with no issues. I installed the Steam client and then installed Dota 2.

Dota 2 performance was not great, it was playable but there were flickering patches of graphics.

Installed the XFCE version of Manjaro. It is based off Archlinux so most of the packages are of recent releases. Again, no issues with hardware, web browsing or YouTube browsing. However Dota 2 still had the flickering graphics and not very smooth performance.

Installed MX Linux "ahs"" (XFCE). It is based off Debian stable with a 6.6 kernel . It performed well on browsing and video streaming. But there were multiple issues with Dota 2, occasionally it will load with no sound, the game may crash and quit and there was still some flickering graphics.

Installed Fedora Workstation 40. It is using the Gnome Desktop, no issues with web browsing and video streaming. Dota 2 is playable with occasionally no sound issue and crashes. Minimal graphic flickering.

Installed Clear Linux* Project. This Linux distribution had Intel optimization for performance improvement. Web browsing and video streaming was fine. For Dota 2, it will always launch and lockup the system. This happened repeatedly.

Installed Pop!_Os by System76. It is based on Ubuntu 22.04 LTS with various kernel optimization. This version uses the Gnome Desktop. The Cosmic Desktop version (Alpha 3) installed fine but it could not boot to desktop.

Pop!_Os has very good performance and no issues running Dota 2. This is a very nicely integrated Desktop and works very well.

Some hardware details from inxi

Network: Device-1: Intel Wireless 7265 driver: iwlwifi Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 Device-3: Intel Bluetooth wireless interface type: USB driver: btusb

Graphics: Device-1: Intel JasperLake [UHD Graphics] driver: i915 v: kernel Display: x11 server: X.Org v: 1.21.1.4 driver: X: loaded: modesetting unloaded: fbdev,vesa gpu: i915 resolution: 1920x1280~60Hz OpenGL: renderer: Mesa Intel UHD Graphics (JSL) v: 4.6 Mesa 24.0.3-1pop1~1711635559~22.04~7a9f319

CPU: Info: quad core model: Intel Celeron N5105 bits: 64 type: MCP cache: L2: 1.5 MiB Speed (MHz): avg: 2800 min/max: 800/2900 cores: 1: 2800 2: 2800 3: 2800 4: 2800

"miniPC"

I purchased a miniPC from Aliexpress for about S$130 ( shipping included ). The specification is as follows:

• Intel Celeron N5105 11th Gen 2.0GHz / 2.9GHz (boost)
• 7.2 x 7.2 x 4.4 cm
• 204 grams
• 8GB DDR4 LPDDR4 (soldered on, non expandable)
• 128Gb SATA M.2 2242
• 3x USB-A 3.2
• 2x HDMI 2.0
• 1x Type-C (Power only)
• Gigabit LAN RJ45
• 1x 3.5mm Headphone Jack
• Micro SD Card slot (Max 128GB)
• WIFI 5
• BT 4.2
• Windows 11 Pro

Two interesting aspects is the use of USB C for power and the M.2 slot. The USB C port allows the use of any USB C power adapter (at least 45W) or a power bank that supports at least 22.5W charging. The supplied SSD drive was replaced with a M.2 non SATA drive. The M.2 support a NVME drive that perform a read speed of 1.1 GB/s which is double the SATA speeds.

The fan was not too loud at full load however the CPU temp reached 100C.

One of the reasons I wanted a low end miniPC to test was to see how well it performs for basic tasks like web browsing and video streaming. I deliberately chose the most cost effective Intel based system with adequate performance.

I will installing various Linux distributions and will be testing them. I will report my findings.

"rhsecapi"

rhsecapi makes it easy to interface with the Red Hat Security Data API.

From the RPM info in the rhsecapi package:

Leverage Red Hat's Security Data API to find CVEs by various attributes (date, severity, scores, package, IAVA, etc). Retrieve customizable details about found CVEs or about specific CVE ids input on cmdline. Parse arbitrary stdin for CVE ids and generate a customized report, optionally sending it straight to pastebin. Searches are done via a single instantaneous http request and CVE retrieval is parallelized, utilizing multiple threads at once. Python requests is used for all remote communication, so proxy support is baked right in. BASH intelligent tab-completion is supported via optional Python argcomplete module. Python2 tested on RHEL6, RHEL7, & Fedora but since it doesn't integrate with RHN/RHSM/yum/Satellite, it can be used on any internet-connected machine. Feedback, feature requests, and code contributions welcome.

This tool make it easy to make a query regarding a CVE against RH suite of products and check how are they affected.

A simple query on a CVE

$rhsecapi CVE-2024-3094

 [NOTICE ] rhsda: Found 1 CVEs on cmdline
 [NOTICE ] rhsda: Valid Red Hat CVE results retrieved: 1 of 1

 CVE-2024-3094
  SEVERITY : Critical Impact
  DATE     : 2024-03-29
  BUGZILLA : 2272210
  FIX_STATES :
  Not affected: Red Hat Enterprise Linux 6 [xz]
  Not affected: Red Hat Enterprise Linux 7 [xz]
  Not affected: Red Hat Enterprise Linux 8 [xz]
  Not affected: Red Hat Enterprise Linux 9 [xz]
  Not affected: Red Hat JBoss Enterprise Application Platform 8 [xz]

Another query that also shows the relevant RHSA

rhsecapi CVE-2023-4911 [NOTICE ] rhsda: Found 1 CVEs on cmdline [NOTICE ] rhsda: Valid Red Hat CVE results retrieved: 1 of 1

CVE-2023-4911

 SEVERITY : Important Impact
 DATE     : 2023-10-03
 BUGZILLA : 2238352

 FIXED_RELEASES :
  Red Hat Enterprise Linux 8: [glibc-0:2.28-225.el8_8.6] via RHSA-2023:5455 (2023-10-05)
  Red Hat Enterprise Linux 8: [glibc-0:2.28-225.el8_8.6] via RHSA-2023:5455 (2023-10-05)
  Red Hat Enterprise Linux 8.6 Extended Update Support: [glibc-0:2.28-189.6.el8_6] via RHSA-2023:5476 (2023-10-05)
  Red Hat Enterprise Linux 9: [glibc-0:2.34-60.el9_2.7] via RHSA-2023:5453 (2023-10-05)
  Red Hat Enterprise Linux 9: [glibc-0:2.34-60.el9_2.7] via RHSA-2023:5453 (2023-10-05)
  Red Hat Enterprise Linux 9.0 Extended Update Support: [glibc-0:2.34-28.el9_0.4] via RHSA-2023:5454 (2023-10-05)
  Red Hat Virtualization 4 for Red Hat Enterprise Linux 8: [glibc-0:2.28-189.6.el8_6] via RHSA-2023:5476 (2023-10-05)
  Red Hat Virtualization 4 for Red Hat Enterprise Linux 8: [redhat-release-virtualization-host-0:4.5.3-10.el8ev] via RHSA-2024:0033 (2024-01-03)
  Red Hat Virtualization 4 for Red Hat Enterprise Linux 8: [redhat-virtualization-host-0:4.5.3-202312060823_8.6] via RHSA-2024:0033 (2024-01-03)

FIX_STATES :

 Not affected: Red Hat Enterprise Linux 6 [glibc]
 Not affected: Red Hat Enterprise Linux 7 [compat-glibc]
 Not affected: Red Hat Enterprise Linux 7 [glibc]

UPDATE : There is a version that supports python3 used in RHEL8/9. You can get it here

Download-RPM

One problem is that rhsecapi needs python2 so it is problem getting it to run on anything newer than RHEL7. There is an option to run it in a docker container.

This is the method I ended up using to run rhsecapi.

distrobox which used podman to create a Centos 7 container then install the rhsecapi rpm.

[bogus@myhost ~]$ distrobox enter --root centos7

[bogus@centos7 ~]$ rhsecapi -h

usage: rhsecapi [--q-before YYYY-MM-DD] [--q-after YYYY-MM-DD] [--q-bug BZID] [--q-advisory RHSA] [--q-severity IMPACT] [--q-product PRODUCT] [--q-package PKG] [--q-cwe CWEID] [--q-cvss SCORE] [--q-cvss3 SCORE] [--q-empty] [--q-pagesize PAGESZ] [--q-pagenum PAGENUM] [--q-raw RAWQUERY] [-i YYYY-?-NNNN] [-x] [-0] [-f FIELDS | -a | -m] [-p PRODUCT] [-j] [-u] [-w [WIDTH]] [-c] [-l {debug,info,notice,warning}] [-t THREDS] [-P] [-E [DAYS]] [--dryrun] [-h] [--help] [CVE-YYYY-NNNN [CVE-YYYY-NNNN ...]]

Run rhsecapi --help for full help page

VERSION: rhsecapi v1.0.1 last mod 2017/06/27 See http://github.com/ryran/rhsecapi to report bugs or RFEs

"Living with Secure Boot"

Living with Secure Boot

I bought a new laptop Aspire A515-45, AMD 6 core Ryzen 5 5500U with Radeon Graphics, 16Gb DDR4 ram and 512Gb nvme SSD.

It comes preloaded with Windows 11 and therefore secure boot is enabled by default. Installed AlmaLinux 8.6 with minimal issues, just remember to mount /boot/efi to the first partition of the SSD drive. The Almalinux shim is already correctly signed so there were no issues with booting up the system.

Drivers for the wifi, Intel Wi-Fi 6 AX200 and ethernet, Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet were loaded correctly.

However the drivers for the AMD integrated Radeon graphics were quite basic. AMD provides better graphic drivers ( AMDGPU ) obtained from http://repo.radeon.com/amdgpu-install/. RPM packages for RHEL 8.6 are available. Installation also involves the creation of the amdgpu kernel module. As the newly created amdgpu module is unsigned, it was not loaded during bootup. Similarly manual loading will not work due to the secure boot environment.

A mok certificate had been been created which need to be imported before the amdgpu kernel module is permitted to load.

mokutil --import /root/mok.der

Mokutil will require you to provide a temporary password for importing the certificate. Reboot the system and the MOK manager will start automatically.

Information on how the Mok enrollment screens can be found here.

Use to temporary password to complete the importing of the certificate. The amdgpu driver will now loads correctly.

New Issues

I noticed a new problem where upon resumption from standby, the display remains blank. The system is running but there is no display, only a reboot will bring it back.

Apparently this is an issue on AMD CPU concerning standby, only a newer kernel has the fix for this issue. The current kernel is kernel-4.18.0-372.9.1.el8.x86_64.

Recommendation was to use a version 5 kernel. Instead of compiling a kernel, I took a kernel rpm from ELRepo Project. It had current stable kernel version release 5.18.1-1.el8.elrepo.x86_64.

I installed the elrepo kernel and upon reboot, the new kernel fails to load. This was expected as the secure boot does not have the public certificate for elrepo. I turned off secure boot setting in the BIOS and the 5.18 kernel booted up just fine. The standby issue is resolved.

Apparently the elrepo kernel and modules are unsigned, therefore this is no public certificate to import. In order to re-enable secure boot and permit the loading of the elrepo kernel, I would need to create my own set of keys/certs and sign the elrepo kernel and kernel modules.

I used the information at this link to get the elrepo kernel/modules signed.

How to sign things for secure boot

I needed to build these packages for the sbsign utility

gnu-efi-3.0.11-6.fc34.src.rpm

sbsigntools-0.9.4-4.fc34.src.rpm

sbsign is used to sign the kernel binary. I found kmodsign in my system as provided by the snap package. It was used to sign the kernel modules.

Alternately you could use sign-file to sign the modules. It comes from the kernel-devel rpm. See link below for information on this alternate kernel module signing process.

signing-kernel-modules-for-secure-boot

For the kernel module signing process, you will need to uncompress the kernel modules to .ko, sign them and compress them back to ko.xz.

After importing the self created certificate with the Mok utility and re-enabling secure boot. The elrepo kernel/modules were able to load successfully.

"Secure Boot"

What's up with Secure Boot

Secure boot was implemented in the release of Windows 8 in 2012. Microsoft introduced digitally signed kernel files for Windows PE, Windows RT, Windows 8, and Windows Server 2012.

With the release of Windows 11 in 2021, Secure Boot became a mandatory requirement in PC systems preloaded with Windows 11.

Secure Boot is one feature of the Unified Extensible Firmware Interface (UEFI) 2.3.1 specification (Errata C). The feature defines an entirely new interface between operating system and firmware/BIOS.

When enabled and fully configured, Secure Boot helps a computer resist attacks and infection from malware. Secure Boot detects tampering with boot loaders, key operating system files, and unauthorized option ROMs by validating their digital signatures.

After Secure Boot is enabled and configured, only software or firmware signed with approved keys are allowed to execute. Conversely, software signed with blacklisted keys are disallowed from executing.

Secure Boot is split into several pieces and stages.

db, the “signature database.” Entries here (typically certificates) determine what EFI executables are allowed to run on the device. So this is an “allow” list.

dbx, the “forbidden signatures database.” Entries here are typically SHA256 hashes of specific UEFI binaries, i.e. those things that were signed by a certificate in the “db” list but later found to be bad (e.g. having a security vulnerability that compromises the firmware). So this is a “block” list.

kek, the “key exchange key.” This specifies who is able to update the signature database (the “db” and “dbx” keys). Interestingly, any UEFI binaries signed by the “kek” key can also boot on the device. Microsoft's certificate will be stored here.

pk, the “platform key.” The “pk” variable contains a single certificate that controls access to the “kek” and “db” variables. If this value is cleared, it effectively turns off Secure Boot (putting the device in setup mode). For example, if the manufacturer of the hardware is Dell, then their certificate will be stored here.

For Linux systems, a special boot loader Shim created by Matthew Garrett is used to integrate with the Secure Boot setup. It manages its own certificates. Ubuntu, Red Hat, SUSE, and Debian generate their own versions of Shim that include certificates issued by their companies.

Verisign/Symantec for a fee will digitally signs the Shim bootloader on behalf of Microsoft that the UEFI firmware will permit the loading of the Shim. Once Shim is loaded, it operates independently of the Microsoft verification chain. Shim has built-in certificate management that lets the owner of the computer store certificates called machine owner keys (MOKs).

Shim lets large distributors such as Ubuntu, SUSE, and Red Hat win back control of hardware. Using the Distribution certificate stored in Shim, The Distribution sign the GRUB 2 bootloader. The firmware boots Shim, Shim boots GRUB 2, and GRUB 2 boots the operating system.

A Machine Owner Key (MOK) is a type of user generated key that is used to “sign," or authenticate as trustworthy, an Extensible Firmware Interface (EFI) binary. MOK gives you ownership of the boot process by allowing you to run locally-compiled kernels, kernel modules or boot loaders not delivered with the Linux distribution. This means that to use custom kernel or kernel modules, A public MOK needs to be enrolled and the private MOK is used to sign the custom kernel and kernel modules.

"Remote Desktops"

Having to conduct remote training, I had used a combination of ssh local/remote forwarding to tunnel vnc access from a student's system to a computer in my training room.

A server in the cloud is used in the middle for the ssh tunneling. A ssh local forwarding from the student's PC connects to the server. A ssh remote forwarding is made from the class system to the server. The vnc server port on the class system will be tunneled to a port on the student's windows PC. The student uses a vnc client to connect to the localhost port and will then be connected to the classroom vnc server.

It works however there was a certain amount of latency.

I have evaluated several other solutions and arrived at 2 alternatives which are free to implement and have very good performance.

DWSERVICE

DWSERVICE is an open source project which offers a service to allow access to remote systems (Windows, Mac, Linux, Raspberry...) using a standard web browser - no client-side download required!

DWSERVICE provides its own agent that runs on the target system ( to be controlled ). You will need to registered a account on their website to use the service. You can control multiple configured desktops. The agent setup requires a generated code by the agent to be entered on the desktop service configuration in your account page.

The documentation provided is very comprehensive. The remote desktop performance was very good for the free option. Free account provides 6 Mbps maximum bandwidth. Paid subscriptions gives higher bandwidth options for scenarios where many desktops are concurrently being used.

Additional features include a terminal access to the target system on the website and performance monitoring. One of the most unique feature is a sharing option, It will generate a password protected link which will allow any recipient of the link to get the remote desktop of the target system.

While DWSERVICE looks like a very good option, one caveat is that it is third party service so you never have full control of the entire process.

noVNC

noVNC is a open source browser based VNC client implemented using HTML5 technologies (Web Sockets, Canvas) with encryption (wss://) support. It was created in 2010 and used in many projects like openstack. List of companies and projects using noVNC.

noVNC supports all modern browsers including mobile (iOS, Android). noVNC follows the standard VNC protocol, but unlike other VNC clients it does require WebSockets support. Many servers include support (e.g. x11vnc/libvncserver, QEMU, and MobileVNC), but for the others you need to use a WebSockets to TCP socket proxy. noVNC has a sister project websockify that provides a simple such proxy.

The implement approach is to run the noVNC software on the webserver, It will be configured to access a vnc server by default. noVNC listens on a port, using a browser, navigate to this website at this port will serve up the noVNC page with a button to connect. Click on it to bring up the remote desktop.

Implementation example:

You can install noVNC as a snap app on the webserver.

novnc --listen 8086 --vnc 127.0.0.1:5901

noVNC listens on 8086 and connects to vncserver on 127.0.0.1, port 5901.

However if you want the browser to have a SSL connection to noVNC then the noVNC options will be like this.

novnc --cert /etc/letsencrypt/live/www.example.org/cert.pem --key /etc/letsencrypt/live/www.example.org/privkey.pem --listen 8086 --vnc 127.0.0.1:5901 --ssl-only

www.example.org is the website and the letsencrypt certs are used in this example.

on the target vnc server system

ssh -R 5901:localhost:5901 novnc@www.example.org

This create the ssh tunnel that links port 5901 on the target system to port 5901 on the webserver.

on another terminal

x11vnc -usepw -forever -ncache_cr -bg

This launches a vnc server listening on 5901. X11vnc is used as it support websockets which noVNC connects directly with no need for a websocket proxy. Remember to set a password on the vnc server.

Performance is very good, Using a browser as a client makes access convenient.

"TCP_WRAPPERS"

In ALMALinux/Centos/RHEL 8, tcp_wrappers support was removed from the openssh daemon. This was already done sometime back in Fedora 28 release. Reasons given were as follows:

This was very useful 20 years ago, when there were no firewalls in Linux. This is not the case for today and connection filtering should be done in network level or completely in application scope if it makes sense.

While firewall rules can provide similar functionality but tcp_wrappers is still handy in some situations.

TCP Wrappers (also known as tcp_wrappers) is a host-based networking ACL system, used to filter network access to Internet Protocol servers on (Unix-like) operating systems such as Linux or BSD. It allows host or subnetwork IP addresses, names and/or ident query replies, to be used as tokens on which to filter for access control purposes. Let's do a bit of history first on the origins of tcp_wrappers.

The story begins in 1990 at Eindhoven University of Technology where Wietse Venama was administrator of the computer system network. Wietse is also the creator of the Postfix SMTP server. The university system was coming under increasingly heavy attacks from a Dutch computer cracker who was consistently able to gain root privilege. The cracker was skilled at typing the following command sequence:

rm -rf /

One night, Wietse noticed the cracker was watching him over the network, making contact with the finger network service. Since finger does not require a password, he was finally able to explain why much of the crackers activities had gone unnoticed. Wietse’s first reaction was to shutdown the finger network service. Instead, he decided it would prove more beneficial to maintain the service and determine where the finger requests were coming from. The solution he found was to make a swap by moving the vendor provided network server programs to another location, and install a trivial (TCP Wrapper) program in their place. Whenever a connection was made, the trivial program would just record the name of the remote host and then run the original network server program. The first TCP Wrapper version was just a few lines of code that Wietse carefully copied from an old network daemon source. Because it did not exchange any information with the client or server processes, the same TCP Wrapper version could be used for many types of network services. He made several improvement to the software and used to monitor the cracker activities. However the cracker was never caught. He maintained it until 1995, and on June 1, 2001, released it under its own BSD-style license.

The following attributes of TCP Wrappers are of prime importance:

• Wrappers can be installed without any changes to existing software, or to existing configuration files.
• The wrapper programs have no interaction with the client user.
• The wrappers have no interaction with the server application.
• Once the wrappers have established interaction between client and server, the wrapper disappears. Consequently, there is no overhead on either end.

In the previous version of Centos/RHEL before release 8, the openssh daemon, sshd had the libwrap library compiled in. This means the tcp_wrapper feature was supported and it worked in the following manner.

tcp_wrapper looks at the content of two files to determine access to network services:

/etc/hosts.allow

/etc/hosts.deny

rules in /etc/hosts.allow is processed first.

If you want to explicitly allow localhost full access and block 192.178.0.114 from accessing sshd, the contents of the two files are as follows

/etc/hosts.allow ALL: 127.0.0.0/8

/etc/hosts.deny sshd: 192.168.0.114

sshd because of the libwrap library will honor the hosts.deny entry and refuse ssh connection from the host 192.168.0.114. Any modification to the files will take immediate effect.

I have been using tcp_wrapper to block ssh brute force attacks. A background program watches the /var/log/secure for failed attempts to login via ssh. After 3 failed tries, the IP address of the attacker is entered into /etc/hosts.deny file and that attacking host is blocked instantly.

While this can also be done by creating a firewall rule to DROP/REJECT connection from this attacker. I find the tcp_wrapper approach to be simpler and I have a list of the offending IPs in one file.

This approached had work very well for many years until Centos release 8. The openssh no longer has the libwrap library. So I used Fail2Ban to block ssh brute force attacks instead. It will block the attacking IPs by creating firewall rules via firewalld.

Recently I wanted to try to find a way to use tcp_wrapper like mechanism to block ssh brute force attacks. After review some options I reread this link and it provided a way to incorporate tcp_wrapper support to sshd. In fact, the methodology is very similar to the approach used in the 1990s when Wietse implement tcp_wrappers.

The implementation is as follows:

Install tcp_wrappers

yum install tcp_wrappers

cd /etc/systemd/system/

cp /usr/lib/systemd/system/sshd@.service .

edit sshd@.service

CHANGE THIS LINE ExecStart=-/usr/sbin/sshd -i $OPTIONS $CRYPTO_POLICY

TO ExecStart=@-/usr/sbin/tcpd /usr/sbin/sshd -i $OPTIONS $CRYPTO_POLICY

IF SELINUX is enforced, this seboolean needs to be turn on

setsebool ssh_use_tcpd on getsebool ssh_use_tcpd ssh_use_tcpd --> on

Stop the current ssh service and start the sshd socket systemctl stop sshd; systemctl start sshd.socket

To make it permanent remember to disable sshd.service and enable sshd.socket

the tcpd program will checks on the /etc/hosts.allow and /etc/hosts.deny (create them first) files before running the sshd program. Essentially the same tcp_wrapper functionality is back in place. I can now run my ssh brute force blocking program again.

"Memory Test"

I had encountered scenarios when I had a system lockup and I needed to identify, if it was a software or hardware issue. Most of the time it is due to some hardware issue, maybe due to insufficient cooling or memory problems.

First thing to do is to boot up a OS live CD or the system rescue ISO. System rescue ISO is a good choice as it will bring a full desktop you can then run some apps to bring on the system lockup. The idea is to run software that is not from your boot drive to determine if software is the cause of the problem. If it runs well then there may be software or data corruption issues with your OS drive. However if the same system lockup is observed then it time to focus on the hardware.

To do full memory testing, you would need to bootup a environment with the test software to rigorous run different test patterns on the full bank of memory multiple time. Here are some software to do this

memtest86 is a memory test software program designed to test and stress test an x86 architecture computer's random-access memory (RAM) for errors, by writing test patterns to most memory addresses, reading back the data, and comparing for errors. Each tries to verify that the RAM will accept and correctly retain arbitrary patterns of data written to it, that there are no errors where different bits of memory interact, and that there are no conflicts between memory addresses. It was developed by Chris Brady in 1994. In February 2013, the original MemTest86 was sold to PassMark. Currently there is a commercial version and a free version. Both will support UEFI booting but only from a usb drive image.

memtest86+ is a fork of memtest86 released under the GNU General Public License (GPL) in 2004. The most recent update is on 4th Dec 2020. It has a ISO release but does not support UEFI boot.

pcmemtest pcmemtest is a fork and rewrite of memtest86+, which in turn was a fork of memtest86. The purpose of the rewrite was to: - make the code more readable and easier to maintain - make the code 64-bit clean and support UEFI boot - fix failures seen when building with newer versions of GCC

It is based on the 4th Dec 2020 v5.01 release of memtest86+. You would have to get the source code and built the binaries and create the ISO file. It has all the build scripts and Makefiles. The only problem I faced in the build process was a syntax error in the pcmemtest-1.4/build64/Makefile

lines 103 and 107 had the syntax problem $(eval SIZES=$(shell size -G -d memtest_shared | grep memtest_shared))

change it to remove the -G option $(eval SIZES=$(shell size -d memtest_shared | grep memtest_shared))

the build process completed with no problems after the change and just one more step ( make iso ) to create the ISO file. Now I have a memory test ISO that support UEFI boot.

You can download it here

memtest.iso

In the past, I had used memtest86 to verify faulty dimm modules. It was also useful to boot the ISO on the PC shop system to show the memory failure to the shop owner to convince him to give me a replacement memory module.

"Multiboot USB - Boot any ISO file in one USB drive"

In past, I would make a bootable usb drive from the archlinux ISO for installation purposes and forget which I put it. On one occasion, I had a boot issue and needed to "rescue" the archlinux. Because I could not find the archlinux usb drive, I had to download the ISO and make another boot device.

This week I heard about a software tool called Ventoy from the Late Night Linux podcast. It will allow multiple ISO to reside in one usb drive and it will create a menu list upon boot for the user to choose the specific ISO to boot. It supports both Windows and Linux environments and the default filesystem it uses for the storage partition in the usb is the exFAT filesystem. Of course you can reformat this storage partition to any other linux file system of your choice. You just copy into the storage partition the ISOs and boot the usb drive to use any one of them.

One caveat is that only ISOs that support UEFI boot can be used. For example, this Ultimate Boot CD iso did not boot as it did not support UEFI boot.

Use a USB 3.0 usb drive for more tolerable boot speed and the appropriate size for all the ISOs you want to put in it.

Here is my list of ISOs for OS rescue, system test, partition sizing, disk cloning and general troubleshooting.

• Almalinux 8.4 RHEL 8.4 clone
• Centos 7 RHEL 7 clone
• Archlinux A very very up to date linux distribution
• Rescatux is a Debian-based live distribution featuring a graphical wizard for rescuing broken GNU/Linux and Windows installations and boot loaders.
• SystemRescue Archlinux based rescue toolkit.
• Gparted Manage disk partitions ( create,delete, resize, copy, and move partitions without data loss)
• Clonezilla is a partition and disk imaging/cloning program similar to True Image® or Norton Ghost®. It helps you to do system deployment, bare metal backup and recovery.
• PCmemtest memory tester is based on a fork and rewrite of Memtest86+