Spurious mount point
Hello, all
How can I track down the origin of this mount point:
/dev/sda2 on /home/hana type btrfs (rw,relatime,space_cache,subvolid=259,subvol=/@/.snapshots/1/snapshot/hana)
if it is not present in /etc/fstab? I shouldn't like to find/grep thoughout the whole filesystem.
Signature · 2 lines
() ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
Quoted 4 lines · Anton Shepelev
Hello, all
How can I track down the origin of this mount point:
Quoted 8 lines
/dev/sda2on/home/hanatype btrfs (rw,relatime,space_cache,subvolid=259,subvol=/@/.snapshots/1/snapshot/hana)if it is not present in
/etc/fstab? I shouldn't like to find/grep thoughout the whole filesystem.--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
Sounds like some service taking snapshots regularly is managing this. Maybe this is Mint or Ubuntu and you're using Timeshift?
Maybe it'll show up in the journal if you add boot parameter 'systemd.log_level=debug' and reboot; then use 'journalctl -b | grep mount' and it should show all instances logged instances of mount
events: systemd, udisks2, maybe others?
Signature · 1 line
Chris Murphy
A message that is not in the archive (sent off-list or not yet received): CAJCQCtSz+=uwXUFGxagoUOYxy99eCJGG-ezLVh0RO=vL=LReEg@mail.gmail.com
Chris Murphy to Anton Shepelev:
Quoted 10 lines
Quoted 6 lines
How can I track down the origin of this mount point:
/dev/sda2on/home/hanatype btrfs (rw,relatime,space_cache,subvolid=259,subvol=/@/.snapshots/1/snapshot/hana)if it is not present in
/etc/fstab? I shouldn't like to find/grep thoughout the whole filesystem.Sounds like some service taking snapshots regularly is managing this. Maybe this is Mint or Ubuntu and you're using Timeshift?
It is SUSE Linux and (probably) its tool called `snapper', but I have not found a clue in its documentation.
Quoted 5 lines
Maybe it'll show up in the journal if you add boot parameter 'systemd.log_level=debug' and reboot; then use 'journalctl -b | grep mount' and it should show all instances logged instances of mount events: systemd, udisks2, maybe others?
I will try that as soon as the client lets me reboot that machine.
Signature · 2 lines
() ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
Quoted 9 lines · Anton Shepelev
Chris Murphy to Anton Shepelev:
Quoted 7 lines
Quoted 6 lines
How can I track down the origin of this mount point:
/dev/sda2on/home/hanatype btrfs (rw,relatime,space_cache,subvolid=259,subvol=/@/.snapshots/1/snapshot/hana)if it is not present in
/etc/fstab? I shouldn't like to find/grep thoughout the whole filesystem.
Quoted 6 lines
Quoted 3 lines
Sounds like some service taking snapshots regularly is managing this. Maybe this is Mint or Ubuntu and you're using Timeshift?
It is SUSE Linux and (probably) its tool called `snapper', but I have not found a clue in its documentation.
I wasn't aware that SUSE was now using the @ location for snapshots, or that it was using Btrfs for /home. For a while it's been XFS with a Btrfs sysroot.
Signature · 1 line
Chris Murphy
Chris Murphy:
Quoted 3 lines
I wasn't aware that SUSE was now using the @ location for snapshots, or that it was using Btrfs for /home. For a while it's been XFS with a Btrfs sysroot.
Ours does use btrfs for /' and xfs for /home' *except* `/home/hana', which is strange and wonderful, because the standard usage is there in fstab and hana mount is created somewhere else.
Signature · 2 lines
() ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
16.10.2018 0:33, Chris Murphy пишет:
Quoted 10 lines · Anton Shepelev
Quoted 9 lines
Chris Murphy to Anton Shepelev:
Quoted 7 lines
Quoted 6 lines
How can I track down the origin of this mount point:
/dev/sda2on/home/hanatype btrfs (rw,relatime,space_cache,subvolid=259,subvol=/@/.snapshots/1/snapshot/hana)if it is not present in
/etc/fstab? I shouldn't like to find/grep thoughout the whole filesystem.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Sounds like some service taking snapshots regularly is managing this. Maybe this is Mint or Ubuntu and you're using Timeshift?
It is SUSE Linux and (probably) its tool called `snapper', but I have not found a clue in its documentation.
I wasn't aware that SUSE was now using the @ location for snapshots,
It does not "use @ for snapshots". It is using /@ as top level directory for root layout. This was changed from using / directly quite some time ago (2-3 years).
Snapshots are located in own subvolume which is either /.snapshots (if your install is old) or /@/.snapshots and is always mounted as /.snapshots in current root.
Quoted 3 lines
or that it was using Btrfs for /home. For a while it's been XFS with a Btrfs sysroot.
Default proposal is separate home partition with XFS, it can of course be changed during installation.
Note that after default installation /@/.snapshots/1/snapshot is default subvolume and *the* filesystem root, which gets mounted as "/". So it could be result of bind-mount of /hana on /home/hana (/hana is resolved to "default-subvolume"/hana => /@/.snapshots/1/snapshot/hana).