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

[UB40D]

The system is now back up--thanks to all those who helped.

For future reference (including mine) I'll document what else I had to do
to get it back to a working state.

On Wed, Nov 5, 2014 at 1:53 PM, UB40D <ub40dd at googlemail.com> wrote:

>
> On Wed, Nov 5, 2014 at 7:35 AM, Yann Lehmann <aristide at vtxmail.ch> wrote:
>
>> I think you don't need to boot from the old drive, once you have copied
>> all files to the new one.
>>
>> I don't know what distribution you are using. But with any xbuntu install
>> cd, you can "repair" an existing linux-installation (as you will have on
>> the new drive). It is an option of the text based installer and will allow
>> you to install grub on the new disk.
>>
>> Eventually, you will have to adjust '/etc/fstab' with according uuids.
>> The command 'ls -l /dev/disk/by-uuid' will list the uuids of all
>> partitions, and you can the use the result in '/etc/fstab'.
>>
>
> Yes, more or less. I'm on mythbuntu. This (from memory) is what I managed
> to do yesterday evening and this morning before having to head off to work:
>
> - physically install the spare drive
>
> - suitably partition it with gparted (booting from the old drive)
>
> - make temporary mount points for these partitions with mkdir, and change
> their permissions
>
> - list the new drive's partitions by uuid and copy the uuids into suitable
> entries in /etc/fstab
>
> - reboot into single user mode (shift key during grub, press e, edit the
> linux entry by adding single at the end, boot with F10)
>
> - check whether all the new partitions mounted properly, fix typos in
> fstab and repeat ;-)
>
> - for each of /boot, /, /var, home, rsync -bunchofoptions from old drive
> to new drive
>
> - observe that some had errors, as expected, but sadly not just on /var
>
> - grub-install /dev/sdf
>
> - failure because I needed to set the grub_bios flag on that partition.
>
> - did that with parted
>
> - grub-install again (no complaints)
>
> - attempt to boot
>
> - failure
>
> I forgot what it complained about but I had no time left to keep fiddling
> with it ;-)
> However I don't think I'm THAT far off. Next steps would be
>
> - make it actually boot
>
> - remove the drive with i/o errors and check it still boots
>
> - attempt to repair the database with mysql tools
>
> - if that doesn't work, attempt to restore a database from a week ago
>

When rebooting in single user mode, the boot process was stopping with a
message like

serious errors were found while checking the disk drive for
/mnt/blabla/some-partition-on-the-broken-drive
press i to ignore, s to skip mounting, m for manual recovery

and then a bunch of another 30 lines of messages. Because there were so
many other messages after this one, I didn't think that pressing those
buttons still worked. But it did. So I could just *S*kip mounting and get
to a prompt. Once there, I removed that partition from fstab so it wouldn't
be mounted automatically.

The rsync command to copy files from the broken drive to the replacement
drive was

rsync -avxHAX --progress /old-var /new-var

With the --progress flag it prints out a lot of messages as it goes along,
both for success and for failure. However if you want to know what files
had problems you can just run the command a second time; it will not
reprocess the files that were successfully transferred and it will report
just on the ones that still have i/o errors.

grub-install /dev/sdf
(where sdf is the new drive) works, but it's probably a good idea to redo
it after we're using the / /boot /var of the new drive.
I had a problem where, on single-user boot, I still got a complaint like
the one above (errors were found while checking the disk drive for xxx) but
for something I thought I had removed from /etc/fstab. I am concerned it
may have been the wrong copy of /etc/fstab

for repairing the MYI:

as root, I went to the relevant directory (on the new drive)
/var/lib/mysql/mythconverg
where I had program.MYI.broken (of which only the first few MB had copied
before the i/o error) and I copied it to program.MYI.

Then I attempted the repair with
myisamchk program.MYI
myisamchk -r -q program
myisamchk -r program
myisamchk program.MYI

and finally it looked like problems had been fixed and the file regenerated.

I then rebooted into mythbuntu and tried mythfilldatabase, but it failed. I
forgot the error message but something in the database was not writable.
To fix that, I had to

chmod 660 program.*
chown mysql:mysql program*
restart mysql

after this, I could do mythfilldatabase and, after that, schedule some
recordings.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20141106/92039b24/attachment.html>