February 2012 Archives

Where did my hard drive go?

| No TrackBacks
I've been trying to rsync a 1TB filesystem for a few days, mostly from firewire and most recently from USB. Running Firewire, here's what popped up in the logs:

[5776217.857647] Filesystem "sdb1": xfs_log_force: error 5 returned.

And of course, rsync bombed, there was gnashing of teeth, and the kernel/XFS weren't happy. /dev/sdb had disappeared. I tried moving it to a different controller (I have three firewire ports on that PC), and finally to USB with the same results every time... The drive/rsync would go for a while, then fail. And not recover. I reset the hard drive by unplugging the 12V power input cable from the back, and later noticed that simply unplugging it from firewire/USB was enough, provided I left it disconnected long enough for the devices to be deleted from /dev & friends. The drive was a Firewire/USB Western Digital MyBook drive I had borrowed. I haven't had a lot of faith in the devices since I bought a MyBook2 and found it was completely unable to be used as a boot device for a Mac. Unfortunately, that's the one sure-fire way to backup a Macintosh -- install Mac OSX to an external drive, then move over the applications and preferences of the users.

Here's the dmesg when I moved it to USB:

[5788570.588332] usb 5-6: new high speed USB device using ehci_hcd and address 8
[5788570.737577] usb 5-6: configuration #1 chosen from 1 choice
[5788570.742572] scsi25 : SCSI emulation for USB Mass Storage devices
[5788570.743242] usb-storage: device found at 8
[5788570.743246] usb-storage: waiting for device to settle before scanning
[5788570.744481] usb 5-6: New USB device found, idVendor=1058, idProduct=1112
[5788570.744486] usb 5-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[5788570.744489] usb 5-6: Product: My Book 1112
[5788570.744493] usb 5-6: Manufacturer: Western Digital
[5788570.744496] usb 5-6: SerialNumber: 574341563539313134373334
[5788575.820168] usb-storage: device scan complete
[5788575.826172] scsi 25:0:0:0: Direct-Access     WD       My Book 1112     1009 PQ: 0 ANSI: 4
[5788575.830661] scsi 25:0:0:1: Enclosure         WD       SES Device       1009 PQ: 0 ANSI: 4
[5788575.835334] sd 25:0:0:0: [sdb] 1952151552 512-byte hardware sectors (999502 MB)
[5788575.836495] sd 25:0:0:0: [sdb] Write Protect is off
[5788575.836495] sd 25:0:0:0: [sdb] Mode Sense: 23 00 10 00
[5788575.836495] sd 25:0:0:0: [sdb] Assuming drive cache: write through
[5788575.842777] sd 25:0:0:0: [sdb] 1952151552 512-byte hardware sectors (999502 MB)
[5788575.844493] sd 25:0:0:0: [sdb] Write Protect is off
[5788575.844493] sd 25:0:0:0: [sdb] Mode Sense: 23 00 10 00
[5788575.844493] sd 25:0:0:0: [sdb] Assuming drive cache: write through
[5788575.844493]  sdb: sdb1
[5788575.863526] sd 25:0:0:0: [sdb] Attached SCSI disk
[5788575.863650] ses 25:0:0:1: Attached Enclosure device

Then mounted the XFS file system..

[5788585.568840] XFS mounting filesystem sdb1
[5788586.331150] Ending clean XFS mount for filesystem: sdb1

And then when the device decided to go to sleep, doing 15MB/s.

[5790392.964797] usb 5-6: reset high speed USB device using ehci_hcd and address 8
[5790905.294369] usb 5-6: reset high speed USB device using ehci_hcd and address 8

(x400).

I started doing some Googling, which lead me to a number of pages about
hdparm and sdparm.

This one gave me the basic idea, but the syntax didn't work except for "sdparm -al $device".

This command foreshadowed most of my investigation:

# sdparm -c STANDBY -6 /dev/sdb1
    /dev/sdb1: WD        My Book 1112      1009
change_mode_page: failed setting page: Power condition

 
This one provided some ideas and a little more clue.

This one proved exceptionally useful, once I got the syntax down and figured out how to set the flags and save them.

First I had to set the drive to auto_restart using :

"echo 1 > /sys/class/scsi_disk/$id/allow_restart"

# echo 1 > /sys/class/scsi_disk/25\:0\:0\:0/allow_restart
# echo 1 > /sys/class/scsi_disk/3\:0\:0\:0/allow_restart

Then set the STANDBY flag to zero, so the drive will start...

But first, I figured out how to set the SCT (Standby Timer) to a high value. It maxed out at 288000. 288000 in 100ms chunks is 28800 seconds, double of 14,400, which is one day.

# sdparm -al /dev/sdb
    /dev/sdb: WD        My Book 1112      1009
    Direct access device specific parameters: WP=0  DPOFUA=1
Power condition [po] mode page:
  IDLE        0  [cha: n, def:  0, sav:  0]  Idle timer active
  STANDBY     1  [cha: y, def:  1, sav:  1]  Standby timer active
  ICT         0  [cha: n, def:  0, sav:  0]  Idle condition timer (100 ms)
  SCT      6000  [cha: y, def:6000, sav:6000]  Standby condition timer (100 ms)

Well, that's no good. Set is -s, so let's see if that can be turned up.

# sdparm -s STANDBY=0 -6 --save /dev/sdb
    /dev/sdb: WD        My Book 1112      1009


# sdparm -al /dev/sdb
    /dev/sdb: WD        My Book 1112      1009
    Direct access device specific parameters: WP=0  DPOFUA=1
Power condition [po] mode page:
  IDLE        0  [cha: n, def:  0, sav:  0]  Idle timer active
  STANDBY     1  [cha: y, def:  1, sav:  1]  Standby timer active
  ICT         0  [cha: n, def:  0, sav:  0]  Idle condition timer (100 ms)
  SCT       288000  [cha: y, def:6000, sav:288000]  Standby condition timer (100 ms)
#

Bonus. But wait, that means that STANDBY can be set to 0, and saved...

# sdparm -s STANDBY=0 -6 --save /dev/sdb
    /dev/sdb: WD        My Book 1112      1009
#

No errors... looks good.


# sdparm -al /dev/sdb
    /dev/sdb: WD        My Book 1112      1009
    Direct access device specific parameters: WP=0  DPOFUA=1
Power condition [po] mode page:
  IDLE        0  [cha: n, def:  0, sav:  0]  Idle timer active
  STANDBY     0  [cha: y, def:  1, sav:  0]  Standby timer active
  ICT         0  [cha: n, def:  0, sav:  0]  Idle condition timer (100 ms)
  SCT       288000  [cha: y, def:6000, sav:288000]  Standby condition timer (100 ms)
#

The system started behaving as if the drive were online. Imagine my surprise when I switched terminals and found that rsync was happily copying data!  

So that's how you turn off the power management for a Western Digital MyBook portable hard drive.

Edit: It's not always effective. Sometimes it still refuses to wake up. But now it takes a long time to go to sleep. 


PE-75 Generator Manual TM 11-900

| No TrackBacks
Original Post: 02-20-2012 @ 1:17:40

PE-75 Power Unit

2.5KW Generator, 120V, 22.5A, 1800 RPM
6.5HP Briggs & Stratton Model ZZ (with 'antique' updraft carburetor), 2400 RPM

330 lbs, mounted to steel frame.

Yes, I have a manual. Here's Part I, V1.0 of it:

[removed]

This is also known as TM 11-900.


This monster was a part of an SCR-197.

Here's some other manuals I found on the web. Mine, as you note, is slightly different:

http://blog.catonic.us/kirby/PE-75/

Edit: 6/25/2012

Now I have the whole manual. Both of these are about 10MB:

TM 11-900
TM 11-900 rotated for readability

My manual is copyright by me, Kris Kirby. All rights reserved. This manual may be used for non-commercial purposes only. This manual may not be included in derivative works, or compilations of works (i.e.: CDROM collections), or sold on eBay either in print form or on electronic media.

Please contact me if you have a desire to include the manual in distributed works; we may be able to come to an understanding.

I have much higher quality versions of this document already scanned at over 150 DPI, uncompressed. I'd be happy to work out a license for the higher quality works and/or commercial uses.

DRM hasn't been included in these works because I believe strongly in portability. My original manual was printed/produced in the 1940s. It has survived this long, but it will not survive forever. It is my desire to preserve this information, but not exploit it. It took me a long time to scan, process, and so on. And you'll note from the document that I didn't always get everything straight. I don't seek to recoup my time, energy, and hard drive space. But there is a significant personal investment of each of those.

If there's something you can't read on a page, let me know. I may be able to re-scan the page and change the documents. It was stored in the accessory box of the generator, so it is filthy and does tend to leave specks behind on the scanner.

I can be reached at kris ]a()t[ catonic d0t us.

Bless me Father, for I have sinned...

| No TrackBacks
... I have committed great atrocities against Mac OSX....

Based on the info at Bombich.com about blessing folders to make them bootable, I found that it was necessary to do a little bit more.

# bless --info "/Volumes/FW1"
finderinfo[0]: 187 => Blessed System Folder is /Volumes/FW1/System/Library/CoreServices
finderinfo[1]: 746345 => Blessed System File is /Volumes/FW1/System/Library/CoreServices/boot.efi
finderinfo[2]: 0 => Open-folder linked list empty
finderinfo[3]: 0 => No OS 9 + X blessed 9 folder
finderinfo[4]: 0 => Unused field unset
finderinfo[5]: 187 => OS X blessed folder is /Volumes/FW1/System/Library/CoreServices

Quoth:

The relevant information in this case is that the blessed system folder is at inode 116, and that path (for the human reader) is /System/Library/CoreServices. PowerPC-based Macs need only this piece of information to boot. PPC Open Firmware will find that directory, then execute the file named "BootX" within that directory. Intel-based Macs also use the "Blessed System File" information. In this case, that is the file at inode 546345 and (again, for the human reader), that file is located at /System/Library/CoreServices/boot.efi.

If you ever need to bless a volume manually (for example, if CCC indicated that it was unable to bless the volume), you could run this command in the Terminal application:

sudo bless -folder "/Volumes/Backup/System/Library/CoreServices"

It is important to note that blessing a volume is different than specifying a boot device. Blessing a volume simply updates the information in the HFS Volume Header that indicates where the blessed system folder and file are located. When you specify a particular volume as the startup disk, on the other hand, the computer stores a reference to that volume in the "Non volatile RAM" -- basically a small section of RAM whose contents are not lost when the machine loses power or is shutdown. The importance of this disctinction, and all four of these rules for that matter, is that simply setting a volume as the startup disk may not be sufficient to actually boot from that volume.

In my particular case, executing the above "bless" resulted in a single folder that was blessed, so FW1B, the backup/rsync copy of FW1, wasn't blessed the same. Turns out the fix is simple, thanks to the man page for bless:

sudo bless -folder "/Volumes/FW1B/System/Library/CoreServices" -file "/Volumes/FW1B/System/Library/CoreServices/boot.efi"

And that's how you make it bootable. This is Mac OSX 10.6.7, I think.

The long story made short is that I wound up with two system images on a single hard drive, one of which could *not* be shrunk below 145GB, despite having 40GB of free space. It appears that limit is due to another partition on the same drive not being 145G+145G away from the original image. Once both images are shrunk, the 105GB images will fit on a single 320GB drive, giving me back my 1TB drive.

This link was used to form the basis of that rsync. I used the built-in rsync from /usr/bin/rsync, rather than another product.

The basic process was:

1) Blank disk
2) Partition disk
3) rsync from original disk partition #1 to target disk partition #1
4) rsync from original disk partition #2 to target disk partition #2
5) bless files & folders on target disk partition #1 to match blessed folders on original disk partition #1.
6) test booting from target disk partition #1.

Resetting a DVD Burner gone wonky

| No TrackBacks
After attempting to burn a DVD, I started receiving these messages in the log, and all over the root terminal. Naturally, this made it hard to be root and fix the problem.

Feb 18 22:19:31 secondlt kernel: [5643777.542654] hdb: status error: status=0x58 { DriveReady SeekComplete DataRequest }
Feb 18 22:19:31 secondlt kernel: [5643777.542659] ide: failed opcode was: unknown
Feb 18 22:19:31 secondlt kernel: [5643777.542719] hdb: status error: status=0x58 { DriveReady SeekComplete DataRequest }
Feb 18 22:19:31 secondlt kernel: [5643777.542724] ide: failed opcode was: unknown
Feb 18 22:40:19 secondlt kernel: [5645187.666411] hdb: status error: status=0x58 { DriveReady SeekComplete DataRequest }
Feb 18 22:40:19 secondlt kernel: [5645187.666411] ide: failed opcode was: unknown

Well, this wasn't made any easier because hald was polling that device every two seconds:

# ps -ax | grep "hal"
Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html
19265 ?        Ss     0:00 /usr/sbin/hald
19266 ?        S      0:00 hald-runner
19284 ?        S      0:00 hald-addon-input: Listening on /dev/input/event3 /dev/input/event2 /dev/input/event1
19292 ?        S      0:00 /usr/lib/hal/hald-addon-cpufreq
19293 ?        S      0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
19298 ?        S      0:00 hald-addon-storage: polling /dev/hdb (every 2 sec)
19372 pts/1    S+     0:00 grep hal
#

So step 1 was to kill -HUP the hald process, 19298. Fortunately, it didn't come back. Next was to head into the man pages on hdparm and see if there was a flag that could reset the device. There is, it's "-w". The man page notes it is an extremely dangerous flag.

# hdparm -w /dev/hdb
device reset
#

Then restart hald:

# /etc/init.d/hal restart

Check the logs again:
Feb 18 22:40:19 secondlt kernel: [5645187.666751] hdb: DMA disabled
Feb 18 22:40:19 secondlt kernel: [5645187.714462] hdb: ATAPI reset complete
Feb 18 22:40:50 secondlt kernel: [5645221.270844] cdrom: This disc doesn't have any tracks I recognize!

Ok, that last one means I have a burnable DVD loaded and can restart the burning program.

This is all well and good, because I really didn't want to shut the virtual machines down to reboot the system.

Which brings me to another topic: always run ntpd on your virtual machines. When the system suspends them, they loose track of time. So much so that it may be easier to stop ntp, ntpdate, and then restart ntp after a reboot/suspend action.

VMotion is damn cool technology, but not worth the $50,000 if you're just lazy and don't care to take a chance with losing a system. OTOH, if you're doing VMotion, you already bought shared storage of some kind.

About this Archive

This page is an archive of entries from February 2012 listed from newest to oldest.

January 2012 is the previous archive.

March 2012 is the next archive.

Find recent content on the main index or look in the archives to find all content.