I am currently dding my entire KM hard drive to another to have an exact clone so that hopefully I will be able to shed some light on whether or not a previously upgraded and manually repaired database (from a remote .21 frontend) can be upgraded to R5.5.

I will probably only have time to try one method per day maximum. What I hope to do tomorrow evening is to take a drive, change the schema version field from 1214 to 1160 and connect to it from a remote frontend running .21 to force a database upgrade again. Then I will run the backup script followed by booting from the 5.5 disk and auto-upgrading.

If that doesn't work, are there any other tests that anybody will want me to try before I restore my box with a backup from May 30 with database schema 1160 and doing an auto-upgrade that *should* work for sure?

If that were to fail I will probably just do a fresh install and copy all of my videos, etc. manually onto the machine and try to reconfigure everything. Luckily I only have a couple of recordings, everything else has been transcoded to xvid and shouldn't be difficult to import into the video database.

Let me know ASAP if there's anything that you want me to guinea pig!

Update (for anyone following this saga):

I booted to runlevel 2 in Knoppix and ran something like


I had to kill dd this morning after it hadn't completed in 8 hours. This is probably because I have the new drive mounted in an external enclosure instead of installing it internally. It appeared to be working on my /myth partition at the time (with the root partition completed).

My current (old) hard drive is sda
My new hard drive is sdb

So I rebooted directly into KM on the old drive and it looks like the "structure" of the new drive is correct so I mounted /dev/sdb1 to /mnt/newroot and /dev/sdb3 to /mnt/newmyth/


updated a few things

spat out errors, so I did a

which was done almost immediately (seems fishy).

Then left for work after running

again and it seemed to be working.

I suppose I probably should have stopped the backend and mysql before rsyncing anything, though... I will look into that further tonight.

But the main thing is: if somebody wanted a straightforward, seamless clone of a disk and didn't want to have to wait for dd or have to manually partition, install lilo, etc... couldn't they follow this procedure?

1. run a km backup
2. boot from livecd and dd the mbr and partition table to the new drive
3. format the new hard drive partitions 1 (2?) and 3 to filesystems of their liking
4. mount old and new drives. rsync root & myth to new drive
5. physically replace old drive with new and boot from new drive
6. run km restore
7. Drink a beer

Just thought that if so I would write a better detailed howto on it.
If not, then I wouldn't waste my time finding out the hard way

Sorry that this is totally unrelated to my original post, but it does play a role in the whole process

I would strongly recommend against step 2. Partitioning and FS creation are fast on modern hardware (as you discovered) and you'll get a structure that is correct and appropriate for the new drive.

For copying the files and such cp -a or rsync -a would be my choices, and rsync generally gets the nod because it checksums the files as it goes. This costs a bit of time but helps ensure correctness.

I am abandoning this. Even after restoring a perfectly clean database from May, I still had trouble upgrading and could not use my tuners after the upgrading (even after deleting all tuners, adding them, shutting down and unplugging for 5 mins). I did a fresh install instead and will just manually add recordings

At this point what I'd recommend is exactly that, and applying a data only extract of your "recorded" and other related tables for the recordings. Somebody had posted a good list within the last week or so...

http://mysettopbox.tv/phpBB2/viewtopic.php?t=17867

I have that sql file at hand, but I don't think I'm even going to restore it just because I would like to keep this installation untainted (and it helps that I only had 2 recordings that were not transcoded).

For completeness to my previous posts:
I ran a remote frontend with .21 on it, and instead of updating the database like the previous remote frontend had, it just said that they were different versions. So that scrapped the first idea I was going to try.

Then I restored a clean backup from schema 1160, loaded the recordings.sql file (see link above) and ran mythfilldatabase and did another backup. I actually had to modify the recordings.sql file because it had extra fields in it.

I had the problem during the upgrade where it wouldn't connect to the database. My /etc/mysql/my.cnf file already had the bind address commented out and I changed my /home/mythtv/.mythtv/mysql.txt file to change the DBHostName to localhost, I restarted mysql and the backup continued to run. Then I got to the points where the .................................................. filled the screen for 10+ minutes, so I did a ctrl+c like recommended in the Hints. That terminated the upgrade script, so I restarted and it said my tuners were unavailable. I removed all tuners, added them again and they were still unavailable. I powered down, pulled the plug for 5-10 mins, then started it back up and still unavailable.

So I decided to do a fresh install instead, but I still do have my original unmodified R5F27 hard drive just in case there are any more tests you might want me to run.

Just a note: I had a non-knoppmyth frontend update my DB schema to 1214 - disabling my R5F27 knoppmyth box by not being able to properly query the input cards. I didn't manually try to fix the db - so it was a pure 1214 schema. I was able to do the upgrade (manual) to R5.5 without any issues (that weren't already covered in the hints thread). I will post full details if anyone is interested.

Was there a reason that you did a manual upgrade instead of automatic? That is something I have not tried.

Only that I have been running knoppmyth since SATA-lvm was not recognized by the auto installer script - so I had originally done a manual install - and therefore have always done the manual upgrades since. Until recently, I had never spotted the thread about disk structure requirements for the auto installer to work.

Here is a link to the steps for my manual R5F27 to R5.5 upgrade - don't think I did anything differently from any other upgrade - so I am not sure it will make a difference for you...

hth

jmacmythtv - I was just looking at that and it looks like you either don't have a swap partition or have it in an odd place... You really should have a swap partition...

Oh and cloop errors are a bad sign, usually indicating a problem with reading the CD. I wouldn't trust the install.

The remote login thing is documented and intentional. It's configured to only allow the extra user (with a hopefully more random username and password) rather than the mythtv user (which has a fixed username and password) or the root user. See the R5F27 Hints http://knoppmyth.net/phpBB2/viewtopic.php?t=16384 under Known Changes 6.1

Thanks TJC.

I may not have posted all my partitions in that list ... this is the output of
df -haT

Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1 ext3 4.6G 2.6G 1.8G 60% /
usbfs usbfs 0 0 0 - /proc/bus/usb
tmpfs tmpfs 1013M 4.0K 1013M 1% /dev/shm
/dev/mapper/vg-myth ext3 927G 731G 196G 79% /myth
rpc_pipefs rpc_pipefs 0 0 0 - /var/lib/nfs/rpc_pipefs
nfsd nfsd 0 0 0 - /proc/fs/nfsd

I know the machine is using swap - as it shows in infocenter. Is tmpfs is an appropriate file type for swap space? - I thought it was supposed to be "linux swap"...

As for the CLOOP errors, they appeared only briefly while the CD spun up to speed and after I issued a reboot command without the CD in the drive. In general, this release is running better than any other I have tried ... tks for all the work on it!

Since swap isn't a mountable file system you need to do something a bit different to list it. Try this:

root@myvcr:/# cat /proc/swaps
Filename Type Size Used Priority
/dev/sda2 partition 2441872 3560 -1

All good?

Yeah, that makes a lot more sense. I'd still keep an eye out for potential issues from those cloop errors. During testing I saw more than a few flaky random issues associated with installs where those occurred, that went away I reinstalled with clean reads.