Making USB Bootable Windows 10 Installer

I needed to update some servers to Windows 10/2016 at work this week, but didn’t have any DVDs large enough to accommodate the 5.8 GB size of the Windows ISO. Normal DVD+Rs are 4.7 GB, so to make use of the ISO I downloaded from MSDN, one needs a DVD-R DL which can hold 8.5 GB of data.

I didn’t feel like going to a store or waiting for delivery, so I used Microsoft’s “Windows 7 USB/DVD Download Tool” (seemingly misnamed since it supports windows 7 and newer).

Once downloaded, the tool is fairly straight forward. You point it to an ISO, and then to a USB drive, and voila, it copies the data.

The annoyance is that I got the error “We were unable to copy your files. Please check your USB device and the selected ISO file and try again.” Trying again, of course, did not resolve the issue.

Fortunately, someone knowledgeable was able to explain the root cause of the error. The USB’s MBR needs to be cleared. This doesn’t happen automatically with the Windows Download Tool.

To clear the MBR and format the drive, follow these steps using the diskpart tool:

diskpart
diskpart> list disk
diskpart> select disk #
diskpart> clean
diskpart> create partition primary
diskpart> select partition 1
diskpart> active
diskpart> format quick fs=fat32
diskpart> assign
diskpart> exit

This resolved my issue and I was able to go along my merry way.

I don’t use Windows a lot in my every-day life, but it is something I use quite a bit at work. Documenting little things like this helps me to remember tricks I come across, and hopefully can help other people searching for solutions to similar problems.

NVidia Web Driver Headless Update

I upgraded my graphics card in my 2008 MacPro to an Nvidia 950. This of course requires the Nvidia WebDriver since Apple doesn’t offer built-in support. I installed the driver, swapped my cards, and it worked like a charm.

Today I had a security update from Apple and thought nothing of it. Unfortunately, after the chime, the video never showed up! I didn’t panic immediately. I SSHed into my computer, and told it to reboot just to see if it was a glitch. No luck… I also tried using screen sharing, alas screen sharing doesn’t work without a GPU.

Luckily it is possible to fix this problem with nothing more than an SSH connection to the troubled Mac. I logged in, and ran the command, system_profiler SPSoftwareDataType, to determine which OS Release I have so I can choose the appropriate WebDriver package.

$ system_profiler SPSoftwareDataType
Software:

    System Software Overview:

      System Version: OS X 10.11.6 (15G20015)
      Kernel Version: Darwin 15.6.0
      Boot Volume: Macintosh SSD
      Boot Mode: Normal
      Computer Name: MikePro
      User Name: Michael Caldwell (michaelcaldwell)
      Secure Virtual Memory: Enabled
      System Integrity Protection: Enabled
      Time since boot: 3 minutes

The helpful people at MacVidCards.com keep a handy list of all the up-to-date releases of the WebDriver. I selected the appropriate one and was able to install it over SSH using the installer command (which I didn’t know existed before today!).

$ sudo installer -pkg WebDriver-346.03.15f13.pkg -target /
Password:
installer: Package name is NVIDIA Web Driver 346.03.15f13
installer: Upgrading at base path /
installer: The upgrade was successful.
installer: The install requires restarting now.
$ sudo reboot
Connection to 10.0.1.12 closed by remote host.

After the reboot, the display popped on just like it used to. Crisis averted!

MediaWiki on CentOS 7

I’ve set up a few installations of MediaWiki in the past on different operating systems. It’s not the type of thing I do a lot, but when I do, It’s usually not too much trouble.

I was migrating an old MediaWiki installation from a Windows 2007 server to CentOS 7. I figured it would be pretty routine. It turns out there were a couple little hiccups along the way that I figure I should document to help me out in the future.

The first problem I ran into is that CentOS 7 doesn’t ship with a new enough version of of PHP for the current release of Media Wiki.

Uninstall built in version of PHP

yum erase php
yum erase php-common

Install yum repo for newer PHP release

rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm

Install PHP packages

yum install php55w* --skip-broken

This allowed MediaWiki to run finally, and I was able to create a new LocalSettings.php. From there I restored the SQL database without any issue. Don’t forget to install MariaDB.

yum install mariadb-server mariadb

To import the old SQL data to the new DB, first creat a DB with the same name, and then pupolate it with the sql file.

# Get into mysql shell
mysql --password=********
# Create DB with same name as old DB
mysql> CREATE DATABASE my_wiki;
# Exit shell

# Import old SQL data to new DB
mysql --password=******** my_wiki < /wiki.sql

I also copied over the images directory from the old installation.

The next issue I had is permissions. SELinux wasn’t even on my mind, and provided all sort of permission problems. I ran the following commands on my html directory where MediaWiki is installed in an attempt to fix everything.

sudo chown apache:apache -R /var/www/html/

find . -type f -exec chmod 0644 {} \;
find . -type d -exec chmod 0755 {} \;

sudo chcon -t httpd_sys_content_t /var/www/html -R
sudo chcon -t httpd_sys_rw_content_t /var/www/html/images/ -R

At this point, MediaWiki is running, but I couldn’t see any images, or upload any files. I tweak settings in LocalSettings.php but to no avail. I enabled logs and better error messages by adding these lines to LocalSettings.php

$wgShowExceptionDetails = true;
$wgDebugLogFile = "/var/log/mediawiki/debug-{$wgDBname}.log";

When I upload a file using MediaWiki, I get the error:

Could not create directory "mwstore://local-backend/local-public/1/1e".

The log file shows the following error:

[FileOperation] mkdir(): Permission denied
[FileOperation] FSFileBackend::doPrepareInternal: cannot create directory /1/1e

I am unable to upload images, so I Google the error message and check my settings. Almost all of the sites talking about this error suggested permission issues with the images folder. I checked my permissions over, and over again with no luck. The rest fo the sites talked about having the $wgTmpDirectory set correctly, which I’m pretty sure I did.

$wgEnableUploads = true;
$wgUseImageMagick = true;
$wgImageMagickConvertCommand = "/usr/bin/convert";
$wgTmpDirectory = '/var/www/html/images/temp';

What bothers me is that the error message in the log looks like it is trying to mkdir at the root level, however MediaWiki switches a lot between url paths (relative) and absolute. It wasn’t clear. The next debugging step was using strace to see what the OS was doing. I attached strace to one of the apache processes and uploaded a file, and lo:

mkdir("/temp", 0777)                    = -1 EACCES (Permission denied)

It is trying to use my root directory as the images fodler location, even though I have a different tmp directory specified in my settings file.

It turns out that there are default setting in the img_auth.php file that don’t appear to be correct. They get automatically set based on the environment. I chose to explicitely set them in the LocalSettings.php document instead.

# Redefining Upload Directory and Path from img_auth.php
$wgUploadDirectory = '/var/www/html/images';
$wgUploadPath = '/images';

Finally. My images instantly start working and I can upload files again. Thank goodness! This wasn’t a difficult thing, but it is surprising that I couldn’t find any help on the internet for this specific problem. And since I don’t install/perform maintenance on MediaWikis very often, there is a lot of stuff I have to relearn. So here it is, some notes on this issue for my future self, in case I ever need it.

© 2007-2015 Michael Caldwell