<div dir="ltr">On Wed, Nov 5, 2014 at 2:09 PM, Stephen Worthington <span dir="ltr"><<a href="mailto:stephen_agent@jsw.gen.nz" target="_blank">stephen_agent@jsw.gen.nz</a>></span> wrote:<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Your problem with the program.MYI file is not too bad either if that<br>
is the only affected file. A .MYI file is just an index and I believe<br>
it can be recreated from the main program.MYD data file with the<br>
proper mysql commands, although I have never done that. And in any<br>
case, the I believe that the program table is just the EPG data and<br>
can therefore be recreated in its entirety by dropping the table and<br>
creating a new one, then using mythfilldatabase to reload all the<br>
current EPG data.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Making a Linux drive or partition bootable again after copying like<br>
that depends on what distribution you are using. All Ubuntu based<br>
distros can fix a drive to be bootable again by booting from the<br>
installation disk (live DVD or live DVD image on USB stick) and<br>
(re)installing grub2 to the hard drive. The web has instructions on<br>
how, and I have had to do that a couple of times too with Mythbuntu<br>
and it worked fine. But it is a fiddly, detailed process you have to<br>
go through. Read ALL the instructions carefully! I missed a step the<br>
first time. </blockquote><div><br></div><div>I did manage to get it all working---the system is now back up and it records again.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> You also need to check the /etc/fstab setup as the UUIDs<br>
are going to have changed on the new drive.</blockquote><div><br></div><div>Yes, I expected that and dealt with it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I usually use partition<br>
labels now instead of UUIDs to avoid that problem. </blockquote><div><br></div><div>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!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Again, you can<br>
edit fstab using a live CD/DVD boot. If your favourite editor is not<br>
available on the live DVD, then you can just use apt-get to install it<br>
temporarily in the RAM image the live DVD is running out of. Of<br>
course, you have to do that again every time you reboot the live DVD.<br>
<br>
Having a bootable image on a USB 3 stick is one of the essential tools<br>
I try never to be without. On systems that can be booted from USB 3,<br>
it is much faster that using a live DVD.<br></blockquote><div><br></div><div>Live DVDs take ages but I've never tried a USB3 stick... maybe I should.</div><div><br></div><div>In my case I managed to do everything just by booting off the hard disk, first the old one and then the new one.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Here is an example of a script I wrote to recover a recordings<br>
partition from a bad drive to a good one:<br>
<br>
#!/bin/bash<br>
<br>
cd /mnt/old/recordings<br>
for a in * ; do<br>
ddrescue -v /mnt/old/recordings/$a /mnt/new/recordings/$a<br>
/mnt/rescue/$a.log<br>
done<br>
<br>
(Watch out for line wrapping - the ddrescue line is all one line and<br>
is long enough that it will likely show up as two)<br>
<br></blockquote><div><br></div><div>Interesting tactic. Fortunately I only had a couple of files with i/o errors, and doing the rsync copy told me which ones.</div><div><br></div><div>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.</div><div> </div><div>Thanks for your suggestions</div></div><br></div></div>