Preserve /home during reinstall?

[acampbell]

Something went bady wrong for unknown reasons after pkg_add and while trying to fix things I made them worse and ended with Err M on booting. The solution I used previously for this, thanks to iggimi, didn't work this time so I have to reinstall. But I'd like to preserve /home if at all possible. I think this can be done by putting "None" for mount in disklabel, but is that correct or is there a different way?

[jggimi]

OpenBSD on amd64 or i386 uses a 2-stage bootloader. The first stage is loaded from the MBR or GPT by the hardware when booted, and its entire job is to load the second stage and run it. The second stage bootloader issues the "boot>" prompt, and loads and runs your kernel, among other tasks.

An ERR M message comes from the first stage. It's presence on your console means, "I went to load the second stage from where you told me it was supposed to be, but it was not there."

The second-stage bootloader is the file "/boot". If that file gets moved, installboot(8) must be run to re-install the first stage into the MBR/GPT, and inform it of /boot's new physical location.

You *can* boot the ramdisk kernel (bsd.rd), and correct this problem. You'll need to mount the root partition, and the partition with /usr. You'll need access to the bootloader stage files (1st stage, biosboot, and 2nd stage, boot) which are stored in /usr/mdec. See the installboot(8) man page.

[jggimi]

Replying again for additional clarity and some step-by-step (from memory).

The ramdisk kernel can be booted, but it will need to be booted from install media, since the second stage of the on-disk bootloader is not available. Once booted, select the shell. You want to:

1. mount the root partition as "/mnt"
2. discover the partition letter that should be mounted as "/mnt/usr"
3. mount it
4. cd into /mnt/usr/mdec
5. run installboot

Let us assume your workstation's hard drive is "sd0". If it is "wd0", modify accordingly.

# mount /dev/sd0a /mnt
# cat /mnt/etc/fstab

Displaying the contents of the fstab file will inform you which partition letter to mount. Assuming you then discover it is partition "p":

# mount /dev/sd0p /mnt/usr
# cd /mnt/usr/mdec
# installboot -v -r /mnt sd0 biosboot boot

That will copy the second stage file from /mnt/usr/mdec/boot to /mnt/boot, re-install the first stage from /mnt/usr/mdec/biosboot into your MBR or GPT, and modify the first stage to point it to the second stage physical location.

[acampbell]

Thanks, iggimi, but I don't seem able to mount the root partition. Even if I could, and could solve the ERR issue, the system still wouldn't complete the boot - this was the original difficulty. Hence the decision to reinstall. A bit drastic, I know...

Can you kindly confirm that if I don't actually mount /home (i.e leave this at "none" in disklabel) it should not be overwritten? I think this is what the FAQ says but I'm not sure.

[jggimi]

Thanks, iggimi, but I don't seem able to mount the root partition.

You will need to discover why. Does the drive still have an on-disk disklabel? From that booted and running ramdisk kernel's shell:

# disklabel sd0

If you get a valid disklabel, you may still be able to recover your crippled system, or obtain a back up of critical information before reinstalling. If there is no disklabel (only the "c" partition appears), then recovery of data is still possible, but difficult.

[acampbell]

Yes there us a valid disklabel when I run
# disklabel sd0

(from the install disk shell commant)

[jggimi]

I recommend seeing if it is possible to mount any of the other partitions. If only the root partition has been damaged, you may be able to back up critical information in /home (and perhaps /var) that might otherwise be lost. The ramdisk kernel does not have dump(8), but I believe it has tar(1), which could be used to back up your critical information, if partitions are still mountable.

If /home is mountable, then -- yes -- it is possible to protect your current /home during a reinstall. I recommend backing up FIRST. The sectors currently used by the partition (as defined in the disklabel) must NOT be over written during install, so they must not be assigned to any partition during partition layout. After the installation has completed, the partition can be manually added to the disklabel(8) and to the fstab(5).

[jggimi]

Additionally, to use the ramdisk kernel's shell for backup, please be aware that device nodes for disks other than sd0 and wd0 are not included in the ramdisk's filesystem, due to space limitations. To manage any additional drives, such as sd1, you must first create the nodes, with (for example):

# cd /dev
# sh MAKEDEV sd1

[acampbell]

I can mount some of the partitions but /dev/sd0a appears to be empty. My /home is backed up nightly to tarsnap so I shall be able to recover stuff from there, although slowly.

I presume that while reinstalling the system I should delete the disklabel entry for /home to prevent its being overwritten?

I'll try this tomorrow - brain too addled at the moment.

[jggimi]

Having the tarsnap backup is terrific!

An upgrade rather than an install could be used to repopulate your root partition. But I think the effort would only be worth it if you also backed up /etc along with /home.

To recover /home without loss during an install, you must be sure that:

1. There is no /home partition defined during the install.
2. That you capture the starting sector and size from the existing disklabel.
3. That the install does NOT assign any sectors from the area currently containing /home to any partition.
4. That after installation, you define the partition in the disklabel using the starting sector and length you recorded.
5. That you add the partition to your fstab(5).

[albator]

How about booting bsd.rd (or the same ISO used for installation) and then choose to upgrade?

Welcome to the OpenBSD/amd64 X.X installation program.
(I)nstall, (U)pgrade, (A)utoinstall or (S)hell?

It shouldn't modify your home partition and fix your boot problem. A backup remains still highly recommanded first if your /home partition is accessible.

[jggimi]

Our posts may have overlapped, albator. An upgrade requires an existing /etc directory in a mountable root partition. In order to perform an upgrade, first acampbell would need to restore /etc. The upgrade script will not modify /etc, but it requires /etc/fstab and if the network is used it requires network configuration files such as /etc/hostname.* and /etc/resolv.conf.

[jggimi]

I'll also note that just because the root partition cannot be successfully mounted, it does not also mean that all data within is necessarily lost. It is possible that tools like fsdb(8) or sysutils/sleuthkit could be used as aids to recovery of existing data from the partition, if it still exists and has not been overlaid.

But that sort of forensic recovery requires a great deal of time and effort. And it also requires a separate, running OS with access to the damaged partition or a copy of the damaged partition.

[acampbell]

Thanks again for help. I wasn't successful in preserving /home so I'm currently restoring from tarsnap (thanks, tarsnap).

Incidentally, I tried the bootstrap repair process on a spare old laptop; I couldn't make it work. There was no bjosboot in /usr/mdec, only mbr. Perhaps it needs the full cd64 iso?

[jggimi]

Sorry you were unable to keep your existing /home from being overwritten on install.

Due to space limitations, the ramdisk kernel no longer comes with the bootloader files in the ramdisk's in-memory /usr/mdec. The files are included in the base fileset. The install and upgrade scripts run biosboot(8) using the just-installed or just-upgraded system's /usr/mdec/{biosboot,boot}.

---

Edited to add: this is why the "reinstall boot blocks" how-to in post #3 included steps to mount the system's /usr partition as /mnt/usr and cd into /mnt/usr/mdec.

[acampbell]

Yes I see. But when I mount /dev/wd0a (or any other partition) I always get an empty /mnt so I can't get any further.

[jggimi]

Anthony, I can't look over your shoulder, so I can only go by what you've posted. And what you've posted is that you are able to mount a filesystem, but that the filesystem contains no files. That's possible, if you manually formatted these filesystems with newfs(8), they would mount cleanly and be empty of of any files.

It's also possible that you are not actually able to mount these filesystems, and are missing an error message. Is it possible that your mount commands are not completing successfully? The df(1) command will output a list of all mounted file systems, and how much storage is in free or allocated in each.

[acampbell]

I haven't used newfs or anything similar. df shows that /dev/wd0a is mounted on /mnt but there are no files there. The same happens with other partitions, although some of them won't mount at all, saying "no such file".

Anyway, I think it's time to call it a day, at least for the moment and stop troubling you. Thank you for your patience. I must just remember never to interrupt an ungrade process to avoid getting into this situation.

A year or two back I was able to complete this process without problems, so I don't know why it doesn't work for me now.

[bsd-keith]

I've upgraded a few times, without problems, remembering to upgrade all packages too, & all my /home files remained untouched, so it does work normally.

[jggimi]

There are four things I can think of that would remove all files from a filesystem.

1. Re-formatting with newfs(8).
2. Removing them with an accidental rm(1) -r.
3. An fsck(8) of a very damaged filesystem with either a "-y" option or answering "yes" to removing each and every file.
4. Accidentally running the ramdisk's install script rather than the update script. This would cause #1 to occur.