LinHES Forums
http://forums.linhes.org/

Strategy for hardware and software update migration?
http://forums.linhes.org/viewtopic.php?f=14&t=19307		 Page 1 of 1
Author:  acronce [ Sat Nov 29, 2008 6:36 pm ]
Post subject:  Strategy for hardware and software update migration?
Hi all,

I'm trying to formulate a strategy for migrating from an ancient backend-only machine running an older KnoppMyth to new hardware, updating to the latest KnoppMyth while retaining the existing scheduling and recordings.

The old system is PATA-only with a single 300 GB drive and R5E50 installed via automatic mode. The system includes the Schedules Direct update from last year. Since I did an automatic install, there appears to be a roughly 5 GB boot partition (/dev/hda1), a 2 GB swap partition (/dev/hda2), and the rest is for /myth (/dev/hda3).

The new system will be a SATA-only MSI Wind Nettop barebones, running an Atom processor. Note that this is a backend-only system, so it doesn't need much horsepower. I plan to install 1 TB SATA drive. I'd like this drive configured similar to my previous "automatic" install, where there's a small boot partition and the rest is /myth. Later I might boot from an 8 GB Compact Flash card, but for now I want to keep things simple.

After researching the problem, I think the following summarizes what I need to do:

1. Do a KnoppMyth backup, just in case.

2. Format and mount the new 1 TB drive as an external drive on the old machine.

3. Copy all the files from the old 300 GB drive to the new 1 TB drive.

4. Configure the new 1 TB drive to boot.

5. Boot the new hardware with the 1 TB drive.

6. Go through the KnoppMyth automatic update process on the new hardware, as per this post:

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

7. After updating, take a look at the tweaks that I previously performed (I've kept a detailed log) to see what, if anything, needs to be carried forward.

Does the above sound about right?

Of course the devil is in the details. While I've become somewhat experienced with Unix as a Mac developer, I'm still something of a Linux noob. I've researched this, but I'm not completely sure that I've divined the exact incantations needed to perform the above spells.

For the format step, maybe I can cheat a little rather than using fdisk and mkfs. If I perform a default R5E50 install on the new 1 TB drive in the new hardware, that would also set up the default partitions and file systems. Then I could move the drive to the old system, delete the files from the new drive, then copy from the old to the new. Before copying, maybe I should probably save off /etc/fstab and /etc/lilo.conf from the new drive, then restore them after the big copy.

For the copy step, I think that I need to do two copy operations, one for the boot partition and one for the myth partition, something like this:

cp -ax / /newboot
cp -ax /myth /newmyth

I assume that I don't have to bother copying the swap partition.

Also, there's the little detail that copying 300 GB of data could be very painful. Again, my old machine is PATA-only with USB 1.0. At a top speed of 1.5 MB/s, it's going to take over 2 days to copy the data from the old machine to a USB enclosure.

I suppose that I could reverse the problem by first copying the boot drive the slow way, then boot off the new machine, then mount the old drive in a USB 2.0 enclosure. Then I could copy the old /myth partition at USB 2.0 speeds.

Alternatively I could get an eSata enclosure, but I have no idea how to manage the formating and mounting of an eSata drive under Linux. For that matter, I'm not sure yet how to mount a USB drive under Linux ;-)

For step 4 (configuring the new drive for boot), I'm really not clear on what to do. If I do the "cheat" and create a default install on the new hardware to establish the partitions, then maybe all I have to do is restore the original, saved off /etc/fstab and /etc/lilo.conf files.

If instead I do a real format via the fdisk/mkfs pattern, then I expect that I'll have to edit /etc/fstab and /etc/lilo.conf manually, replacing the hda's with sda's for the SATA device. Maybe I also have to call lilo -C with the newly modified /etc/lilo.conf, but I'm not sure about that.

Hopefully I'm on the right track. I'd appreciate any suggestions to help firm up the strategy.

Thanks in advance.
Author:  cecil [ Sun Nov 30, 2008 12:32 am ]
Post subject: 
1) Backup on old MBE.
2) Attach and format new 1TB. Make 5 gig for /, /swap (1.5x RAM) and the rest for /myth).
3) cp -a /myth/* /mnt/newmyth/
4) Place 1TB in new MBE.
5) Boot R5.5 CD on new MBE and select auto upgrade.
6) You can continue from your #6...
Author:  acronce [ Sat Dec 13, 2008 9:30 pm ]
Post subject: 
I'm finally getting around to doing this upgrade. To save time, I ended up getting a SATA/IDE adaptor so that I temporarily install the new SATA drive in my old IDE-only machine. This should make copying the myth partition a lot faster than USB.

I've partitioned the new drive as per Cecil's recommendations. Now I'm formatting the partitions. I'm sticking with the default of ext3. I know it's not optimal for large file deletes, but I don't want to deal with file system problems related to power failure, even with a UPS.

The question I have is do I need to format the swap partition? Sorry, but I'm a Linux noob ;-)

Thanks in advance.
Author:  graysky [ Sun Dec 14, 2008 5:00 am ]
Post subject: 
@OP - I don't think you need to format the swap. Also see tjc's advice in this thread which is more or less what cesman said, except tjc recommends rsync. It is how I did the same thing when I upgraded HDDs.
Author:  jmckeown2 [ Sun Dec 14, 2008 10:21 am ]
Post subject: 
Before you format the new filesystems on the drive, you have to partition the drive, which sets the sizes of the partitions, and therefore three file systems. For the Swap, there *IS* a special partition type that you need to use when you set up the drive. depending on the partitioner there will be "Linux" for the / (root) and /myth partitions, and "Linux Swap" for the Swap partition.

If I run "fdisk /dev/sda" (/dev/sda is my boot disk) then type 'p' to Print the partition table I get:
Code:
Disk /dev/sda: 250.0 GB, 250058268160 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         609     4891761   83  Linux
/dev/sda2             610         853     1959930   82  Linux swap / Solaris
/dev/sda3             854       30401   237344310   83  Linux

You can then format the sda1 and sda3 as ext3 (or xfs, or whatever) but sda2 is ready to be your swap partition. The auto-upgrade will handle getting in the fstab file, and getting it activated.
Author:  stinga [ Sun Dec 14, 2008 12:35 pm ]
Post subject: 
G'day all,

Lots of ways to skin a cat, when I have done this (or moving to a bigger disk) I have done...

1 perform backup
2 connect new disk, disconnect old disk
3 do new install
4 reconnect old disk
5 copy old /myth to new /myth
6 disconnect old disk
7 perform upgrade.

(various reboots and mount points needed)

I am about to this since I need a bigger disk and need to upgrade to the latest knoppmyth.
Also want to change /myth from ext3 to xfs.

I find doing the above lets me have something to fall back on, should it all go horribly wrong!
Author:  mythmax [ Mon Dec 15, 2008 8:29 pm ]
Post subject:  Keep a copy of your old hda1
Here's an upgrade tip:

Use dd to keep a copy of your old hda1 around after the upgrade so you can look up settings you forgot to write down before the upgrade.

Just prior to doing an upgrade I boot off a knoppix CD and issue the command : dd if=/dev/hda1 of=hda1.dd (after cding to the directory where I want to place my backup)

Later I can mount that with: mount -o loop hda1.dd /mount_point and then: cd mount_point.

I always have to use the hda1 backup because I always forget something. (Last time I forgot my crontab.) Sometimes I don't realise I've missed something until long after the upgrade such as adding a select music option to library.xml. I typically keep hda1.dd in my /myth/backup directory until the next upgrade.
Author:  tjc [ Mon Dec 15, 2008 8:52 pm ]
Post subject: 
This type of thing is what the system backup is for, and why it uses a "inclusive backup, selective restore" strategy. Discussion of this, how to add extras so that they get backed up every time, and how to get individual files from the backup are covered here: Taking advantage of the enhanced backup and restore scripts
Author:  acronce [ Mon Dec 15, 2008 11:49 pm ]
Post subject: 
Partitioning and formating the new drive was straightforward. I ended up using a SATA/IDE adapter in order to copy the old /myth to the new drive in the old system. That helped because it took a lot less time to copy than it would have if I used USB.

But it still took something like 16 hours. So when it was done, I did another myth backup, then used rsync to capture any changes onto the new drive.

I've gotten to the point where I performed the auto-update. Unfortunately after rebooting, I'm getting a black screen. Basically the monitor I'm using says that the video mode is not supported. I tried my big screen also (which has DVI in), but got nada.

Further, although I can see that the machine is obtaining an IP address via DHCP, I can't ping the new box, nor SSH to it, nor VNC. It's like I've lost control of the Mars lander ;-)

Remember, this is a backend only system. So I really couldn't care less what its resolution is or refresh rate is. 800x600 is just fine, as long as I can see it with my monitor.

I tried to follow the instructions on the wiki regarding recovering from a blackscreen. It was pretty straight forward to use the CD install to get to the point where I could hide the startx binary and enter the command line at boot. But at that point, the wiki article falls flat with a general "now you can fix your xorg.conf" file.

I tried commenting out all the modelines but 800x600 60 Hz, but that didn't work.

Can someone tell me how I can hack my system so that it displays a low resolution that my monitor can handle? I suspect that once I can see the screen, I can go through the remainder of the installation configuration and bring the box up.

Thanks in advance.
Author:  acronce [ Tue Dec 16, 2008 9:07 am ]
Post subject: 
After some more research, I ended up rebuilding my xorg.conf via the following command:

Code:
dpkg-reconfigure xserver-xorg

Now I can see what I'm doing and I'm working my way through the rest of the setup. Life is much better.
Author:  acronce [ Thu Dec 18, 2008 8:44 am ]
Post subject: 
Another issue I ran into was that my /myth was not mounted after the auto update. This seems to be a common problem because other people have posted about it. I had to re-rerun the auto update, manually editing the fstab and replacing the xorg.conf with my saved, working one after installation.

I don't think there was anything non-standard about my /myth mount. Except that I had a few folders of my own that I used to transfer some stuff from the old machine.

I wonder if there's a way to improve the detection of /myth? Maybe if there was a well known hidden file at the root?

Anyway, at this point, the migration has worked. However I'm seeing some problems with recording certain shows that I'll post in a separate thread.

Thanks to everyone for their suggestions.
Page 1 of 1 All times are UTC - 6 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/