Moving system disk provokes data loss?

["John D. Baker" <jdbaker%mylinuxisp.com@localhost>]

Posting to both netbsd-users and pkgsrc-users as the topic spans base
system and package issues.

I recently updated a machine that had been dual-booting Ubuntu 8.04 and
NetBSD-6.1_STABLE.  The Ubuntu installation was on wd0 and was left in
place to check the ext3 filesystems in case of an unclean shutdown.
NetBSD operated them as ext2, naturally.

The user wished to migrate all of his data to disks bearing ffs filesystems
and to eventually be rid of the Ubuntu installation entirely

After determining all data on the disk with the existing NetBSD-6 install
was either safely copied elsewhere or of no further interest, we determined
that it was simplest to save "/etc" and "/usr/pkg/etc" to some scratch
space, wipe the target disk out and install from scratch.

(The target disk had previously been the target of a "g4u" copy of the
machine's presumedly-failing system disk.  As a result, only the first
80GB of the 1TB disk had been available.  Now, we'd have the full capacity
at our disposal.)

The target disk was wiped (1MB of /dev/zero written to /dev/wd1d),
re-'fdisk'ed and 'disklabel'led.  A fairly ordinary install transpired
and all space not allocated to system functions was placed in an additional
partition mounted on "/d1" (as we proposed the mountpoint to mimic the
device node).  The old "/etc" and "/usr/pkg/etc" were restored to the new
system and 'etcupdate' run to bring things into line with the new sets.

Thereafter, a few key packages were installed.  To wit: the recently-
updated "xfce4-4.12" and "xfce4-extras", "libreoffice4", "firefox", and
a few other odds and ends.

At this point, all user data was still on ext2/3 filesystems on other
physical disks, which behaved properly.  We then began migrating data
from those disks/filesystems and once all data were recovered to available
ffs filesystems, the ext2/3-bearing disks were similarly zeroed and
'disklabel'led (w/o 'fdisk') for use under NetBSD.

The last disk to be operated on was "wd0" which held the Ubuntu install.
As it happened, all user data easily fit on the newly-installed NetBSD
system disk ("wd1") and an auxiliary disk, "wd2", so "wd0" was not
immediately reclaimed.  NetBSD "/etc/fstab" entries were updated to
reflect the new arrangement and symbolic links made where appropriate.

In this state, all seemed to work fine, except xfce4 is missing the vast
majority of its icons (even though the packages are installed).  We even
went so far as to update pkgsrc on the machine, remove the binary packages
and rebuild locally, but that did not help.

Additionally, 'firefox' lost the user's bookmarks from the previous
version he'd been using.

Eventually, we reclaimed "wd0" in the same way by 'dd'-ing a megabyte of
"/dev/zero" to it and writing a bare disklabel w/o prior 'fdisk'.

At this point we discovered that the PE-SC430's BIOS can't cope with
the boot disk not being on the SATA-0 connector, so we scrambled to
rearrange the cabling so the previous "wd1" would now be "wd0".  After
fixing up entries in "/etc/fstab" to match, all seemed to be in order
once again.

The first thing noticed was that the user's 'firefox' bookmarks
mysteriously reappeared just where he expected to find them.

It was then discovered that 'libreoffice' had lost all the modifications
to a spreadsheet the user uses to track his finances made between the
initial installation of 'libreoffice4' a few days before and the moving
of the system disk from "wd1" to "wd0".  His home directory did not
change location as it was physically located on "/dev/wd2" the entire
time (referenced by a symbolic link "/home" that pointed to the approprate
directory).  At no time was 'libreoffice' ever terminated abnormally.

Further, we had created symbolic links in the user's 'gimp' configuration
directory to permit direct acquisition via 'xsane' as a 'gimp' plugin.
After changing the location of the system disk from "wd1" to "wd0", those
symbolic links had been removed.

This has been the most bizarre update I've ever performed and I find it
quite unsatisfying.  Alas I am no-longer on-site with the machine and I
do not have remote access to it.  Any remedies will have to be explained
to the user to perform.

-- 
|/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645