After installing Fotorama plugin in Piwigo provided that there is Embedded Video installed, the following error message will be shown while clicking the slideshow button on top of the video pages: Notice: Undefined index: selected_derivative in /…/plugins/Fotorama/main.inc.php on line 54 Fatal error: Call to a member function get_type() on a non-object in /…/plugins/Fotorama/main.inc.php on line 54

Solution:

Maybe it is just a workaround for the issue. However, it works so far. Comment out the statements causing the error in main.inc.php of Fotorama plugin as below:

$type = $current['selected_derivative']->get_type();
    $defined = ImageStdParams::get_defined_type_map();
    if (!isset($defined[$type]))
    {
      $type = pwg_get_session_var('picture_deriv', $conf['derivative_default_size']);
    }

and rewrite the following line:

$type = pwg_get_session_var('picture_deriv', $conf['derivative_default_size']);

Config:

• Piwigo          2.6.2
• Embedded plugin: 2.6.2
• Fotorama plugin:   2.6.h

The post Piwigo Fotorama Conflict w/ Embedded Video appeared first on LarryLai.

After installing Fotorama plugin in Piwigo provided that there is Embedded Video installed, the following error message will be shown while clicking the slideshow button on top of the video pages: Notice: Undefined index: selected_derivative in /…/plugins/Fotorama/main.inc.php on line 54 Fatal error: Call to a member function get_type() on a non-object in /…/plugins/Fotorama/main.inc.php on line 54

Solution:

Maybe it is just a workaround for the issue. However, it works so far. Comment out the statements causing the error in main.inc.php of Fotorama plugin as below:

$type = $current['selected_derivative']->get_type();
    $defined = ImageStdParams::get_defined_type_map();
    if (!isset($defined[$type]))
    {
      $type = pwg_get_session_var('picture_deriv', $conf['derivative_default_size']);
    }

and rewrite the following line:

$type = pwg_get_session_var('picture_deriv', $conf['derivative_default_size']);

Config:

• Piwigo          2.6.2
• Embedded plugin: 2.6.2
• Fotorama plugin:   2.6.h

The post Piwigo Fotorama Conflict w/ Embedded Video appeared first on LarryLai.

When I tried to spin up my CentOS 7 guest—running on kernel 3.10 within VirtualBox 6.0.10—the boot process didn’t behave as expected. Instead of reaching a stable login prompt, the system stalled mid-way through the startup sequence.

Upon inspecting the console logs, I noticed two critical error messages that pointed to exactly where things were breaking down: [FAILED] Failed to start Virtual Machine and Container Registration Service and [FAILED] Failed to start Login Service.

At this stage, I wasn’t entirely certain of the smoking gun. It looked like a potential issue with the SELinux configuration—specifically how it was interacting with the system’s boot state—but I also had to consider that this might be a known bug within VirtualBox 6 itself. Regardless of the exact culprit, these two service failures were preventing me from accessing my environment.

Prerequisites for Troubleshooting

Before diving into the fix, I made sure I had a few things in place—this approach means editing system files during boot, so a little preparation goes a long way:

• Access to the VirtualBox console. You need to be at the keyboard when the VM first powers on, ready to catch the GRUB menu before it hands off to the kernel. (My environment was a CentOS 7 guest on VirtualBox 6.0.10.)
• A snapshot or backup first. Since we’ll be remounting the filesystem and editing /etc/selinux/config, take a VirtualBox snapshot beforehand. If anything goes sideways, you can roll straight back.
• Comfort with a terminal editor. The fix happens in vi inside a minimal rescue shell, so basic vi navigation (insert, save, quit) is all you need.
• Knowing your boot entry. If GRUB lists multiple kernels, be ready to identify your primary CentOS entry—that’s the one we’ll edit.

Step 1: Revealing the Hidden Boot Errors (Exit Quiet Boot)

When I first encountered the boot failure, I was met with nothing but a static progress bar. By default, CentOS 7 uses a “quiet boot” setting that hides the technical minutiae of the startup process behind a clean splash screen. While this looks professional, it is incredibly unhelpful when you are troubleshooting a system that refuses to start.

To see what was actually happening under the hood, I needed to reveal the full system logs. As soon as the boot sequence begins, pressing the Esc key interrupts the quiet mode and displays the detailed text-based output. By doing this, I was finally able to see the specific [FAILED] messages—such as those regarding the Virtual Machine and Container Registration Service—that provided the first real clue into the system’s instability.

Step 2: Booting CentOS into Rescue Mode via GRUB

Once I realized the standard boot process was hitting a wall, my next move was to use the GRUB menu to bypass the failing services and drop straight into a command-line environment. It’s important to note that GRUB itself isn’t corrupt—it is still functioning perfectly as our entry point—we just need to change how it hands off control to the kernel.

Here is exactly how I navigated through the bootloader to enter rescue mode:

1. Select the Entry: When the VirtualBox window displays the GRUB boot menu, use your arrow keys to highlight your primary CentOS boot entry.
2. Edit the Boot Parameters: Press the e key on your keyboard. This opens an editor that allows you to modify the boot instructions before they are actually executed by the system.
3. Modify the Linux Line: Scroll down through the text until you find the line starting with linux16. This line contains the kernel-specific arguments and parameters. Navigate to the very end of this line, add a space, and append: systemd.unit=rescue.target
4. Execute the Boot: Once the parameter is added, press Ctrl+X (or F10) to boot with these new settings.

This process forces CentOS to skip the standard multi-user startup sequence—where the failing services are triggered—and instead boots you directly into a minimal, single-user rescue environment where we can address the SELinux configuration issues manually.

Step 3: Fixing the SELinux Configuration (the Root Cause)

Once I was settled into the rescue shell, my first task wasn’t editing files—it was making sure I could actually save them. Depending on how the system lands in rescue mode, the root filesystem can come up read-only, so to be safe I remounted it writable before touching anything:

mount -o remount,rw /

With write access secured, I turned my attention to the primary suspect: the SELinux configuration. SELinux sits deep in the boot path, and when its policy gets tangled up with the system’s state—as it can in a quirky VirtualBox guest—it’s capable of quietly stalling the very services CentOS needs to finish starting.

I opened the configuration file using vi:

vi /etc/selinux/config

Inside the file, I located the line starting with SELINUX=. Here is the detail that made this issue so hard to pin down: it wasn’t set to enforcing, as you might assume. It was already on permissive—a mode that is only supposed to log policy violations, not block anything. That’s precisely why SELinux is such an easy culprit to overlook here; on paper it shouldn’t have been able to stop those services at all. Yet they still refused to start. So rather than half-measures, I turned SELinux off completely:

SELINUX=disabled

Setting the mode to disabled takes SELinux fully out of the boot path on the next startup, which is what finally cleared the conflict stalling the Registration and Login services. I saved the file and exited the editor. (If you’d prefer to keep SELinux active for security, you can switch it back to enforcing once you’ve confirmed the VM boots reliably—but for getting a stuck machine running again, disabling it is the fastest, most decisive fix.)

Step 4: Verifying the Fix and Ruling Out the VirtualBox 6 Bug

After saving my changes in rescue mode, I performed a standard reboot to see if the system would finally reach the login prompt. This time, the boot sequence progressed smoothly; those alarming [FAILED] messages that had been stalling the startup process were nowhere to be seen.

To double-check my work, I ran getenforce once the system was up. The output came back Disabled, confirming SELinux was fully switched off and no longer interfering with the services that had been failing to initialize.

While the VM is now stable, I kept one caveat in mind: the environment involves VirtualBox 6.0.10. There have been documented instances of specific service failures linked to bugs within this particular version of the hypervisor. While correcting the SELinux configuration solved my immediate problem, if you encounter similar boot issues on a different machine even after following these steps, it is worth considering that the issue might reside in the VirtualBox software itself rather than your CentOS configuration.

The post How to Fix CentOS VM Client Boot Failure: A Step-by-Step Troubleshooting Guide appeared first on LarryLai.

When I tried to spin up my CentOS 7 guest—running on kernel 3.10 within VirtualBox 6.0.10—the boot process didn’t behave as expected. Instead of reaching a stable login prompt, the system stalled mid-way through the startup sequence.

Upon inspecting the console logs, I noticed two critical error messages that pointed to exactly where things were breaking down: [FAILED] Failed to start Virtual Machine and Container Registration Service and [FAILED] Failed to start Login Service.

At this stage, I wasn’t entirely certain of the smoking gun. It looked like a potential issue with the SELinux configuration—specifically how it was interacting with the system’s boot state—but I also had to consider that this might be a known bug within VirtualBox 6 itself. Regardless of the exact culprit, these two service failures were preventing me from accessing my environment.

Prerequisites for Troubleshooting

Before diving into the fix, I made sure I had a few things in place—this approach means editing system files during boot, so a little preparation goes a long way:

• Access to the VirtualBox console. You need to be at the keyboard when the VM first powers on, ready to catch the GRUB menu before it hands off to the kernel. (My environment was a CentOS 7 guest on VirtualBox 6.0.10.)
• A snapshot or backup first. Since we’ll be remounting the filesystem and editing /etc/selinux/config, take a VirtualBox snapshot beforehand. If anything goes sideways, you can roll straight back.
• Comfort with a terminal editor. The fix happens in vi inside a minimal rescue shell, so basic vi navigation (insert, save, quit) is all you need.
• Knowing your boot entry. If GRUB lists multiple kernels, be ready to identify your primary CentOS entry—that’s the one we’ll edit.

Step 1: Revealing the Hidden Boot Errors (Exit Quiet Boot)

When I first encountered the boot failure, I was met with nothing but a static progress bar. By default, CentOS 7 uses a “quiet boot” setting that hides the technical minutiae of the startup process behind a clean splash screen. While this looks professional, it is incredibly unhelpful when you are troubleshooting a system that refuses to start.

To see what was actually happening under the hood, I needed to reveal the full system logs. As soon as the boot sequence begins, pressing the Esc key interrupts the quiet mode and displays the detailed text-based output. By doing this, I was finally able to see the specific [FAILED] messages—such as those regarding the Virtual Machine and Container Registration Service—that provided the first real clue into the system’s instability.

Step 2: Booting CentOS into Rescue Mode via GRUB

Once I realized the standard boot process was hitting a wall, my next move was to use the GRUB menu to bypass the failing services and drop straight into a command-line environment. It’s important to note that GRUB itself isn’t corrupt—it is still functioning perfectly as our entry point—we just need to change how it hands off control to the kernel.

Here is exactly how I navigated through the bootloader to enter rescue mode:

1. Select the Entry: When the VirtualBox window displays the GRUB boot menu, use your arrow keys to highlight your primary CentOS boot entry.
2. Edit the Boot Parameters: Press the e key on your keyboard. This opens an editor that allows you to modify the boot instructions before they are actually executed by the system.
3. Modify the Linux Line: Scroll down through the text until you find the line starting with linux16. This line contains the kernel-specific arguments and parameters. Navigate to the very end of this line, add a space, and append: systemd.unit=rescue.target
4. Execute the Boot: Once the parameter is added, press Ctrl+X (or F10) to boot with these new settings.

This process forces CentOS to skip the standard multi-user startup sequence—where the failing services are triggered—and instead boots you directly into a minimal, single-user rescue environment where we can address the SELinux configuration issues manually.

Step 3: Fixing the SELinux Configuration (the Root Cause)

Once I was settled into the rescue shell, my first task wasn’t editing files—it was making sure I could actually save them. Depending on how the system lands in rescue mode, the root filesystem can come up read-only, so to be safe I remounted it writable before touching anything:

mount -o remount,rw /

With write access secured, I turned my attention to the primary suspect: the SELinux configuration. SELinux sits deep in the boot path, and when its policy gets tangled up with the system’s state—as it can in a quirky VirtualBox guest—it’s capable of quietly stalling the very services CentOS needs to finish starting.

I opened the configuration file using vi:

vi /etc/selinux/config

Inside the file, I located the line starting with SELINUX=. Here is the detail that made this issue so hard to pin down: it wasn’t set to enforcing, as you might assume. It was already on permissive—a mode that is only supposed to log policy violations, not block anything. That’s precisely why SELinux is such an easy culprit to overlook here; on paper it shouldn’t have been able to stop those services at all. Yet they still refused to start. So rather than half-measures, I turned SELinux off completely:

SELINUX=disabled

Setting the mode to disabled takes SELinux fully out of the boot path on the next startup, which is what finally cleared the conflict stalling the Registration and Login services. I saved the file and exited the editor. (If you’d prefer to keep SELinux active for security, you can switch it back to enforcing once you’ve confirmed the VM boots reliably—but for getting a stuck machine running again, disabling it is the fastest, most decisive fix.)

Step 4: Verifying the Fix and Ruling Out the VirtualBox 6 Bug

After saving my changes in rescue mode, I performed a standard reboot to see if the system would finally reach the login prompt. This time, the boot sequence progressed smoothly; those alarming [FAILED] messages that had been stalling the startup process were nowhere to be seen.

To double-check my work, I ran getenforce once the system was up. The output came back Disabled, confirming SELinux was fully switched off and no longer interfering with the services that had been failing to initialize.

While the VM is now stable, I kept one caveat in mind: the environment involves VirtualBox 6.0.10. There have been documented instances of specific service failures linked to bugs within this particular version of the hypervisor. While correcting the SELinux configuration solved my immediate problem, if you encounter similar boot issues on a different machine even after following these steps, it is worth considering that the issue might reside in the VirtualBox software itself rather than your CentOS configuration.

The post How to Fix CentOS VM Client Boot Failure: A Step-by-Step Troubleshooting Guide appeared first on LarryLai.

While powerful cloud models like Opus 4.x can be integrated to manage local files and interact with my computer, running all tasks—no matter if they are complex, basic, or recurring—unnecessarily consumes expensive tokens. Even though there are several pricing tiers of cloud models to choose from, constantly switching between them during rapid implementation cycles is inconvenient. Local open-source models are fantastic for handling basic, repetitive tasks for free, but they are strictly bound by the hardware they run on.

Config
* Mac hardware: Mac mini M2 Pro with 32GB Unified Memory.
* Local Agent: “Hermes” framework running the gemma4:26b-mlx model.
* Cloud Agent: Claude running Opus 4.x.

Issue
Due to the hardware limitation of my Mac’s 32GB of memory (unlike a Mac Studio which can be configured with up to 512GB of unified memory), the relatively small gemma4:26b-mlx model frequently truncated complex Python scripts mid-generation. It would abruptly cut off critical logic right after the import statements and variable declarations.

To be clear, this truncation is due to the physical hardware constraints and the local model size, not a limitation or flaw in the Hermes agent framework itself. However, it meant the local agent could not be trusted to reliably write structural code.

Solution
To solve this, I built the Hybrid AI Orchestration Protocol: a directory-isolated, dual-agent “Walkie-Talkie” Blackboard architecture. The agents never speak directly; they coordinate via a single state.json file inside a .handover/ directory. This file separates liveness from intent (tracking the holder and the purpose).

To prevent file conflicts and token waste, the protocol enforces strict roles:
1. The Client (Me): Initiates the Product Requirements Document (PRD), answers questions, and gives final sign-off.
2. Claude (The Architect & QA): Handles structural planning, complex coding, and final QA. Claude is also the sole Version Control Manager—Hermes is strictly locked out of autonomous Git operations so a truncated script never overwrites the repository.
3. Hermes (The Executor): Restricted from structural coding. It reads Claude’s scripts, checks paths, installs pip dependencies, executes terminal tests, and reports errors back to Claude.

Tricks
What makes this system genuinely robust are three specific guardrails implemented to prevent common multi-agent failure modes:
* The DRILL-ME Phase: Before any code is written, Claude must interrogate me about the PRD. Crucially, Claude must ask operational questions on behalf of Hermes (e.g., confirming the exact macOS path for credentials). This ensures the local execution environment is mapped beforehand.
* Anti-Infinite-Loop: Agents can easily get stuck in an endless loop of failing a test and rewriting broken code. The state file tracks an attempt_count. If a script fails 5 times, it triggers an ABORTED state, forcing a human review.
* Append-Only Logs: During testing, failures are saved as append-only numbered logs (log_001.txt, log_002.txt) instead of overwriting the terminal output. This preserves the complete debugging history for Claude to analyze.

The post Hybrid AI Protocol: Orchestrating Cloud and Local AI appeared first on LarryLai.

This morning when accessing YouTube from TV, there’s no response. Found that the reason was internet access failure though WiFi connection was fine.

Then some other things got wrong due to router issue.

Issue

All the web hosting sites in local virtual server were down. The problem was port forwarding records all disappeared. I guess that after rebooting the router some configuration was corrupted.

Even worse, once adding back those port forwarding records, there’s error message about something like IP conflicts.

Solution

Restore previous configuration backup

Tricks

Sometimes a buggy device is bad. This time there are double bugs. First, configuration settings (port forwarding) unexpectedly corrupted; then the previous port forwarding became zombie configuration records. New addition of settings create conflicts.

Configuration

Netgear Nighthawk MR60: firmware ver. 1.0.4.98

The post Port Forwarding Issue – Netgear Nighthawk appeared first on LarryLai.

When trying to use FaceTime on iMac to make phone calls through iPhone, there is an issue to connect the iPhone with the Mac. Even though these 2 devices are on the same WiFi network. There’s an error message on the iPhone “Cannot turn on calls on other devices”. When clicking “Calls on Other Devices” under “Settings -> phone” as suggested by Apple’s support forum, it doesn’t work to connect the iPhone with the Mac.

Solution:

In the iPhone, go to Settings, and click “facetime”, select something like … AppleID… and sign in.

Tricks:

Though the AppleID is signed in probably in my new iPhone, some Apps have to be signed in, I guess, before some of its features are to be enabled.

Config:

• iPhone SE 2020: iOS 13.5.1
• iMac (late 2013): macOS 10.15.5 (Catalina)

The post Make Phone Calls on Mac appeared first on LarryLai.

Google Site Kit plugin for WordPress is no doubt a comprehensive site performance plugin delivering promised all-in-one dashboard also with colourful layout.

Issue:

Using Google Site Kits plugin for a while without problem, suddenly its dashboard, settings, analytics, etc. all go blank.

Solution:

Disable the plugin – Remove Query Strings by Littlebizzy

Tricks:

• A common practice to solve this kind of problem is to disable all plugins. However, in some cases with CDN installed like CloudFlare plugin, the DNS of the website is usually switched from domain hosting company to the CDN. Then, once the plugin is disabled, the website address will be disconnected with your web hosting server.
• The ‘Remove Query Strings’ plugin is to improve website speed rating.

The post Google Site Kit All Blank in WP appeared first on LarryLai.

Solution

1. 1. Remove the symbolic link of privkey.pem under

      /etc/letsencrypt/live/[mydomain]/privkey.pem

   2. recreate the symbolic link with the dedicated user running Jupyter notebook.
   3. Run command as root:

      systemctl restart jupyterhub

Tricks

1. 1. • As the jupyter server is run by the ownership of a dedicated user, after the renewal, the private key, i.e. privkey.pem must be owned by this user. However, I run the command:

        certbot renew --standalone

        under root.

      • note that let’s encrypt command for CentOS 6 is quite different from CentOS7

Config

1. • OS: CentOS 7
   • Jupyter-notebook: 5.7.8

The post SSL Key Ownership appeared first on LarryLai.

Default ordered list item style is decimal number, lower/upper alpha, lower/upper roman then followed by a dot. Thought it’s easy to change the dot to something like
  a) This is good 1st item
  b) This is good 2nd item.

      instead of:
  a. This is not good 1st item
  b. This is not good 2nd item

However, there’s no simple way to change the style of ordered list item and remove the dot after the order number <ol> <li></li></ol>.
As I got used to markdown’s convinence of auto numbering for ordered list items, don’t want to hard code the order into the list.

Solution

1. Removing the default ordering number and using counter by creating counter variable (say, list) like this
     ol { list-style-type: none; counter-reset: list;}
2. Update counter variable for each \
3. like this `ol>li { counter-increment: list; }
4. Display the content of the new counter like this `ol>li::before { content: counter(list, lower-alpha) ") "; }

Tricks

• It’s a bit complex for multi-level ordered list, but the principle still applies
• Some more has to be added to see hanging text like default ordered list display. This can be done by the following for modifying 2nd order level :

  ol ol {    
    list-style-type: none;    
    counter-reset: list;   
  }     
  ol ol>li::before {     
    content: counter(list, lower-alpha) ") \00a0";
    display: inline-block;
    width: 1.5em;
    text-align: right;
  }    
  ol ol>li {    
    counter-increment: list;    
    margin-left: .5em;    
    text-indent: -1.5em;    
  } 
  

  Of course, several paramenters can be adjusted to fit into each individual case. These include margin-left, text-indent spaces and the counter number style, i.e. lower-alpha, lower-roman, decimal, etc.

The post CSS List item style a) b) appeared first on LarryLai.