<div dir="ltr"><div>The system is now back up--thanks to all those who helped.</div><div><br></div>For future reference (including mine) I'll document what else I had to do to get it back to a working state.<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 5, 2014 at 1:53 PM, UB40D <span dir="ltr"><<a href="mailto:ub40dd@googlemail.com" target="_blank">ub40dd@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 5, 2014 at 7:35 AM, Yann Lehmann <span dir="ltr"><<a href="mailto:aristide@vtxmail.ch" target="_blank">aristide@vtxmail.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think you don't need to boot from the old drive, once you have copied all files to the new one.<br>
<br>
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.<br>
<br>
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'.<br></blockquote></div><br></div></span><div class="gmail_extra">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:<br><br></div><div class="gmail_extra">- physically install the spare drive<br><br></div><div class="gmail_extra">- suitably partition it with gparted (booting from the old drive)<br><br></div><div class="gmail_extra">- make temporary mount points for these partitions with mkdir, and change their permissions<br><br></div><div class="gmail_extra">- list the new drive's partitions by uuid and copy the uuids into suitable entries in /etc/fstab<br><br></div><div class="gmail_extra">- reboot into single user mode (shift key during grub, press e, edit the linux entry by adding single at the end, boot with F10)<br><br></div><div class="gmail_extra">- check whether all the new partitions mounted properly, fix typos in fstab and repeat ;-)<br><br></div><div class="gmail_extra">- for each of /boot, /, /var, home, rsync -bunchofoptions from old drive to new drive<br><br></div><div class="gmail_extra">- observe that some had errors, as expected, but sadly not just on /var<br><br></div><div class="gmail_extra">- grub-install /dev/sdf<br><br></div><div class="gmail_extra">- failure because I needed to set the grub_bios flag on that partition. <br><br></div><div class="gmail_extra">- did that with parted<br><br></div><div class="gmail_extra">- grub-install again (no complaints)<br><br></div><div class="gmail_extra">- attempt to boot<br><br></div><div class="gmail_extra">- failure <br><br></div><div class="gmail_extra">I forgot what it complained about but I had no time left to keep fiddling with it ;-)<br></div><div class="gmail_extra">However I don't think I'm THAT far off. Next steps would be<br><br></div><div class="gmail_extra">- make it actually boot<br><br></div><div class="gmail_extra">- remove the drive with i/o errors and check it still boots<br><br></div><div class="gmail_extra">- attempt to repair the database with mysql tools<br><br></div><div class="gmail_extra">- if that doesn't work, attempt to restore a database from a week ago</div></div></blockquote><div><br></div><div>When rebooting in single user mode, the boot process was stopping with a message like</div><div><br></div><div>serious errors were found while checking the disk drive for /mnt/blabla/some-partition-on-the-broken-drive</div><div>press i to ignore, s to skip mounting, m for manual recovery</div><div><br></div><div>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.</div><div><br></div><div>The rsync command to copy files from the broken drive to the replacement drive was</div><div><br></div><div>rsync -avxHAX --progress /old-var /new-var</div><div><br></div><div>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.</div><div><br></div><div>grub-install /dev/sdf </div><div>(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.</div><div>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</div><div><br></div><div>for repairing the MYI:</div><div><br></div><div>as root, I went to the relevant directory (on the new drive) </div><div>/var/lib/mysql/mythconverg</div><div>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.</div><div><br></div><div>Then I attempted the repair with</div><div>myisamchk program.MYI</div><div>myisamchk -r -q program</div><div>myisamchk -r program</div><div>myisamchk program.MYI</div><div><br></div><div>and finally it looked like problems had been fixed and the file regenerated.</div><div><br></div><div>I then rebooted into mythbuntu and tried mythfilldatabase, but it failed. I forgot the error message but something in the database was not writable.</div><div>To fix that, I had to</div><div><br></div><div>chmod 660 program.*</div><div>chown mysql:mysql program*</div><div>restart mysql</div><div><br></div><div>after this, I could do mythfilldatabase and, after that, schedule some recordings.</div></div></div></div>