Reinstall mount warning #1299
Reinstall mount warning #1299
Conversation
github-actions
bot
added
the
area/system-reinstall-bootc
ckyrouac
force-pushed
the
reinstall-mount-warning
branch
from
cefb40e to
fdae493
Compare
mount/src/mount.rs
Outdated
| if let Some(path) = path { | ||
| cmd.arg(path); | ||
| } |
There was a problem hiding this comment.
Minor but this can also be cmd.args(path) because Option can act like a zero-or-one-element iterator.
system-reinstall-bootc/src/prompt.rs
Outdated
| root.children | ||
| .iter() | ||
| .flatten() | ||
| .filter(|child| child.source == root.source) |
There was a problem hiding this comment.
So...this seems like it will basically only find btrfs subvolumes, right? I think that's the only real sane case where the same source device can be mounted multiple times in that way.
In Linux one can mount e.g. the same block device multiple times but for filesystems without subvolumes there's not much use case for it.
There was a problem hiding this comment.
So for someone who has e.g. /home or /var/log as a LVM logical volume, the sources are different so this check won't trigger.
However, the hard part here is to generalize this, we're going to need to exclude e.g. the API filesystems among many other things. I'm sure there's code to do this, but we'd need to do some investigation.
system-reinstall-bootc/src/prompt.rs
Outdated
|
|
||
| if !problematic_filesystems.is_empty() { | ||
| println!(); | ||
| println!("Notice: the following filesystems are currently mounted on the root disk. After rebooting into the bootc system, these filesystems will not be mounted. They will be preserved so you will need to manually mount or remove them."); |
There was a problem hiding this comment.
Well...strictly speaking, someone could inject configuration into their image to mount it. It would be totally sane to me for example to have an OS configuration that auto-discovers a btrfs subvolume named home and mounts it at /home or whatever.
Getting into this level of detail, we could in theory also scrape /etc/fstab and the .mount units in the target environment...but, yeah a lot there.
I'm uncertain. I think in the short term given the above, effectively special casing "/home btrfs subvolume" could make sense as a starting point.
NOTE: Detected mounted btrfs subvolumes: /home
These subvolumes are left unchanged by this tool.
?
ckyrouac
force-pushed
the
reinstall-mount-warning
branch
from
fdae493 to
c1d3495
Compare
There was a problem hiding this comment.
Thanks! This is looking pretty good to me so far!
I'm thinking rather than having a lot of explanatory in the binary we add it to the docs or so, which is what the text is implying.
BTW I bet we could get some testing of s-r-b by using loopback mounts to set up alternative root installation targets, though that would require passing through the target root instead of assuming /. But definitely nonblocking.
ckyrouac
force-pushed
the
reinstall-mount-warning
branch
from
c1d3495 to
7497c43
Compare
This allows retrieving all mounts. Signed-off-by: ckyrouac <ckyrouac@redhat.com>
ckyrouac
force-pushed
the
reinstall-mount-warning
branch
from
7497c43 to
5700972
Compare
This uses findmnt to locate filesystem mounts that are on the same source as the root mount. If any are found, the user is warned these filesystems will persist unmounted in the bootc system. The user must hit <enter> to proceed. This does the same for logical volumes in the same group as root. It also adds a generic warning to help the user understand what will happen after rebooting into the bootc system. Signed-off-by: ckyrouac <ckyrouac@redhat.com>
ckyrouac
force-pushed
the
reinstall-mount-warning
branch
from
5700972 to
118dced
Compare
@cgwalters this is a rough outline of what I'm planning to do to guide the user to handle their mounted filesystems. I'm not sure which mounts we should list though. This code correctly shows the
/homemount from a Fedora workstation install but I'm sure there are other cases I'm missing.(I'm also trying to figure out a more functional way to parse the filesystems)