Windows ME BSODs (Exception, System Busy, and WARNING) Captured directly from VMware Workstation today.

I had found in the past that it was a bit hard to find clean, unedited, pixel-perfect copies of the Blue Screens of Death, so when my Windows ME VM crashed today I knew it was time to save these for the future. These are pretty much the same as the ones that would appear in Windows 95 and Windows 98.

First the classic “An exception 0D has occurred” BSOD

Next, System is busy

and last but not least, WARNING system has become unstable

Installed a new Ubiquiti USG at an office downtown today, and noticed that in the 8 hours since the system was first up, it had detected over 800 nearby networks. I decided to analyze the data a bit for fun.

First, the channel. I was surprised to see that over half of all detected APs were on channel 6.

It does make sense that there are far more 2.4GHz APs detected, since it has better signal penetration.

Next up, security standards.

Nearly 90% of APs are using WPA2 of some sort, and just over 10% are open. Less than 1% use WPA.

Now, arguably the most interesting – the AP manufacturer, according to OUI lookup.

Note: some OUIs were not recognized, so the dataset is slightly less than 800 here.

In the manufacturer breakdown we se a lot of the usual brands – Cisco, Aruba and Ubiquiti are in the top. Technicolor, Sagemcom, ASUS, HP, Juniper, Sonicwall are all also common network vendors. But what of the others?

The biggest “unusual” vendor we see is Mitsumi. Mitsumi is generally known as an OEM that manufactures PC peripherals and input devices – mice, keyboards, floppy and optical drives, and quite a few game consoles. It’s not surprising that they would make WiFi radios, but I wouldn’t expect their OUI to be used as an OEM.

Looking a bit further at the data, most of the Mitsumi networks’ SSIDs are in the format “WiFi Hotspot 0000” (where 0000 is a random 4 digits). However, a few of them had names such as “Cruze”, “Volt”, “Equinox” and “Malibu”. So, apparently Mitsumi manufactures the WiFi radio for the GM OnStar car hotspots.

Continuing on with the less-known OUI vendors, we also see Visteon, Continen (Continental), Harman/B (Harman/Becker), and AlpsElec (Alps Electric).

Alps, like Mitsumi, is an OEM known for PC peripherals – particularly keyboards and laptop touchpads. In this case, the SSIDs for the Alps APs are all some variant of “MB Hotspot 000” – so they are Mercedes-Benz car hotspots.

So, unsurprisingly, the other 3 are also car electronics OEMs.

Visteon – spun off from Ford in 2000, they specialize in car infotainment and other electronics systems.
Continental Automotive Systems – The electronics systems branch of German company Continental Tire.
Harman/Becker – a division of Samsung, specialized in car electronics, resulting from the Harman company’s acquisition of Becker, a German car radio manufacturer.

Today’s takeaway: a LOT of cars have WiFi hotspots built-in these days!

Got frustrated that this form wasn’t available as a proper PDF form, so made it myself. Intended only as a convenience for those who wish to use it. PDF is not password-protected or signed.

Download a copy of the 4383-80E pdf form (Patient Enrolment and Consent to Release Personal Health Information) below.

Intel used to host these on their website, but took them down in a purge a few years back. So here are the drivers I saved a while back.

XBEM – Ethernet + Modem
XBE – Ethernet only

The 314 ones are from Intel (2000), the others are from Dell and a bit older (1999). All versions in one 7-zip file.

I’ve found multiple guides on how to enable NVIDIA GPU access from lxc containers, however I had to combine the information from multiple sources to get a fully working setup. Here are the steps that worked for me.

1. Install dkms on your Proxmox host to ensure the nvidia driver can be auto-updated with new kernel versions.
   # apt install dkms
2. Download the latest nvidia binary driver supported by nvidia-patch.
   Head over to https://github.com/keylase/nvidia-patch and get the latest supported driver version listed there.
3. Download the nvidia-patch repo
   git clone https://github.com/keylase/nvidia-patch.git
4. Install the driver from step 1 on the host.
   For example, ./NVIDIA-Linux-x86_64-455.45.01.run
5. Run the nvidia-patch/patch.sh script on the host.
6. Install the same driver in each container that needs access to the Nvidia GPU, but without the kernel module.
   ./NVIDIA-Linux-x86_64-455.45.01.run --no-kernel-module
7. Run the nvidia-patch/patch.sh script on the lxc container.
8. On the host, create a script to initialize the nvidia-uvm devices. Normally these are created on the fly when a program such as ffmpeg calls upon the GPU, but since we need to pass the device nodes through to the containers, they must exist before the containers are started.
   
   I saved the following script as /usr/local/bin/nvidia-uvm-init. Make sure to chmod +x !

#!/bin/bash
## Script to initialize nvidia device nodes.
## https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html#runfile-verifications

/sbin/modprobe nvidia

if [ "$?" -eq 0 ]; then
  # Count the number of NVIDIA controllers found.
  NVDEVS=`lspci | grep -i NVIDIA`
  N3D=`echo "$NVDEVS" | grep "3D controller" | wc -l`
  NVGA=`echo "$NVDEVS" | grep "VGA compatible controller" | wc -l`

  N=`expr $N3D + $NVGA - 1`
  for i in `seq 0 $N`; do
    mknod -m 666 /dev/nvidia$i c 195 $i
  done

  mknod -m 666 /dev/nvidiactl c 195 255

else
  exit 1
fi

/sbin/modprobe nvidia-uvm

if [ "$?" -eq 0 ]; then
  # Find out the major device number used by the nvidia-uvm driver
  D=`grep nvidia-uvm /proc/devices | awk '{print $1}'`

  mknod -m 666 /dev/nvidia-uvm c $D 0
  mknod -m 666 /dev/nvidia-uvm-tools c $D 0
else
  exit 1
fi

Next, we create the systemd service files to start this script, and the nvidia-persistenced.

# nvidia-uvm-init.service
# loads nvidia-uvm module and creates /dev/nvidia-uvm device nodes

[Unit]
Description=Runs /usr/local/bin/nvidia-uvm-init

[Service]
ExecStart=/usr/local/bin/nvidia-uvm-init

[Install]
WantedBy=multi-user.target

# NVIDIA Persistence Daemon Init Script
#
# Copyright (c) 2013 NVIDIA Corporation
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.
#
# This is a sample systemd service file, designed to show how the NVIDIA
# Persistence Daemon can be started.
#

[Unit]
Description=NVIDIA Persistence Daemon
Wants=syslog.target

[Service]
Type=forking
ExecStart=/usr/bin/nvidia-persistenced --user nvidia-persistenced
ExecStopPost=/bin/rm -rf /var/run/nvidia-persistenced

[Install]
WantedBy=multi-user.target

Next, symlink the two service definition files into /etc/systemd/system
cd /etc/systemd/system
# ln -s /usr/local/lib/systemd/system/nvidia-uvm-init.service
# ln -s /usr/local/lib/systemd/system/nvidia-persistenced.service
and load the services
# systemctl daemon-reload
# systemctl start nvidia-uvm-init.service
# systemctl start nvidia-persistenced.service

Now you should see all the nvidia device nodes have been created
# ls -l /dev/nvidia*
crw-rw-rw- 1 root root 195, 0 Dec 6 18:07 /dev/nvidia0
crw-rw-rw- 1 root root 195, 1 Dec 6 18:10 /dev/nvidia1
crw-rw-rw- 1 root root 195, 255 Dec 6 18:07 /dev/nvidiactl
crw-rw-rw- 1 root root 195, 254 Dec 6 18:12 /dev/nvidia-modeset
crw-rw-rw- 1 root root 511, 0 Dec 6 19:00 /dev/nvidia-uvm
crw-rw-rw- 1 root root 511, 0 Dec 6 19:00 /dev/nvidia-uvm-tools

/dev/nvidia-caps:
total 0
cr-------- 1 root root 236, 1 Dec 6 18:07 nvidia-cap1
cr--r--r-- 1 root root 236, 2 Dec 6 18:07 nvidia-cap2

Check the dri devices as well
# ls -l /dev/dri*
total 0
drwxr-xr-x 2 root root 100 Dec 6 17:00 by-path
crw-rw---- 1 root video 226, 0 Dec 6 17:00 card0
crw-rw---- 1 root video 226, 1 Dec 6 17:00 card1
crw-rw---- 1 root render 226, 128 Dec 6 17:00 renderD128

Take note of the first number of each device after the group name. In the listings above I have 195, 511, 236 and 226.

Now we need to edit the lxc container configuration file to pass through the devices. Shut down your container, then edit the config file – example /etc/pve/lxc/117.conf. The relevant lines are below the swap: 8192 line

arch: amd64
cores: 12
features: mount=cifs
hostname: plex
memory: 8192
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.1.1,hwaddr=4A:50:52:00:00:00,ip=192.168.1.122/24,type=veth
onboot: 1
ostype: debian
rootfs: local-lvm:vm-117-disk-0,size=250G,acl=1
startup: order=99
swap: 8192

lxc.cgroup.devices.allow: c 195:* rwm
lxc.cgroup.devices.allow: c 226:* rwm
lxc.cgroup.devices.allow: c 236:* rwm
lxc.cgroup.devices.allow: c 511:* rwm
lxc.mount.entry: /dev/dri dev/dri none bind,optional,create=dir
lxc.mount.entry: /dev/nvidia-caps dev/nvidia-caps none bind,optional,create=dir
lxc.mount.entry: /dev/nvidia0 dev/nvidia0 none bind,optional,create=file
lxc.mount.entry: /dev/nvidiactl dev/nvidiactl none bind,optional,create=file
lxc.mount.entry: /dev/nvidia-uvm dev/nvidia-uvm none bind,optional,create=file
lxc.mount.entry: /dev/nvidia-modeset dev/nvidia-modeset none bind,optional,create=file
lxc.mount.entry: /dev/nvidia-uvm-tools dev/nvidia-uvm-tools none bind,optional,create=file

Now, start your container back up. You should be able to use NVENC features. You can test by using ffmpeg:
$ ffmpeg -i dQw4w9WgXcQ.mp4 -c:v h264_nvenc -c:a copy /tmp/rickroll.mp4

You should now have working GPU transcode in your lxc container!

If you get the following error, recheck and make sure you have set the correct numeric values for lxc.cgroup.devices.allow and restart your container.

[h264_nvenc @ 0x559f2a536b40] Cannot init CUDA
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width
or height
Conversion failed!

Another way to tell the values are incorrect is having blank (———) permission lines for the nvidia device nodes.

$ ls -l /dev/nvidia*
---------- 1 root root        0 Dec  6 18:04 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 Dec  6 19:02 /dev/nvidiactl
---------- 1 root root        0 Dec  6 18:04 /dev/nvidia-modeset
crw-rw-rw- 1 root root 511,   0 Dec  6 19:02 /dev/nvidia-uvm
crw-rw-rw- 1 root root 511,   1 Dec  6 19:02 /dev/nvidia-uvm-tools

In an Administrator PowerShell session:

# Install the OpenSSH Server
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
# Set service to Automatic startup
Set-Service -Name sshd -StartupType 'Automatic'
# Start service
Start-Service sshd
# Confirm the Firewall rule is configured. It should be created automatically by setup. 
Get-NetFirewallRule -Name *ssh*

Update: Even after doing all this the system still locks up randomly when using the amdgpu driver.

I’m running dual AMD FirePro W2100 driving 3 monitors in my workstation. Since installing the cards I’ve been suffering random freezes/graphical lockups that seemed to be related to 3D. They occurred typically during an animation in gnome-shell, or when using Firefox or Chrome with hardware acceleration. Most times, I was able to recover by logging in to the machine via ssh and sending killall -HUP to the appropriate process (usually gnome-shell). Every time this happened, syslog would be full of GPU faults:

[ 2482.763707] radeon 0000:02:00.0: GPU fault detected: 146 0x0468100c
[ 2482.763708] radeon 0000:02:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0011173E
[ 2482.763709] radeon 0000:02:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0805000C
[ 2482.763710] VM fault (0x0c, vmid 4) at page 1120062, read from CB (80)
[ 2482.763713] radeon 0000:02:00.0: GPU fault detected: 146 0x0408500c
[ 2482.763714] radeon 0000:02:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00111744
[ 2482.763715] radeon 0000:02:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0805000C
[ 2482.763717] VM fault (0x0c, vmid 4) at page 1120068, read from CB (80)

I tried updating my kernel (going from Ubuntu 18.04 to 18.10 and even reinstalling with Pop!_OS 18.10 than 19.04) and updating graphics drivers using the oibaf ppa, to no avail. Finally found what seems to be the solution on HackerNews (thanks danieldk) – force the use of the newer amdgpu driver rather than the older radeon driver. The W2100 is a first-generation GCN chip and so is supported by both drivers, and radeon is chosen as the default. To force amdgpu, you need to pass the kernel flags

amdgpu.si_support=1 radeon.si_support=0 amdgpu.cik_support=1 radeon.ciksupport=0

In Ubuntu, add these to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, then run update_grub. Pop!_OS doesn’t use grub, so you need to add each flag using kernelstub -a amdgpu.si_support=1 and repeating for each of the 4.

So far, my system seems stable since this change. I will update this post if anything changes.

It “just works!”

Install pulseaudio-dlna from Ubuntu default repos, then run pulseaudio-dlna. The first time, it failed, but I think that’s because the receiver was switched off. Console output did show it had been detected though. After switching on the receiver then running pulseaudio-dlna again, it redirected my currently playing audio to the receiver after a few seconds! So far this is the first time I’ve managed to get DLNA live streaming working with this receiver in 5 years of owning it.

Note: this post is more intended for personal reference; as such the quality of writing is not up to my standard, but I’ve decided to publish it as-is anyway since I don’t have time to review and figure it could be useful to someone.

I was looking for a good portable Linux laptop to that I could carry around without being too worried about battery life or the device getting scratched up in my bag. I tried a few different devices, including the HP Folio 13, ThinkPad X131e, GPD Pocket, Dell Latitude E7240. Finally I settled on the Acer C720 Chromebook. The main points in favour of this device are, for me:

• Compact, thin and light (11.6″)
• Relatively low cost (4GB RAM model can be had for under $150 CAD)
• Proper modern low-voltage Intel Core processor (Celeron 2957U – Haswell) and not an Atom core or high-end i7
• Dual-band Wi-Fi and Bluetooth

and the main downsides:

• Basic TN LCD panel
• 16GB storage
• Runs Chrome OS
• Chrome OS keyboard layout

The good news is the downsides are fairly easily remedied.

TN LCD Panel

The Acer C720 uses a standard 11.6″ LED backlit eDP panel. I was able to find an IPS panel to replace it on laptopscreen.com (model N116BCA-EA1). The panel replacement is fairly straightforward; care needs to be taken not to break the LCD bezel or any of the clips.

16GB SSD

The SSD on the C720 is a standard M.2 2242 SATA SSD. The M.2 slot is easily accessible after removing the Chromebook’s bottom cover.

Runs Chrome OS

The Chrome OS/Linux dual-boot process is done by using the chrx script (https://github.com/reynhout/chrx). Remember to remove the write-protect screw while the bottom cover is off.

Chrome OS keyboard layout

This was arguably the hardest part. I chose to run Xubuntu, so the steps I went through apply to that environment. Chrx by default provides good defaults, mapping the back, forward, refresh, brightness and volume keys. The big issue for me was the placement of the power button (above the backspace key)

1. Prevent systemd-logind from handling the power button
   edit /etc/systemd/logind.conf and add the following line:
   HandlePowerKey=ignore
2. Prevent xfce power manager from handling the power button
   xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/logind-handle-power-key -s true
3. Allow xfce power manager to handle lid switch
   xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/logind-handle-lid-switch -s false
4. Remap power key to Delete
   xmodmap -e “keycode 124 = Delete”
   To find the keycode, stop lightdm, startx to start a basic X session, then use xev to get the keycode for the power key.

 

Other tweaks

Consistent custom wallpaper/background for boot splash, login, and lock screen

• gnome-screensaver uses the Gnome DE’s wallaper setting. Configure this via CLI:
  gsettings set org.gnome.desktop.background picture-uri file:///usr/local/share/wallpaper/animevillage.jpg
• lightdm-gtk-greeter can be configured using GUI tool lightdm-gtk-greeter-settings or by editing /etc/lightdm/lightdm-gtk-greeter.conf
• plymouth/boot splash:
  • go to /usr/share/plymouth/themes and create a copy of the xubuntu-logo directory. I called mine xubuntu-logo-mod
    sudo cp -R xubuntu-logo xubuntu-logo-mod
  • within the new xubuntu-logo-mod directory, rename and edit config files accordingly
    325 cd xubuntu-logo-mod/
    326 ls
    327 sudo mv xubuntu-logo.plymouth xubuntu-logo-mod.plymouth
    328 sudo mv xubuntu-logo.script xubuntu-logo-mod.script
    329 sudo nano xubuntu-logo-mod.script
  • replace wallpaper.png in xubuntu-logo-mod directory with desired image. I used ImageMagick’s convert tool to convert my jpg format image to png.
  • add new theme we have created as an “alternative” with higher priority
    • Find out priority and config for current theme
      sudo update-alternatives –query default.plymouth
      Name: default.plymouth
      Link: /usr/share/plymouth/themes/default.plymouth
      Status: auto
      Best: /usr/share/plymouth/themes/xubuntu-logo-mod/xubuntu-logo-mod.plymouth
      Value: /usr/share/plymouth/themes/xubuntu-logo-mod/xubuntu-logo-mod.plymouth

      Alternative: /usr/share/plymouth/themes/xubuntu-logo-mod/xubuntu-logo-mod.plymouth
      Priority: 200

      Alternative: /usr/share/plymouth/themes/xubuntu-logo/xubuntu-logo.plymouth
      Priority: 150

    • Create new alternative with higher priority
      sudo update-alternatives –install /usr/share/plymouth/themes/default.plymouth default.plymouth /usr/share/plymouth/themes/xubuntu-logo-mod/xubuntu-logo-mod.plymouth 200

 

 

 

1. 1. Adjust screen layout using your DE’s tool.
   2. Install and run arandr. arandr will read the current display layout and allow you to save it as an xrandr script.
      
   3. Place the script from arandr somewhere safe (I put it in /usr/local/bin).
   4. Create file /etc/lightdm/lightdm.conf.d/displays.conf with the following content:

      [SeatDefaults]
      display-setup-script=/usr/local/bin/monitorlayout.sh
      

      Where “/usr/local/bin/monitorlayout.sh” is the path to the script saved from arandr.
      For sddm, instead edit /usr/share/sddm/scripts/Xsetup.sh and add a line to have it run the same “/usr/local/bin/monitorlayout.sh” script.

      #!/bin/sh
      # Xsetup - run as root before the login dialog appears
      
      # set screen layout using Xrandr
      /usr/local/bin/monitorlayout.sh

   5. Restart lightdm or sddm

      sudo systemctl restart lightdm.service
      sudo systemctl restart sddm.service