One thing I liked about the Tips & Tutorial section on ubuntuforums.org was that users could post questions, give information, read others' questions and see the answers, etc. in a single place. From my point of view, in addition to being able to help users, I got great feedback as to how my scripts were used and what issues users were facing.
But the forums staff decided that the wiki's were the way to go. And I'm good with that (the reasons go beyond my own personal needs)... but I know that since that time, the once-regular questions have almost completely died away - and the support requests that I do see are randomly dispersed and often I don't get to see them until it's too late.
I'm specifically referring the Wubi migration and resize scripts that used to be here and here respectively. Now they are in the Wiki: https://help.ubuntu.com/community/MigrateWubi and https://help.ubuntu.com/community/ResizeandDuplicateWubiDisk
So, where can users go for help or just to discuss some issues? I don't really know. Of course you're welcome to email, but then that's not shared with the community. You could open issues in github, but that's more for code issues than support.
At this time, I recommend creating a new support thread on ubuntuforums.org, and then send me a PM there so I can come and find it. It means that the support requests will be watered down (not all in one place for other users to browse), but they'll still be searchable.
Showing posts with label migrate. Show all posts
Showing posts with label migrate. Show all posts
Friday, November 9, 2012
Wednesday, April 4, 2012
How to migrate - updated for release 12.04 Precise Pangolin
A new version of the Wubi migration script will be released for Ubuntu 12.04 Precise Pangolin. There have been some minor changes that are required for release 12.04, and a few features added.
The simple migration hasn't changed
It's still straightforward to do a migration, for example if the target partition is /dev/sda5 and the swap partition is /dev/sda6, you can migrate as follows:
sudo bash wubi-move-2.2.sh /dev/sda5 /dev/sda6
New features
These are some of the changes with version 2.2 of the script:- Simplified interaction
- Improved validation and diagnostics
- Migrate to separate target partitions e.g. for / (root), /boot, /usr, and /home
- Run migration validation pre-check without making any changes
- Resume a migration that failed due to e.g. a corrupt file, without having to recopy everything
- Synchronize a migrated install (e.g. to keep a fully bootable backup)
More information
For full instructions run:
bash wubi-move-2.2.sh --help
How to download
As usual, you can download the script from the HOWTO: migrate wubi install to partition thread on ubuntuforums.org. Select the file wubi-move-2.2.tar.gz, download, then right-click, and Expand. This will create a new directory with 3 scripts: wubi-move-2.2.sh, check-source.sh and check-targets.sh.
How to migrate in pictures
How to migrate from a root.disk
In the following example, the partition containing the root.disk is labeled 'wubi install' so the mountpoint is: /media/wubi install (including the space). This needs to be 'escaped' with '\' when specifying the location as shown in the screenshots below. Note also that this example uses a swap partition that is already used by another install (so option --shared-swap is specified to prevent running mkswap):
How to migrate to separate partitions
In the following example, there is a separate partition for /boot and /home in addition to the standard target (/) and swap partition. In addition, this example uses the --shared-swap and --no-bootloader option:
Some notes on --resume and --synch
The new options --resume and --synch are designed to save time, either when the migration terminates due to rsync copy errors, or a refreshed migration is desired. Normally the script will only proceed on an empty partition (to prevent loss of data), so these options are the only way to bypass this - and they make use of rsync's sychronization ability to only copy files that are missing/changed.
Since this does introduce a little risk, these options rely on a control file created the first time the migration is started. This ensures that the target partitions are the same as on the prior run. In other words, resubmit the migration command in the exact same way, but append --resume on the end.
The idea behind the --synch option is to keep a bootable backup e.g. on an external drive. This can be quickly syncronized prior to performing major updates (like an release upgrade).
Warning - synchronization will remove anything added to the migrated install that's not on the source install (in other words, don't use this option if you are actively using the migrated install).
This option is probably more useful for non-Wubi installs, so use it after you've migrated from Wubi (the script works on normal installs too).
Friday, May 20, 2011
How to migrate - in pictures
Update: this post is now out of date. Please refer to this instead: How to migrate updated for release 12.04
Wednesday, February 9, 2011
New release of Wubi migration script
I've released a new version of the Wubi migration script (wubi-move-2.0.sh). Here are some of the new features:
- You can migrate either Wubi or a normal install. It detects the type and handles accordingly. This is useful if you want to move your regular Ubuntu install, keep a working backup, or do some experimentation without jeopardizing anything. Also for Wubi users who migrate and then need to re-jig their partitions, it makes it easier to move the install (without worrying about UUID changes).
- It now supports grub-legacy. This was one area that was lacking - I don't know how many people have Wubi with grub-legacy, but there have been a few requests. So the migration supports releases with grub-legacy: 8.04 to 9.04 (as well as those that have been upgraded to 9.10 and later). The caveat is that the script replaces grub-legacy with Grub2 on the migrated install - so you probably don't want to be doing this prior to release 9.10 (I don't know how robust Grub2 is on 8.04.4, for example).
- It also supports migration from a root.disk file with the --root-disk= option. I had already come up with a manual solution for this before and it didn't seem too big a deal to add in to the script. So if you have a good root.disk, but you've lost the ability to boot into it, or you want to migrate to another machine, you can now boot a live CD and migrate from it. The root.disk must be a working, fully-contained Wubi install i.e. not have separate virtual disks for /boot, /usr or /home. (This rules out grub-legacy where /boot is always on the /host Windows partition.)
- Finally there are some minor tweaks. The new option --shared-swap will bypass the 'mkswap' command to preserve the UUID on the swap partition. Useful if you have multiple installs and you want to share the existing swap partition.
- I also split the output from --help into two separate options: --help and --notes to suppress the flood of output.
- Other notable changes - better validation, better error handling, for instance if there is an error in the chroot, the script attempts to cleanly unmount from the chroot before exiting.
Testing all the possible scenarios and releases is a challenge. I've done a number of cases from releases 8.04.4 to 10.10 (except 8.10) including Wubi and non-Wubi, with Grub2 and Grub-legacy. But as always community feedback is always welcome.
Thursday, January 27, 2011
The mystery of the disappearing root.disk
In the past month or so I've noticed a small but noticeable number of users losing their root.disk files (or the entire \ubuntu\disks\ directory). The reason for this is unclear and, so far, the recovery rate is 0%.
In one case, booting from a live CD and running "ls /host/ubuntu/disks gave the following:
# cd /media/win/ubuntu/disks
# ls -l
# d??????? ? ? ? ? ? disks
It's hard to know from the other side of the internet what attempts have been made to recover. But suggestions to run chkdsk don't seem to fix the problem. It's also impossible to know whether this is a new Wubi problem or whether this is a regular issue that has always affected Wubi. Time will tell.
What can you do in this case? The best insurance is a regular backup of your root.disk file, or the important contents contained within.
On that note, I also saw a thread where a user tried to reinstall Wubi to fix a problem. Reinstalling Wubi will always remove the current install, delete the root.disk, and destroy any existing Ubuntu data/settings.
"Just uninstall"
Unfortunately I also see many community members advising Wubi users to uninstall because they assume the problem is Wubi-related. Often this is not the case, but rather it is a normal Ubuntu problem that can be solved (and would still have to be solved after replacing Wubi with a normal install). It is important to let these well-meaning members know that this advice could destroy the user's important data. It's not hard to add a cautionary warning, and perhaps suggest to the user how to recover data from a root.disk from Windows (e.g. http://ext2read.blogspot.com/) before uninstalling.
A final comment... in my opinion, reinstalling an OS is not a solution to a problem - it's the last resort when there is no solution. All too often I see users quickly reinstalling at the first sign of a problem e.g. when their master boot record MBR is overwritten by Grub2. This is the simplest thing to fix and doesn't damage installed OS's or their data, so if they could just resist the urge to give up and reinstall it would save them a lot of trouble.
And remember - you can rid yourself of Wubi, but not lose any of the look and feel, settings or data on your current Wubi install, simply by migrating. There is a new migration script coming soon that supports grub-legacy (Wubi installed prior to release 9.10 and later upgraded) as well as migrations from a live CD/USB simply by pointing at a root.disk file.
In one case, booting from a live CD and running "ls /host/ubuntu/disks gave the following:
# cd /media/win/ubuntu/disks
# ls -l
# d??????? ? ? ? ? ? disks
It's hard to know from the other side of the internet what attempts have been made to recover. But suggestions to run chkdsk don't seem to fix the problem. It's also impossible to know whether this is a new Wubi problem or whether this is a regular issue that has always affected Wubi. Time will tell.
What can you do in this case? The best insurance is a regular backup of your root.disk file, or the important contents contained within.
On that note, I also saw a thread where a user tried to reinstall Wubi to fix a problem. Reinstalling Wubi will always remove the current install, delete the root.disk, and destroy any existing Ubuntu data/settings.
"Just uninstall"
Unfortunately I also see many community members advising Wubi users to uninstall because they assume the problem is Wubi-related. Often this is not the case, but rather it is a normal Ubuntu problem that can be solved (and would still have to be solved after replacing Wubi with a normal install). It is important to let these well-meaning members know that this advice could destroy the user's important data. It's not hard to add a cautionary warning, and perhaps suggest to the user how to recover data from a root.disk from Windows (e.g. http://ext2read.blogspot.com/) before uninstalling.
A final comment... in my opinion, reinstalling an OS is not a solution to a problem - it's the last resort when there is no solution. All too often I see users quickly reinstalling at the first sign of a problem e.g. when their master boot record MBR is overwritten by Grub2. This is the simplest thing to fix and doesn't damage installed OS's or their data, so if they could just resist the urge to give up and reinstall it would save them a lot of trouble.
And remember - you can rid yourself of Wubi, but not lose any of the look and feel, settings or data on your current Wubi install, simply by migrating. There is a new migration script coming soon that supports grub-legacy (Wubi installed prior to release 9.10 and later upgraded) as well as migrations from a live CD/USB simply by pointing at a root.disk file.
Wednesday, November 10, 2010
How to migrate a WUBI install to partition
If you've used WUBI for a while, you've likely spent a lot of time customizing it: playing with settings, installing and configuring programs, and saving data. If you planned ahead you made notes along the way and could reinstall fairly easily, but chances are it'd take a lot of effort to do this again.
When you refer to the Wubi Guide, it points you towards LVPM to do the migration, but LVPM hasn't been updated since Ubuntu 8.04, and doesn't work out of the box without some tweaking. The Wubi Guide's own script is in a similar state.
Fortunately it is still possible to migrate, and you can find a script and a step-by-step guide(if you want to do it manually) on ubuntuforums.org. *
Before you migrate you'll need to partition your drive. That's something you'll have to do beforehand, but it's fairly straightforward on Windows Vista or 7 - use the built in Disk Utility. For XP, you can use Gparted that is part of the Ubuntu 'Live CD'.
* This can be used to migrate Ubuntu versions 9.10 and later. If you installed on an earlier version of Ubuntu (even if you later upgraded) you have a different boot loader and the guide does not apply.
Subscribe to:
Posts (Atom)
















