Thursday, March 23, 2017

Dance, Dance...ZOT! Fixing a Dangerous Disco Light

  
Having Fun Shouldn't Be Deadly, But It Easily Could Have Been...


The Shocking Story of the FX LAB Disco Light

The other day a friend told me he had a light that shocked him when he touched it.  Intensely curious, I asked him if I could take a look at it.  He was more than happy to pass it to me, and I spent a little time with it this afternoon figuring out why it was unsafe.  The short answer is that the light was badly designed - and cheaply manufactured.  This combination resulted in a device that leaked 230VAC to its external enclosure, at up to 10VA.  This is more than enough power to be lethal

Here's a shot of the rear of the unit, showing its brand name, working voltage and so forth:


Ocular Inspection

An external inspection of the unit revealed very little.  The power cord and plug were undamaged.  There were no obvious cracks, splits or other signs of damage to the body of the unit.  

"Cold" Power Check

I next performed a "cold" power check on the device, which means I checked it out while it was unplugged.  Using my beloved Fluke 12B Multimeter, I checked for continuity between the body of the device (which had been the shock vector) and the pins of the power plug.  Plugs in Hong Kong look like this:


They are wired like this:




https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets:_British_and_related_types

Power in Hong Kong is color codedThese days, we follow the "New Cable Color Code":


http://phonespeco.com/wiring-electrical-color-code

Findings


  • There was zero resistance between the body of the device and ground (#3)
  • There was infinite resistance between the body of the device and line (#4, #5)
  • There was infinite resistance between the body of the device and neutral (#2)

These results are consistent with a normally functioning device.

"Hot" Power Check

My next move was to take the disco light apart.  In terms of the powered components of the unit, I discovered that it was composed of two modules connected by a wiring harness:

  • A POWER module
  • A LIGHTING module

Securing the unit safely on a level, non-conductive surface, I very carefully plugged it into a switched power bar outlet (with the outlet turned OFF).  I made sure that the unit was not in contact with me or anything conductive, and turned it on. 

Here's what I saw:



Once again, the unit appeared to be functioning normally.  I tested various points around the unit for voltage leaks by placing the black lead of my multimeter on the grounding bolt and probing around the unit with the red lead.  While doing so, I detected 0V at the steel base of the POWER module, 3V at the steel base of the LIGHTING module, and 12V at the back of the motor, which is responsible for an "extra" disco effect.  While detecting any leaking voltage is undesirable, what I found was insufficient to cause the kind of shock my friend described.
 

Mechanical Inspection

Increasingly puzzled by this situation, I took a closer look at how the unit was mechanically constructed.  

  • The first thing I noticed was that the LIGHTING module fit into the body of the device by friction alone; it slid under two flanges.  It could therefore be accidentally displaced within the device by a physical blow or by being oriented at too steep an angle.
  • The second thing I noticed that the front plate of the lighting module was supposed to be spot welded to a front plate that held a glass lens.  At some point, the welds had failed.

Mechanical Failure + Design Flaw = Death?

This led me to an interesting conclusion.  The hypothesis I came to was that my friend had been shocked because the LIGHTING module had slid too far back into the device, coming into contact with the transformer mounted on the POWER module.  This would have conducted 230VAC through the back of the motor (which was metal) through to the external shell of the device (which was metal). 

The Solution

Once I knew what was wrong, I knew what I needed to do to make this unit safe again.  I took a plastic lid (which I don't need) from one of the containers I use to organize my work bench and started cutting it up:


 I hot glued a circular piece of plastic to the back of the motor, isolating it electrically.


Then, I traced out a larger circle on the plastic lid...


...and hot glued it to the POWER module, leaving a notch for the wires that connect it to the LIGHTING module:


At this point, the unit was very well isolated electrically, but I still wanted to do something about the mechanical failure.  

So what I did was put the unit together in such a way that the connecting flange was on the outside of the unit rather than in its normal position, which is inside.


I then drilled a hole through both the flange and the face plate:


I then I took the unit apart once more.  I colored the flange black with a marker, partly to prevent rust, partly to integrate the flange (which was now somewhat exposed) visually with the color of the rest of the unit.  It wasn't really necessary, but why not?


Finally, I re-assembled the unit with everything in the correct order, meaning the flange was now inside.  I re-united the the LIGHTING module flange with the face plate using a nut and bolt - that type of mechanical connection will not fail any time soon!



Final Testing

I tested the unit once again for voltage leaks.  There were none.   It seemed safe.  I also took the disco light to my balcony and shined it on a large tree about 30 feet away. To my delight and satisfaction, the disco light seemed to work just fine: 




Party On!

Based on my testing, the FX LAB disco light appeared to be both safe and 100% fully functional. 

It was ready to be put back into service once again.

 finis


 

Wednesday, March 22, 2017

(iMac) Ubuntu Install Gone Wrong? Install by Hand! (2 of 2)


Here's What To Do When The Above Happens To Your Linux Install!


**This article is a continuation of (iMac) Ubuntu Install Gone Wrong? Install by Hand! (1 of 2)**

Creating a Basic Linux Operating Environment

Linux requires a minimal set of files and directories to do its work.  Thanks to the Ubuntu Trusty Tahir Install DVD, we have access to a semi-functioning operating system with almost everything we need.  Here's an overview of the operating environment that the Ubuntu Trusty Tahir Install DVD creates:

root@sentinel:/# ls -l
total 2
drwxr-xr-x   2 root root 2955 Aug  3  2016 bin
drwxr-xr-x   1 root root   60 Aug  3  2016 boot
dr-xr-xr-x   1 root root 2048 Aug  3  2016 cdrom
drwxr-xr-x  18 root root 4300 Mar 17 01:28 dev
drwxr-xr-x   1 root root  740 Mar 17 04:07 etc
drwxr-xr-x   1 root root   80 Mar 16 23:54 home
lrwxrwxrwx   1 root root   32 Aug  3  2016 initrd.img -> initrd.img-4.4.0-31-generic
drwxr-xr-x   1 root root   60 Aug  3  2016 lib
drwxr-xr-x   2 root root   43 Aug  3  2016 lib64
drwxr-xr-x   1 root root   60 Mar 16 23:49 media
drwxr-xr-x   1 root root   60 Mar 17 04:07 mnt
drwxr-xr-x   2 root root    3 Aug  3  2016 opt
dr-xr-xr-x 164 root root    0 Mar 16 23:48 proc
drwxr-xr-x  21 root root  338 Aug  3  2016 rofs
drwx------   1 root root   80 Mar 17 00:10 root
drwxr-xr-x  22 root root  720 Mar 17 01:11 run
drwxr-xr-x   2 root root 4885 Aug  3  2016 sbin
drwxr-xr-x   2 root root    3 Aug  3  2016 srv
dr-xr-xr-x  13 root root    0 Mar 17 03:07 sys
drwxrwxrwt   4 root root  100 Mar 17 04:17 tmp
drwxr-xr-x   1 root root  120 Aug  3  2016 usr
drwxr-xr-x   1 root root  120 Aug  3  2016 var
lrwxrwxrwx   1 root root   29 Aug  3  2016 vmlinuz -> boot/vmlinuz-4.4.0-31-generic

There are many entries in this list.  Some require special treatment, some don't:

  • Certain directories (/dev, /proc and /sys) needn't be copied because they are virtual and/or created by the system when the kernel boots, they just need to be created so the kernel has something to "hook" onto.
  • Certain directories (/cdrom, /mnt, /media) shouldn't be copied because they either contain the newly mounted hard disk (/mnt) or the Ubuntu Trusty Tahir Install DVD (/cdrom, /media) and just might potentially create a copy loop.  They just need to be created.
  • Certain directories (/rofs) are unique to the Ubuntu installation DVD and are not needed for a live Linux system.
  • One directory (/boot) needs to be handled specially.
  • The logical links (initrd.img & vmlinuz) are both broken and they will need to be (re)linked properly to files in the /boot directory, once those file are installed.
  • The rest of the directories can simply be copied over with the cp command.

Directories to Create with mkdir:

Here are the directories we can simply create with the mkdir command:

/boot
/dev
/cdrom
/media/mnt
/proc
/sys


Here are the commands required to accomplish that:


root@sentinel:/# cd /mnt/hdd
root@sentinel:/mnt/hdd# mkdir bootroot@sentinel:/mnt/hdd# mkdir devroot@sentinel:/mnt/hdd# mkdir cdrom 
root@sentinel:/mnt/hdd# mkdir media
root@sentinel:/mnt/hdd# mkdir mnt
root@sentinel:/mnt/hdd# mkdir proc
root@sentinel:/mnt/hdd# mkdir sys

Here's what the /mnt/hdd directory looked like after these operations:


root@sentinel:/mnt/hdd# ls -l
total 40
drwxr-xr-x  2 root root  4096 Mar 17 04:34 boot
drwxr-xr-x 18 root root  4380 Mar 22 01:53 dev
drwxr-xr-x  2 root root  4096 Mar 17 04:34 cdrom
drwx------  2 root root 16384 Mar 17 01:31 lost+found
drwxr-xr-x  2 root root  4096 Mar 17 09:27 media
drwxr-xr-x  2 root root  4096 Mar 17 04:34 mnt
drwxr-xr-x  2 root root  4096 Mar 17 04:34 proc
drwxr-xr-x  2 root root  4096 Mar 17 04:34 sys

Except for the /boot directory, these can all be left as they were created.  

Directories to Copy with cp:

The following directories can be copied to the Linux partition via the command cp -a:

/bin
/etc

/home
/lib
/lib64
/opt
/root
/run
/sbin
/srv
/tmp
/usr
/var


Here's how that was done:


root@sentinel:/mnt/hdd# cp -a /bin .
root@sentinel:/mnt/hdd# cp -a /etc .
root@sentinel:/mnt/hdd# cp -a /home .
root@sentinel:/mnt/hdd# cp -a /lib .
root@sentinel:/mnt/hdd# cp -a /lib64 .
root@sentinel:/mnt/hdd# cp -a /opt .
root@sentinel:/mnt/hdd# cp -a /root .
root@sentinel:/mnt/hdd# cp -a /run .
root@sentinel:/mnt/hdd# cp -a /sbin .
root@sentinel:/mnt/hdd# cp -a /srv .
root@sentinel:/mnt/hdd# cp -a /tmp .
root@sentinel:/mnt/hdd# cp -a /usr .
root@sentinel:/mnt/hdd# cp -a /var .

Here's what the /mnt/hdd directory looked like after all the operations:


root@sentinel:/mnt/hdd# ls -l
total 96

drwxr-xr-x   2 root root  4096 Aug  3  2016 bin
drwxr-xr-x   3 root root  4096 Mar 19 07:26 boot
drwxr-xr-x   2 root root  4096 Mar 17 04:34 cdrom
drwxr-xr-x  18 root root  4380 Mar 22 01:53 dev
drwxr-xr-x 132 root root 12288 Mar 22 01:53 etc
drwxr-xr-x   4 root root  4096 Mar 16 23:54 home
drwxr-xr-x  27 root root  4096 Mar 21 14:42 lib
drwxr-xr-x   2 root root  4096 Mar 21 14:42 lib64
drwx------   2 root root 16384 Mar 17 01:31 lost+found
drwxr-xr-x   4 root root  4096 Mar 21 14:41 media
drwxr-xr-x   2 root root  4096 Mar 17 04:34 mnt
drwxr-xr-x   2 root root  4096 Aug  3  2016 opt
dr-xr-xr-x 149 root root     0 Mar 22 01:52 proc
drwx------  19 root root  4096 Mar 21 14:48 root
drwxr-xr-x  21 root root   720 Mar 22 01:56 run
drwxr-xr-x   2 root root 12288 Mar 21 09:39 sbin
drwxr-xr-x   2 root root  4096 Aug  3  2016 srv
dr-xr-xr-x  13 root root     0 Mar 22 02:36 sys
drwxrwxrwt   4 root root    80 Mar 22 02:17 tmp
drwxr-xr-x  11 root root  4096 Mar 21 14:42 usr
drwxr-xr-x  13 root root  4096 Aug  3  2016 var

OK, we are very close to being done.  The work that remains is:


  • Deal With the /boot Directory 
  • Create the vmlinuz and initrd.img Symbolic Links
  • Change /mnt/hdd/etc/hostname to the new name for this machine (sentinel)
  • Change the root (/) of the system to /mnt/hdd
  • Use the grub commands to activate the hard disk as the primary boot device 
  • Ensure ssh is available on after a reboot
  • Reboot to see what fortune brings!


Deal With the /boot Directory 

The /boot directory is really important, because it's where all of the Linux startup files are kept.   Unfortunately, the /boot directory that is set up by the Ubuntu Install DVD is missing critical files (vmlinuz, initrd.img).  

The broken links at the root of the Ubuntu Install file system are a clue of that; they are red because the target files are missing:

initrd.img -> initrd.img-4.4.0-31-generic
vmlinuz -> boot/vmlinuz-4.4.0-31-generic


These files are listed in an Ubuntu Packages page for Trusty Tahir.

The symbolic links indicate that the system once had initrd.img and vmlinuz files of version 4.4.0-31-generic installed in the /boot directory, but they have somehow gone missing.  Here's what a "normal" /boot directory looks like.  It's from silver, a post-install Linux Ubuntu Trusty Tahir (14.04.5) machine that I built some time ago.  silver has since been upgraded a few times, and it shows.  There are several different versions of initrd.img and vmlinuz files on it:


root@silver:/boot# ls -l
total 98900
-rw-r--r-- 1 root root  1208829 Jun 29  2016 abi-3.16.0-77-generic
-rw-r--r-- 1 root root  1245512 Feb 20 22:14 abi-4.4.0-64-generic
-rw-r--r-- 1 root root  1245512 Mar  4 04:19 abi-4.4.0-66-generic
-rw-r--r-- 1 root root   171880 Jun 29  2016 config-3.16.0-77-generic
-rw-r--r-- 1 root root   190255 Feb 20 22:14 config-4.4.0-64-generic
-rw-r--r-- 1 root root   190255 Mar  4 04:19 config-4.4.0-66-generic
drwxr-xr-x 5 root root     4096 Mar 19 21:11 grub
-rw-r--r-- 1 root root 20202512 Feb 11 17:10 initrd.img-3.16.0-77-generic
-rw-r--r-- 1 root root 22284925 Mar  2 11:33 initrd.img-4.4.0-64-generic
-rw-r--r-- 1 root root 22284241 Mar 12 12:07 initrd.img-4.4.0-66-generic
-rw-r--r-- 1 root root   176500 Mar 12  2014 memtest86+.bin
-rw-r--r-- 1 root root   178176 Mar 12  2014 memtest86+.elf
-rw-r--r-- 1 root root   178680 Mar 12  2014 memtest86+_multiboot.bin
-rw------- 1 root root  3520509 Jun 29  2016 System.map-3.16.0-77-generic
-rw------- 1 root root  3897401 Feb 20 22:14 System.map-4.4.0-64-generic
-rw------- 1 root root  3897401 Mar  4 04:19 System.map-4.4.0-66-generic
-rw------- 1 root root  6376256 Jun 29  2016 vmlinuz-3.16.0-77-generic
-rw------- 1 root root  6989456 Feb 20 22:14 vmlinuz-4.4.0-64-generic
-rw------- 1 root root  6989392 Mar  4 04:19 vmlinuz-4.4.0-66-generic

Looking over the silver file listing, it seems that sentinel needed the following files to be able to boot properly:


  • System.map
  • abi
  • config 
  • vmlinuz
  • initrd.img


What do These Files Do? 


System.map:
"In Linux, the System.map file is a symbol table used by the kernel. A symbol table is a look-up between symbol names and their addresses in memory. A symbol name may be the name of a variable or the name of a function"
-- https://en.wikipedia.org/wiki/System.map


abi:
"In computer software, an application binary interface (ABI) is the interface between two program modules, one of which is often a library or operating system, at the level of machine code. An ABI determines such details as how functions are called and in which binary format information should be passed from one program component to the next, or to the operating system in the case of a system call."
-- https://en.wikipedia.org/wiki/Application_binary_interface


config:
"The config file contains kernel configuration settings. It is created when a kernel is built with the “make menuconfig” command. The settings in this file are changed depending on the options selected in “make menuconfig” command. The contents of this file affect which modules are loaded when the kernel boots."
-- http://www.linuxnix.com/linux-directory-structure-explained-boot-folder


vmlinuz:
"vmlinuz is the name of the Linux kernel executable.  A kernel is a program that constitutes the central core of a computer operating system. It is the first thing that is loaded into memory (which physically consists of RAM chips) when a computer is booted up (i.e., started), and it remains in memory for the entire time that the computer is in operation. An executable, also called an executable file, is a file that can be run as a program.  vmlinuz is a compressed Linux kernel, and it is bootable."
-- http://www.linfo.org/vmlinuz.html


initrd.img:
"The initial RAM disk (initrd) is an initial root file system that is mounted prior to when the real root file system is available. The initrd is bound to the kernel and loaded as part of the kernel boot procedure. The kernel then mounts this initrd as part of the two-stage boot process to load the modules to make the real file systems available and get at the real root file system."
-- http://advancelinux.blogspot.hk/2013/06/what-is-initrd-image-in-linux.html


What Files Do We Have?

We have the following files:

root@sentinel:/# cd /boot
root@sentinel:/boot# ls -1 /boot/*-generic
/boot/abi-4.4.0-31-generic
/boot/config-4.4.0-31-generic
/boot/System.map-4.4.0-31-generic

What Files Are Missing?

We are missing the following files:

vmlinuz-4.4.0-31-generic
initrd.img-4.4.0-31-generic

Eventually, I was able to find these files Ubuntu Trusty Tahir Install DVD, but the matter was made confusing by the fact that they had been saved without version numbers.  They were located in the /cdrom/casper directory:


root@sentinel:/# cd /cdrom/casper
root@sentinel:/cdrom/casper# ls -l
total 1061139
-r--r--r-- 1 root root      61004 Aug  3  2016 filesystem.manifest
-r--r--r-- 1 root root       1067 Aug  3  2016 filesystem.manifest-remove
-r--r--r-- 1 root root         11 Aug  3  2016 filesystem.size
-r--r--r-- 1 root root 1055989760 Aug  3  2016 filesystem.squashfs
-r--r--r-- 1 root root        933 Aug  3  2016 filesystem.squashfs.gpg
-r--r--r-- 1 root root   23614105 Aug  3  2016 initrd.lz
-r--r--r-- 1 root root    6937248 Aug  3  2016 vmlinuz

Finding vmlinuz-4.4.0-31-generic:
How could I be so sure that the vmlinuz file I found in the /cdrom/casper was the right one?  Because I checked it against existing vmlinuz versions by file size (6937248).  After doing some research, I found out that there was only one vmlinuz file of that exact size, and that was vmlinuz-4.4.0-31-generic.  Its even listed on this Ubuntu documentation page, which contains the following:

18 -rw-r--r-- 1 root root 6937248 Des 20 22:49 vmlinuz-4.4.0-31-generic

Another important consideration was that the listed vmlinuz matched the version of the kernel that was currently running on sentinel:


root@sentinel:/boot# uname -a
Linux sentinel 4.4.0-31-generic #50~14.04.1-Ubuntu SMP Wed Jul 13 01:07:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

So I felt pretty safe in my feeling that the vmlinuz file in /cdrom/casper was version actually vmlinuz-4.4.0-31-generic.  So I copied the file it to the /boot directory with the proper version annotation:

root@sentinel:/# cd /mnt/hdd/boot
root@sentinel:/mnt/hdd/boot# cp /cdrom/casper/vmlinuz ./vmlinuz-4.4.0-31-generic

Finding initrd.img-4.4.0-31-generic:
With vmlinuz installed, I only needed initrd.img-4.4.0-31-generic to complete my complement of needed boot files.  As I had already found a version of initrd in the /cdrom/casper directory, I looked at it:

root@sentinel:/mnt/hdd/boot# ls -l /cdrom/casper/initrd.lz
-r--r--r-- 1 root root 23614105 Aug  3  2016 /cdrom/casper/initrd.lz


Huh?  

The file I was looking for was initrd.img, not initrd.lz - was there going to be a problem?  As it turns out, no, but it took quite some time for me to discover what exactly an initrd.img file was and what formats it could come in (.gz, .lz).  In the end, I determined that I could copy the file over to the /boot directory with a different extension and the proper version annotation:

root@sentinel:/mnt/hdd/boot# cp /cdrom/casper/initrd.lz ./initrd.img-4.4.0-31-generic

Now I had all of the files I thought I needed to boot Linux:

root@sentinel:/mnt/hdd/boot# ls -1
abi-4.4.0-31-generic
config-4.4.0-31-generic
initrd.img-4.4.0-31-generic
System.map-4.4.0-31-generic

vmlinuz-4.4.0-31-generic

Create the vmlinuz and initrd.img Symbolic Links

One of the easier tasks in this list is to create the symbolic links at the root of the filesystem to their counterparts in the /boot subdirectory:


root@sentinel:/# cd /mnt/hdd
root@sentinel:/mnt/hdd# ln -s ./boot/vmlinuz-4.4.0-31-generic vmlinuz
root@sentinel:/mnt/hdd# ln -s ./boot/initrd.img-4.4.0-31-generic initrd.img


chroot the System (to /mnt/hdd)

The next stage of the install is to change the root of the system to the hard disk.  this is accomplished with the chroot command:


root@sentinel:/# mkdir /mnt/hdd
root@sentinel:/# mount /dev/sda2 /mnt/hdd
root@sentinel:/# chroot /mnt/hdd

Tweak the Newly chroot-ed System:

A little bit of tweaking is required to make the newly chroot-ed system functional.

  • Re-establish /proc:
  • Re-establish /sys:
  • Re-establish /dev:
  • Re-establish /dev/pts:

Here's the commands to do it:


root@sentinel:/# mount -t proc proc /proc 
root@sentinel:/# mount -t sysfs sys /sys
root@sentinel:/# mount -o bind /dev /dev
root@sentinel:/# mount -t devpts devpts /dev/pts
(https://superuser.com/questions/165116/mount-dev-proc-sys-in-a-chroot-environment)

Housekeeping

A little bit of updating was necessary to make the newly chrooted system fully functional:

root@sentinel:/# apt-get update
.
.
.
(lots of output)
root@sentinel:/# apt-get install aptitude
.
.
.
(lots of output)

Configure & (re)Install GRUB2

Now we need to provision and install grub (actually grub2).  grub is the system that actually manages how the computer boots Linux.  Most of the configuration files for grub are located at /boot/grub, but a very important grub configuration file is also located at /etc/default/grub.  It needs some changes made.

From this:


# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

to this:


# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
#GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash text"
GRUB_CMDLINE_LINUX="text"

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
 
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"  

Don't forget to save your work.

Prepare the New Boot Environment With update-grub:

The update-grub command is used to update the grub boot environment in preparation for installation on the preferred boot device (in our case, /dev/sda):


root@sentinel:/boot/grub# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-31-generic
Found initrd image: /boot/initrd.img-4.4.0-31-generic
done

Install the New Boot Environment With grub-install:

The grub-install command is used to install grub on the preferred boot device (in our case, /dev/sda):


root@sentinel:/boot/grub# grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

Ensure SSH is Available on Boot:
The one thing that we want to be absolutely sure of is that the Secure Shell (ssh) service is available after a reboot, because this iMac has a history of video driver problems and a console that is unusable about 90% of the time.  

First, because we are operating in a chroot-ed environment, we need to re-install ssh on the machine:


root@sentinel:/etc/default# apt-get install --reinstall ssh
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 223 not upgraded.
Need to get 0 B/1,118 B of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 178224 files and directories currently installed.)
Preparing to unpack .../ssh_1%3a6.6p1-2ubuntu2.8_all.deb ...
Unpacking ssh (1:6.6p1-2ubuntu2.8) over (1:6.6p1-2ubuntu2.8) ...

Setting up ssh (1:6.6p1-2ubuntu2.8) ...


Next, we need to make sure that ssh is available at all times.  This is accomplished by programming the machine to start the ssh server at all runlevels (2-5except for single-user mode (1), where having an ssh server available wouldn't make sense, because TCP/IP is usually turned off.


root@sentinel:/# cd /mnt/hdd/etc/rc2.d
root@sentinel:/mnt/hdd/etc/rc2.d# ln -s ../init.d/ssh S99ssh
root@sentinel:/mnt/hdd/etc/rc2.d# cd ../rc3.d
root@sentinel:/mnt/hdd/etc/rc3.d# ln -s ../init.d/ssh S99ssh
root@sentinel:/mnt/hdd/etc/rc3.d# cd ../rc4.d
root@sentinel:/mnt/hdd/etc/rc4.d# ln -s ../init.d/ssh S99ssh
root@sentinel:/mnt/hdd/etc/rc4.d# cd ../rc5.d
root@sentinel:/mnt/hdd/etc/rc5.d# ln -s ../init.d/ssh S99ssh
root@sentinel:/mnt/hdd/etc/rc5.d# cd ../rc5.d

Confirm Everything & Shut Down

At this point, it's advisable to test the new grub environment with a cold start.  This can be accomplished with the shutdown command:


root@sentinel:/boot/grub# shutdown -P now
root@sentinel:/boot/grub#
Broadcast message from graham@sentinel
        (/dev/pts/0) at 13:29 ...

After it had powered down, I turned  the iMac back on by pressing the power button on the back left corner.  There was a chime and I needed to wait about a minute for the machine to boot, during which I saw a parade of crazy looking screens:


Yes, the way sentinel boots is over a minute long and a crazy looking, but in the end I got what I wanted, which was:  (1) A persistent operating environment; and (2) A consistently presented command prompt:



finis



References


Ubuntu 14.04, 13.10: Boot into Text Mode / Console / Command Line
http://ubuntuhandbook.org/index.php/2014/01/boot-into-text-console-ubuntu-linux-14-04/ 


low resolution in plymouth screen with nvidia-current
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/565980