My migration to the 17.1 profile was interrupted because the the directory /usr/lib64/debug/ was mounted as an extra file system. This happens during "unsymlink-lib --finish". It was easy to umount and continue with "unsymlink-lib --reusume-finish". However, I was wondering if the same problem might occur in different and more severe situations. At least the tool should check for subdirectory mounts and issue a warning.
Oh my, mountpoints indeed didn't came to my mind at the time. Thinking about it now, btrfs subvolumes would cause a similar issue. Now, I can think of three scenarios here: S1. Mountpoint stays in the same directory. In this case it's not in 'include' list and we don't have to worry about it much. OTOH, the user may need to update his fstab if it was mounted via the 'wrong' location. S2. Mountpoint needs to be moved as a whole. It's in 'include' list but not in 'exclude'. We don't want to move files, just create the directory and remount it in the new place. Again, the user may need to update fstab if it wasn't mounted via the canonical location. S3. Mountpoint contents need to be split. That's 'include'+'exclude', and it is a hard case. We have three potential solutions here with no apparent clue as to which one would be the best: a. move extraneous files to the new location, leave mountpoint where it is, b. move the mountpoint, copy the remaining files back, c. create a second filesystem (<- this can only be done automatically for subvolumes). All that said, I'm not really convinced this is a use case common enough to work on any real support. Finding and complaining about them -- sure, that makes sense. In other words, for regular mount points: - S1 -> pure warning that fstab may need to be updated. - S2 -> request the user to unmount it, migrate, then remount it. It kinda sucks for testing, though. - S3 -> error out as unsupported, require manual intervention. For btrfs subvolumes things can be a bit harder: - S1 -> can be ignored safely. - S2 -> move the subvolume using 'btrfs sub snap'? - S3 -> move & split or error out?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7aa35d43fbeab580b40fee279aafbc5c543e4931 commit 7aa35d43fbeab580b40fee279aafbc5c543e4931 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2018-01-04 17:50:51 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2018-01-04 17:51:33 +0000 app-portage/unsymlink-lib: Bump to v9 Bump to the v9 bugfix release that explicitly fails whenever mount points are found in /lib* or /usr/lib*. While this is far from perfect, it prevents unexpected failures later on. Bug: https://bugs.gentoo.org/643194 app-portage/unsymlink-lib/Manifest | 1 + app-portage/unsymlink-lib/unsymlink-lib-9.ebuild | 25 ++++++++++++++++++++++++ 2 files changed, 26 insertions(+)}
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8c988da5080da0451d832ced87573779556c03bb commit 8c988da5080da0451d832ced87573779556c03bb Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2018-01-10 14:46:47 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2018-01-10 14:50:38 +0000 app-portage/unsymlink-lib: Bump to v12, with improved error handling Bump to v12. The new version improves error handling even more, and officially starts supporting sub-mounts (and subvolumes) inside the migrated tree. Well, more specifically -- it informs the user of pending doom and helps him recover from it. Closes: https://bugs.gentoo.org/643194 app-portage/unsymlink-lib/Manifest | 1 + app-portage/unsymlink-lib/unsymlink-lib-12.ebuild | 25 +++++++++++++++++++++++ 2 files changed, 26 insertions(+)
