E-Prime 3 got a new issue with recent Windows 10 update. The presentation nearly always stuck at the end of the first item. Diagnose showed that only when E-Prime/E-Run was running on CPU 0, it can finish properly. To enforce this, a shortcut is created for each E-Run file with the target as

C:\Windows\System32\cmd.exe /c start “” /Normal /Affinity 0x1 “C:\Program Files (x86)\PST\E-Prime 3.0\Program\E-Run.exe” “C:\Location of\Your E-Run file.ebs3”

This forces the E-Run to run only on CPU 0.

Another issue: E-Prime 3 can only drive monitors up to 1920×1200 resolution. When your monitor’s native resolution is higher than this, you will have to set your monitor’s resolution lower than this to make E-Prime presentations run. However, if you set the screen resolution too low, some monitors struggle on amplifying the small resolution video signal back to its native resolution. This sometimes cause the screen flickering. To prevent this, the best way is to set the screen resolution as well as the E-Prime display resolution to exactly 1/2 or close to the top resolution E-Prime allows.

My Mellanox MSN2100 switch constantly has the “system status” LED on red since purchase.

By looking into its system status:

show system-health detail

System status summary

System status LED red
Services:
Status: OK
Hardware:
Status: Not OK
Reasons: Failed to get speed tolerance for fan4
Failed to get speed tolerance for fan3
Failed to get speed tolerance for fan2
Failed to get speed tolerance for fan1

System services and devices monitor list

Name Status Type
——————— ——– ———-
sonic OK System
rsyslog OK Process
root-overlay OK Filesystem
var-log OK Filesystem
routeCheck OK Program
dualtorNeighborCheck OK Program
diskCheck OK Program
container_checker OK Program
vnetRouteCheck OK Program
memory_check OK Program
container_memory_snmp OK Program
container_memory_gnmi OK Program
container_eventd OK Program
database:redis OK Process
syncd:syncd OK Process
bgp:zebra OK Process
bgp:staticd OK Process
bgp:bgpd OK Process
bgp:fpmsyncd OK Process
bgp:bgpcfgd OK Process
teamd:teammgrd OK Process
teamd:teamsyncd OK Process
teamd:tlm_teamd OK Process
swss:orchagent OK Process
swss:portsyncd OK Process
swss:neighsyncd OK Process

swss:fdbsyncd OK Process
swss:vlanmgrd OK Process
swss:intfmgrd OK Process
swss:portmgrd OK Process
swss:buffermgrd OK Process
swss:vrfmgrd OK Process
swss:nbrmgrd OK Process
swss:vxlanmgrd OK Process
swss:coppmgrd OK Process
swss:tunnelmgrd OK Process
eventd:eventd OK Process
snmp:snmpd OK Process
snmp:snmp-subagent OK Process
lldp:lldpd OK Process
lldp:lldp-syncd OK Process
lldp:lldpmgrd OK Process
gnmi:gnmi-native OK Process
fan1 Not OK Fan
fan2 Not OK Fan
fan3 Not OK Fan
fan4 Not OK Fan
ASIC OK ASIC
PSU 1 OK PSU
PSU 2 OK PSU

System services and devices ignore list

Name Status Type
————— ——– ——
psu.voltage Ignored Device
psu.temperature Ignored Device

It shows that it cannot obtain fan tolerance data from the database.

Researching the system files, it is found in file /usr/local/lib/python3.9/dist-packages/sonic_platform/fan.py, the fan tolerance is hard set to 50%. And this is not passed to /usr/local/lib/python3.9/dist-packages/health_checker/hardware_checker.py via function data_dict.get(‘speed_tolerance’, None)

There is a simple fix of this: comment out the line #105 of the hardware_checker.py , replace it a hard setting

speed_tolerance = 50

And the system status LED turns green.

The Mellanox/NVidia MSN2100 switch came with a bare ONIE system and is not Plug and Play. NVidia service can not provide setting up assistance without a ONYX//Cumulus/SONiC entitlement. I installed the community version of SONiC from sonic.software for sonic-mellanox.bin.

After the installation, the switch is automatically configured with all 16 ports as routers with a preset IP from 10.0.0.0 to 10.0.0.30. This rendered the switch useless since no two ports can talk with each other.

The following steps resolved the issue and made it a normal dummy switch:

Once log in the management interface:

Step 1: sudo bash # to bring a root interface;

Step 2: config vlan add 100 # This create a vlan;

Step 3: config interface ip remove Ethernet0 10.0.0.0 # do this to all 16 interfaces to remove their router status;

Step 4: config vlan member add 100 -u Ethernet0 # do this to all 16 interfaces to group all ports to a vlan;

Step 5: config clock timezone America/New_York # set time zone of the switch;

Step 6: config clock YYYY-MM-DD HH:MM:SS # set time;

Step 7: cp /etc/sonic/config_db.json ~/ # make a backup of the initial configuration;

Step 8: config save -y # save current configuration;

Step 9: reboot

Then you will get a working switch.

Certainly, do not forget to reset the management password and management port (eth0) ip.

Enjoy.

Sometimes your NFS mount stopped response. You cannot umount normally, if you use umount -l to unmount it, you cannot mount it again, Mounting attempt stalls too. The suggestion on the interenet was to just reboot the client. But you may have important jobs or services on it and you really do not want to.

Here is a rescue:

After you unmounted the volume using umount -l, edit your /etc/fstab file, add vers=3 in front of the “defaults,_netdev” or whatever nfs mounting option column of the stalled volume, save it. Then you try mounting it again, and it is mounted.

This is not the end of story. There are some important new features from NFS_v4 that you do not want to permanently backup to NFS_v3. And someday the vers=3 mount may stall again.

Do not worry. Actually as long as the nfs server is still working, the calls that caused nfs stall will resolve or time out slowly. Wait a day or two, then you go back to the nfs client node, umount the volume mounted with vers=3. If it is in use, use umount -l to unmount it. Then you go editing the /etc/fstab file again, remove the vers=3 instruction, save it. Then you go back to your prompt and mount the volume again. As long as all pending calls that caused the original nfs stall are resolved, you will be able to mount the volume by default version, NFS_v4, again.

This process can be repeated is similar issue happens again, and you are free of being forced to reboot the nfs client box.

Sometimes when an dnf update was unexpectedly terminated like a power failure, the system may leave an inconsistent rpm database. If this happens, in most case by rebuilding rpm database (rpmdb –rebuilddb), and to use (package-cleanup –cleandupes), it could be fixed.

For some severe case, after both, when you are trying to run (dnf update –allowerasing), it still shows this kind of errors:

Running transaction check
error: rpmdbNextIterator: skipping h# ***
Header V3 RSA/SHA1 Signature, key ID ********: BAD
Header SHA256 digest: OK
Header SHA1 digest: OK

And the install/update cannot go through.

If you use (rpm -qa | grep <affected-package>), it shows that the package is not installed. Reinstalling the package using (rpm -Uvh <downloaded package name>) does not help.

This means that a package was erased in the interrupted dnf install/update but the record was not removed from the rpm database. You will need to do

rpm -e –justdb –noscripts –nosignature <package name>

to remove it.

However, sometimes the blocking package name cannot be found in the rpm database.

Here is a clue: when you are doing dnf install, it spits off errors like

Error: transaction check vs depsolve:
libxxx.so.x()(64bit) is needed by <package name>

This shows what lib file is missing.

You can go to internet to google the rpm package of the libxxx.so.x to find which package for your linux distro provides the missing lib file. Then run the

rpm -e –justdb –noscripts –nosignature <package name>

to remove the missing package.

After this, the dnf should function properly thereafter.

If ForwadX11 and ForwardX11Trusted are both enabled in /etc/ssh/ssh_config, when you do “ssh host” it will invoke X11 forwarding by default. This is convenient when you frequently need to run programs with GUI on remote host. However, with X11 forwarding, if you are simply running a text mode command/script via ssh, like “ssh node ls” to list files on a remote host, it may not exit properly with X11 forwarding.

To avoid this, the simplest way is to disable X11 forwarding in the ssh command using -x option: using “ssh -x node command” instead of “ssh node command”.

echo <your password> | ssh <node name> “sudo -S <command>”

For a RAID NAS box, when the NAS box dies, the data on the drives are still intact. They can be retrieved in the following steps:

1. dd disks containing LVM to hard drive; # create images of hard drives
2. losetup /dev/loopx disks.img; # make images appear as loop devices on OS
3. partx -v -add /dev/loopx; # make partitions on the loopback devices available to OS
4. vgscan, vgimport -a; # to import Virtual Groups
5. vgdisplay; # showing imported VG names
6. vgchange -a y vgname; # to activate VG
7. fsck /dev/mapper/vgname; # to check file system of VG
8. fuseext2 -o ro -o sync_read /dev/mapper/vgname /mounting_point; # to mount the VG
9. rsync -av –progress /mounting_point/ /destination/

Then you will get everything at your destination, and then you can safely remove the images.