lima icon indicating copy to clipboard operation
lima copied to clipboard

Past mounts are persisted through stop/start cycles

Open moenodedev opened this issue 1 year ago • 6 comments

Description

Instructions:

  1. Stop the lima instance
  2. Change your home mount point
 mounts:
   - location: "~"
-    mountPoint: "/home/development"
+    mountPoint: "/home/trojan1"
     writable: true
  1. Start the lima instance
  2. Repeat with /home/trojan2, /home/trojan3, /home/trojan4

After doing this 4 times:

  • /home/trojan1 is empty (not mounted) and owned by root
  • /home/trojan2 is empty (not mounted) and owned by root
  • /home/trojan3 is mounted and owned by $USER
  • /home/trojan4 is mounted and owned by $USER
$ ls -lA /home 
total 5
drwxr-sr-x  2 alpine      alpine      1024 Jan 28 14:51 alpine
drwxr-xr-x  3 root        root        1024 May 25 13:16 development
drwxr-xr-x  3 development development 1024 May 25 12:49 development.linux
drwxr-xr-x  2 root        root        1024 May 25 13:04 trojan1
drwxr-xr-x  2 root        root        1024 May 25 13:13 trojan2
drwx------ 11 development development  320 May 25 13:22 trojan3
drwx------ 11 development development  320 May 25 13:22 trojan4
$ mount | grep ^mount
mount0 on /home/trojan3 type virtiofs (rw,relatime)
mount1 on /tmp/lima type virtiofs (rw,relatime)
mount0 on /home/trojan4 type virtiofs (rw,relatime)

Discussion: #2359

Configuration:

disk: "15GiB"

mountType: "virtiofs"
mounts:
  - location: "~"
    mountPoint: "/home/development"
    writable: true
  - location: "/tmp/lima"
    writable: true

vmType: "vz"
os: "Linux"
arch: "aarch64"

audio:
  device: "vz"
video:
  display: "none"
networks:
  - vzNAT: true

images:
  - location: "https://dl-cdn.alpinelinux.org/alpine/v3.19/releases/cloud/nocloud_alpine-3.19.1-aarch64-uefi-cloudinit-r0.qcow2"
    digest: "sha512:d5e69cff0ecb0fd3850bd78f56f66131115934df27b2373c35a85a74b9def52822134dd43f90b4fabe239fdd4452026cb45f1c8f0b36a43af69335a26f0959b5"
    arch: "aarch64"
containerd:
  system: false
  user: false

moenodedev avatar May 27 '24 18:05 moenodedev

If I change the mount point back to the original (a mountPoint that was already used) the previous mountPoint is still mounted:

 mounts:
   - location: "~"
-    mountPoint: "/home/trojan4"
+    mountPoint: "/home/development"
     writable: true
$ mount | grep ^mount
mount0 on /home/trojan4 type virtiofs (rw,relatime)
mount1 on /tmp/lima type virtiofs (rw,relatime)
mount0 on /home/development type virtiofs (rw,relatime)

The original does get the correct permissions and contents:

$ ls -ld /home/development
drwx------ 11 development development 352 May 25 13:33 /home/development

moenodedev avatar May 27 '24 18:05 moenodedev

Another stop/start makes the instance forget the previous mount:

$ mount | grep ^mount
mount0 on /home/development type virtiofs (rw,relatime)
mount1 on /tmp/lima type virtiofs (rw,relatime)

moenodedev avatar May 27 '24 18:05 moenodedev

Is it important to remove the empty directories ? We could add some rmdir code, matching the mkdir.

https://github.com/lima-vm/lima/blob/v0.22.0/pkg/cidata/cidata.TEMPLATE.d/boot/25-guestagent-base.sh#L11

https://github.com/lima-vm/lima/blob/v0.22.0/pkg/cidata/cidata.TEMPLATE.d/boot/05-lima-disks.sh#L31

EDIT: Not sure what VZ is doing, only know QEMU

afbjorklund avatar May 29 '24 06:05 afbjorklund

Supposedly one could add some systemd script to clean up the mount points, and something similar for openrc

https://www.freedesktop.org/software/systemd/man/latest/systemd-poweroff.service.html

/usr/lib/systemd/system-shutdown/lima.shutdown

/etc/local.d/lima.stop

EDIT: Nope, these scripts are run when all filesystems are unmounted (or read-only), so too late to clean up there

afbjorklund avatar May 29 '24 15:05 afbjorklund

Is it important to remove the empty directories ? We could add some rmdir code, matching the mkdir.

We could, as long as we only remove empty directories (and ignore errors when they are not empty).

We cannot force-remove the mount point because it may exist with content the user wants to keep, and it was only temporarily shadowed by a mount.

jandubois avatar May 29 '24 18:05 jandubois

I think rmdir should be OK (leave files and fail), but the timing is tricky...

I was trying with a "lazy" (fuser)unmount, but any processes using it needs to be stopped first

afbjorklund avatar May 30 '24 06:05 afbjorklund