Breadcrumb NavXT 6.3 and Premium Extensions

Over the past few weeks, various Breadcrumb NavXT extensions have been updated in preparation for Breadcrumb NavXT 6.3. Today, the last batch of extension updates are being released. The following extensions are now ready for Breadcrumb NavXT 6.3:

Breadcrumb NavXT 6.3 is not scheduled for release for another few weeks. However, it is recommended to update any extension plugins in use before updating Breadcrumb NavXT.

Users with valid and activated license keys should receive an update notification within the WordPress dashboard and be able to use the update mechanism to update (just like with any plugin in the WordPress.org repository).

Breadcrumb NavXT uManager 1.2.0

Announcing the immediate availability of Breadcrumb NavXT uManager 1.2.0. This version introduces two new features and offers improved compatibility with Breadcrumb NavXT 6.3.0.

On the new feature front, a breadcrumb trail module for Divi is now included. Also new in 1.2.0 is the ability to use multiple taxonomies in a breadcrumb trail for a given post type. Additionally, the order these taxonomies appear in the breadcrumb trail can be specified in the Breadcrumb NavXT settings page.


Users with valid and activated license keys should receive an update notification within the WordPress dashboard and be able to use the update mechanism to update (just like with any plugin in the WordPress.org repository).

Breadcrumb NavXT Multidimension Extensions 2.5.3

Announcing the immediate availability of Breadcrumb NavXT Multidimension Extensions 2.5.3. This version improves compatibility with the upcoming Breadcrumb NavXT 6.3. Changes in Breadcrumb NavXT 6.3’s setting page results in older versions of Breadcrumb NavXT Multidimension Extensions producing a blank settings tab.

You can grab Breadcrumb NavXT Multidimension Extensions from the WordPress.org plugin repository.

XDM/SDDM Slow Startup Followup

As reference previously, recently, the XPS 15 9530 had an issue in startup where the login prompt in the shell was available but XDM/SDDM did not start until several key presses later. Waiting for it to start was a futile effort—once waited over 30 minutes to no avail. A full system reinstall did not help either.

Digging into the dmesg output revealed something interesting:

[83.413293] random: crng init done
[83.413299] random: 7 urandom warning(s) missed due to ratelimiting

It was taking over a minute and a half for random to generate enough entropy. And, this was with the keyboard getting mashed! Apparently, this is a relatively common issue to run into.

Since the XPS 15 9530 has a Haswell core CPU with RDRAND instruction support, an easy way around this is to enable “Trust CPU Vendor” in the kernel config:

CONFIG_RANDOM_TRUST_CPU=y

Now, this is not without consequence. There is concern that Intel’s RDRAND implementation was inappropriately influenced by external parties. An alternative workaround is to install haveged. This has its own issues—it is a software solution to inflate entropy. Finally, on the Gentoo forums, the recommendation is to continue to mash the keyboard until userland applications are updated with to more appropriate entropy requirements.

Fix Linux Boot Halting on “Run /init as init process”

In the process of removing the remaining SandForce controller based SSDs from service, the opportunity to completely refresh the Funtoo install on the XPS 15 9530 was taken. Part of this was to try to figure out why recently sddm would not start until a bit of keyboard mashing occurred (literally pushing the enter key a dozen times in a row caused sddm to start, waiting was simply not enough).

The install was fairly painless—most problems tend to be involve getting the proper device drivers compiled into the kernel. Given there was already a known good kernel config, that was used for the building the kernel on the new install. However, on the first boot off of the new SSD, the boot process halted at:

[2.754164] Freeing unused kernel image memory: 1020K
[2.756196] Write protecting the kernel read-only data: 20480k
[2.758698] Freeing unused kernel image memory: 1980K
[2.760892] Freeing unused kernel image memory: 620K
[2.764980] Run /sbin/init as init process

The init system (OpenRC), for some reason, did not actually kick off. Plugging in a USB device confirmed that the kernel itself was still running. Thus, it was not something simple such as the root device being inaccessible (that causes a kernel panic). But, in this state, the system was not usable (no login prompt).

After a bit of sleuthing and stumbling, a solution was found. The following was added to the kernel config:

CONFIG_DEVTMPFS_MOUNT=y

After rebuilding the kernel and rebooting, the system finally booted completely. Still, this is a little unnerving. This machine never needed this setting before. Additionally, I have not needed this setting on any other machine.