Bug 249280 - Issues migrating from 12-STABLE to 13-CURRENT regarding filesystem layout changes
Summary: Issues migrating from 12-STABLE to 13-CURRENT regarding filesystem layout cha...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-09-12 14:57 UTC by Patrick McMunn
Modified: 2020-09-12 17:46 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick McMunn 2020-09-12 14:57:12 UTC
I recently decided to make the jump from 12-STABLE to 13-CURRENT on my home server. For the most part, the upgrade went smoothly. However, I did run into a couple of issues so far that seem to be due to a change in the filesystem layout and possibly adding certain directories as ZFS datasets.

The first issue I ran into was with /usr/src. Since I had sources for 12.1-RELEASE, 12-STABLE, and HEAD in /usr, I used a symlink pointing in /usr pointing from src -> head-src during the upgrade. After each reboot during the upgrade process, my source code in /usr/src seemingly disappeared, and I had to fetch the source again. I was baffled until I realized that /usr/src was now a ZFS dataset. I unmounted the dataset, and my data was still there. I was subsequently able to move my data to a temporary directory, remount the dataset, and put the data into /usr/src where it belongs.

That was yesterday. Today I realized that /home is now a symlink to /usr/home which is a ZFS dataset, and all the data I had in my home directory has seemingly disappeared. I'm sure that my data is still there, but I can't unmount this dataset on a running system because I get a "device busy" error when trying to unmount it.

So there seems to be two separate issues that need to be addressed.

1) The problem of "disappearing data" where the contents of a directory seem to be gone when a ZFS dataset is mounted at the same location as a preexisting directory.

2) There needs to be a clear way to upgrade a system to this new filesystem layout which can avoid the above issue. I didn't see anything in UPDATING which addresses this problem.
Comment 1 xtouqh 2020-09-12 15:04:14 UTC
How exactly did you upgrade?  There's nothing in source upgrade path that assumes ZFS installation and creates the ones you mentioned.  OTOH, ZFS installation type in installer DOES create those, so is it possible that those were created when you installed the system and (really just guessing) set their mountpoints to "legacy" forgetting about it?  In any case, I have /home as separate dataset -- explicitly deleted the symlink and did destroy /usr/home -- and during 12.2-BETA1 -> 13-CURRENT upgrade yesterday nothing was re-created for me.
Comment 2 Patrick McMunn 2020-09-12 17:46:59 UTC
To be honest, I guess I didn't really pay much attention to what the filesystem layout was before the upgrade. It's one of those things that just is, and I don't think much about it. So some of my assumptions about exactly what changed may be wrong. The original installation was from a 12.1-RELEASE USB image, and I used the default installation options. I later migrated to 12-STABLE from source and now 13-CURRENT from source. It wasn't until the 13-CURRENT migration that this issue arose.

To be completely transparent, though, my original subversion checkout of the 13-CURRENT code became corrupted somehow, and I ended up installing a 13 kernel but only a partially built 13 userland because, unknown to me at the time, the buildworld process failed. As a result, my system was somewhat borked. I had to run a "make installworld" from my previously built 12-STABLE source directory to get a working userland again, reboot into the old kernel, checkout 13-CURRENT source again, rebuild, and then reinstall the kernel and world from a properly built 13-CURRENT system. Reinstalling a 12-STABLE world after having already tried installing a 13 world might have introduced something that caused issues. In any case, this temporary rollback to the 12-STABLE world/userland was the only abnormal part of my upgrade process.