NOTE: You can destroy your TiVo
and incur great personal injury in any one of
several exotic ways by doing this. Unless you're
comfortable with upgrading PC hardware, working
near unshielded power supplies, understand how
hard drives work, and are not afraid to render
$500+ of equipment useless, do not try
this.
You
will VOID your warranty if you do this.
People
will laugh at you if you break your equipment.
Starting
Equipment:
I've got a Philips Digital
Satellite Receiver/Recorder, AKA DSR6000. This unit
is a combined DirecTV receiver and TiVo
recorder. This hardware does not have an analog to
digital converter so it is unable to record from any
source other than the DirecTV signal. This unit
comes with a single Quantum 40.0 GB AT Fireball lct
20 (Quantum PN QML40000LD-A) drive in it.
The computer
that was used for all the data shuffling is a HP
Kayak XAs with a 500MHz PIII and 380MB RAM. This
machine caused some difficulties for me since I'm
using only SCSI drives rather than IDE.
Software
Needed:
I initially used Dylan's Boot
Disk for backup purposes, but then decided that
I didn't like loosing my computer for the duration
of the copy. I ended up simply using my normal Linux
environment for backups and restores (dd is the same
in both environments) and used Dylan's Boot Disk
only to bless (i.e. partition) the new drive once I
reached that stage.
Stuff to
Read:
You should be familiar with the whole
process before you start. You should read:
- The TiVo
Hack FAQ
- The TiVo
Underground Forum
- The TiVo Upgrade
Article on C|Net
There are
other places out there that will have usefull
information, but these are the best to start
at.
Stuff to
Buy:
While it is possible that you can
simply add a single new drive to your system, this
is greatly discouraged. Adding a drive causes the
TiVo to perform a non-reversible software change on
your master drive. For this and other reasons it's
much better to work with a duplicate drive. You
should buy:
(1) Quantum 40.0 GB AT Fireball
lct 20 (5400 RPM)
(1) 60+ GB slave
drive. Each GB will provide just under 1 hour
of recording time. I used a Maxtor Diamond Max
80 (5400RPM), 81.9 GB capacity as measured by
Maxtor with GD, not G (i.e. 1 GB =
1,000,000,000 bytes, not 1,073,741,824 bytes).
The
Process:
After several false starts this is
the proceedure I ended up using successfully:
- Install the new big drive into the
host machine. I installed mine as the
secondary slave drive (my CDROM is my
secondary IDE master) on the IDE bus.
- Install the original TiVo drive into
the host machine. I installed it as the master
drive on the primary IDE bus.
- Create a backup of the original TiVo
drive:
- Boot into standard Linux
environment (i.e. off of your Linux
install, not the boot disk with its
subset of utilities)
- Create the appropriate ext2 file
system on the larger drive:
cfdisk /dev/hdd
[return]
This will get
you to the point that you can create
file systems, etc. Use the arrow
keys to select [New] and hit
[Return]. Accept whatever is
offered for Size (i.e. hit
[Return] again). Use the
arrow keys to select [Write] and then
[Quit]. You are
now the proud owner of a huge ext2fs
file system.
- Mount the file system:
mkdir /tmp/space
[return] mount /dev/hdd
[return]
- Copy the TiVo drive to an image
on the new file system:
dd
conv=noerror if=/dev/hda
of=/tmp/space/tivodrive.img
[return]
This process
will take a long time. Total time
will vary depending on CPU speed,
etc, but it will be several hours at
a minimum. On my system (see above)
the copy took 5.5 hours. dd will not
provide any status information until
it's finished. If dd reports any
errors then the backup may not be
good. You may want to repeat the
process.
-
Remove the TiVo drive and replace
it with the new backup drive.
-
Copy the image onto the new backup
drive:
dd conv=noerror
if=/tmp/space/tividisk.img
of=/dev/hda [return]
On my system this "restore" took
nearly twelve hours, more than
twice as long as the original
backup. Be patient and let it go.
-
Install backup TiVo drive into
TiVo and verify that everything
works as expected. Make sure you
have the drive set for master (it
should be if you installed the
same way I did above). If you have
problems (TiVo won't start, etc)
repeat (6) above. If things still
fail repeat (1) through (6) above.
-
"Bless" the new large drive:
-
Make certain that only the new
large drive and the CDROM are on
the IDE bus (the drive should
not be the master on the Primary
IDE bus - for some unfathomable
reason BlessTiVo won't work with
a drive in that position)
-
Boot off of Dylan's Boot Disk
-
Login as root (i.e. type root and hit
[return] when prompted)
-
"Bless" the drive:
BlessTiVo /dev/hdd
return
When prompted with a warning, just agree. This is BlessTiVo just
giving you one last chance not to destroy the data currently on the
drive.
-
Install the "blessed" drive into
your TiVo as the slave.
-
Double check all your
connections. Is the Quantum set as
master? Is the Maxtor set as slave?
Do they both have power attached?
What about the IDE ribbon? Did you
re-attach the fan?
-
Boot the TiVo. This may take a few
minutes longer than usual as the
unit recognizes the extra drive and
adjusts itself accordingly.
-
Visit System Information and scroll
down one page. Your new recording
capacity should be "Variable, Up to
108 hours"
Notes:
Some notes on why I did it the
way I did.
Real
Linux:
My everyday desktop environment is
Linux. It seemed a little silly to me to give up
the use of both my computer and my TV while I made
this copy, so I chose to use the dd from a full
install of Linux rather than the stripped version
on Dylan's Boots Disk. This allowed me to simply
background the process and use my computer as I
normally would.
No bs=
with dd:
After wasting days copying with
various dd options I decided to stop trying to
speed things along by changing the data read and
written by dd. When I used bs=1024k (as specified
in the TiVo Hack FAQ) I would often get "Target
Device Not Large Enough" errors. I suspect that
this had to do with dd wanting to be able to write
out a complete 1Mb of data at the end of the disk
and having some subset of that available.
No sync
with dd:
sync caused more copying
difficulties. sync causes dd to pad the input
block with NULs to the ibs-size. What this
basically means is that it make more data and can
cause things to not properly line up if software
is looking for data to being and (more
importantly) end at certain locations.
Copy
through intermediary:
I made a copy of my
master TiVo drive through an intermediate drive
location for one reason: safety. It is possible to
simply copy from the primary TiVo onto the new
backup (this is how most people do it), but
there's a certain risk involved in doing this:
dd conv=noerror if=/dev/hdb
of=/dev/hdd
looks suspiciously like
dd conv=noerror if=/dev/hdd
of=/dev/hdb
The former copies the contents of the primary
slave over the contents of the secondary slave,
the latter does the opposite. Since even a few
bytes from the new drive copied into the wrong
spot on the original drive would render the
original useless, I was uncomfortable with this
arrangement. Initially I simply spent much time
making sure I knew where each drive was and
verifying that the bits came from (and went to)
the expected places by copying to /dev/null:
dd conv=noerror if=/dev/hdb
of=/dev/null
This arrangement copies to contents of the primary
slave to a faux device (/dev/null). This allowed
me to watch the activity light on the drive to
make sure the correct one was blinking. After much
worrying over this it occurred to me that I had a
monstrously huge drive that I could simply use as
a staging ground. Since I would be using a file as
my out (backup) there was little chance of a
2:00am SNAFU happening. Likewise for the restore
to the new drive.
Why this
took me two days too long:
I am extremely
uncomfortable with the shutdown procedure of the
TiVo. Linux (and Unices in general) don't like
just having their power yanked. It doesn't give
them time to clean up their file systems,
etc. Rather than research at all if there would be
a better way of doing this I simply assumed
(poorly) that putting the system into Standby
would be sufficient. While that caused the TiVo to
blank the screen, it didn't accomplish what I
wanted (a different story there).
The problem
from this came after my first successful
backup/restore. I placed the new drive into the
TiVo and started up. After acquiring the satellite
signal the screen went blank. I removed power and
restarted several times. Each time the screen went
blank. I mounted the ext2 file systems on my Linux
box and began examining the boot records of the
TiVo. Everything looked healthy, so I could only
assume that I had an error in the copy that was
causing a kernel panic during boot. I started over
and made fresh copies of the drive, etc. A full
two days later (I did have some other things to
deal with too) I tried booting the new copy. Same
behavior. On a whim, however, I hit the TiVo
button. Much to my chagrin the machine woke up and
began functioning normally.
Yes, the
sleep state is stored on the drive. The original
copy was totally healthy - the machine was simply
going to sleep after boot. Watch for this on your
system.