[mythtv-users] Reviving a myth system after hardware failure on /var

[UB40D]

On Wed, Nov 5, 2014 at 2:09 PM, Stephen Worthington <
stephen_agent at jsw.gen.nz> wrote:

> Your problem with the program.MYI file is not too bad either if that
> is the only affected file.  A .MYI file is just an index and I believe
> it can be recreated from the main program.MYD data file with the
> proper mysql commands, although I have never done that.  And in any
> case, the I believe that the program table is just the EPG data and
> can therefore be recreated in its entirety by dropping the table and
> creating a new one, then using mythfilldatabase to reload all the
> current EPG data.
>

Thanks. This was reassuring and really useful. I did succeed in recreating
the MYI with mysql tools. I'll say later how, exactly, for future reference.


> Making a Linux drive or partition bootable again after copying like
> that depends on what distribution you are using.  All Ubuntu based
> distros can fix a drive to be bootable again by booting from the
> installation disk (live DVD or live DVD image on USB stick) and
> (re)installing grub2 to the hard drive.  The web has instructions on
> how, and I have had to do that a couple of times too with Mythbuntu
> and it worked fine.  But it is a fiddly, detailed process you have to
> go through.  Read ALL the instructions carefully!  I missed a step the
> first time.


I did manage to get it all working---the system is now back up and it
records again.

There is one thing about booting that still feels a bit weird (but only
when I go into single user mode). To get to the bottom of it I'll have to
remove the damaged drive.

You also need to check the /etc/fstab setup as the UUIDs
> are going to have changed on the new drive.


Yes, I expected that and dealt with it.


>   I usually use partition
> labels now instead of UUIDs to avoid that problem.


I prefer the UUIDs, despite that problem, because if I move the drives
around physically, or add/remove drives, then I don't have to rewrite the
fstab for previous partitions that may have changed name. That used to be a
pain in the pre-UUID days!


> Again, you can
> edit fstab using a live CD/DVD boot.  If your favourite editor is not
> available on the live DVD, then you can just use apt-get to install it
> temporarily in the RAM image the live DVD is running out of.  Of
> course, you have to do that again every time you reboot the live DVD.
>
> Having a bootable image on a USB 3 stick is one of the essential tools
> I try never to be without.  On systems that can be booted from USB 3,
> it is much faster that using a live DVD.
>

Live DVDs take ages but I've never tried a USB3 stick... maybe I should.

In my case I managed to do everything just by booting off the hard disk,
first the old one and then the new one.


>
> Here is an example of a script I wrote to recover a recordings
> partition from a bad drive to a good one:
>
> #!/bin/bash
>
> cd /mnt/old/recordings
> for a in * ; do
>     ddrescue -v /mnt/old/recordings/$a /mnt/new/recordings/$a
> /mnt/rescue/$a.log
> done
>
> (Watch out for line wrapping - the ddrescue line is all one line and
> is long enough that it will likely show up as two)
>
>
Interesting tactic. Fortunately I only had a couple of files with i/o
errors, and doing the rsync copy told me which ones.

I was unlucky that the failed drive was the boot drive, but lucky that the
files were not crucial---in particular that the database file that failed
was an index instead of crucial data.

Thanks for your suggestions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20141106/9bb993b2/attachment.html>