Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.bugs.dist > #1200552 > unrolled thread

Bug#1072996: cryptmount: No longer working with current sid (e2fsck error)

Started byAgustin Martin <agmartin@debian.org>
First post2024-06-11 15:50 +0200
Last post2024-07-23 11:30 +0200
Articles 5 — 3 participants

Back to article view | Back to linux.debian.bugs.dist


Contents

  Bug#1072996: cryptmount: No longer working with current sid (e2fsck error) Agustin Martin <agmartin@debian.org> - 2024-06-11 15:50 +0200
    Bug#1072996: cryptmount: No longer working with current sid (e2fsck error) Leandro Lisboa Penz <lpenz@lpenz.org> - 2024-06-27 13:10 +0200
      Bug#1072996: cryptmount: No longer working with current sid (e2fsck error) Agustin Martin <agmartin@debian.org> - 2024-07-18 00:10 +0200
    Bug#1072996: /dev/mapper/ nodes being renamed deb-52fba5@lostmaths.uk - 2024-07-20 15:30 +0200
      Bug#1072996: /dev/mapper/ nodes being renamed Agustin Martin <agmartin@debian.org> - 2024-07-23 11:30 +0200

#1200552 — Bug#1072996: cryptmount: No longer working with current sid (e2fsck error)

FromAgustin Martin <agmartin@debian.org>
Date2024-06-11 15:50 +0200
SubjectBug#1072996: cryptmount: No longer working with current sid (e2fsck error)
Message-ID<IOa2S-2a13-1@gated-at.bofh.it>
Package: cryptmount
Version: 6.2.0-2
Severity: normal

Dear Maintainer,

I have noticed that cryptmount is no longer working well with current
sid in my box. This happened recently, although I do not know where
this started to happen,

$ cryptmount LUKS-test
...
e2fsck 1.47.1 (20-May-2024)
Error determining size of the physical device: No such file or directory
unable to stat() device node
Failed to remove device-mapper target "LUKS-test"

If I add the noextfsck flag to cmtab, mount succeeds,

$ cryptmount LUKS-test

However, I have problems when unmounting,

$ cryptmount -u LUKS-test
Target "LUKS-test" does not appear to be mounted

although device is mounted and accesible,

I noticed that when using cryptmount /dev/mapper/LUKS-test seems not
present, although device is mounted. When using the normal cryptsetup close flow

# umount /media/luks-testdir
# /sbin/cryptsetup close LUKS-test

device is properly unmounted.

If I follow the cryptsetup flow for opening

# /sbin/cryptsetup open /dev/sdc1  LUKS-test
# mount /dev/mapper/LUKS-test /media/luks-testdir/

/dev/mapper/LUKS-test is present and 'cryptmount -u LUKS-test' works.

LUKS-test {
  keyformat=luks
  dev=/dev/sdc1
  keyfile=/dev/sdc1
  dir=/media/luks-testdir
  flags=nofsck
  fstype=ext4
}


Thanks for your work on cryptmount.

Regards,

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (50, 'testing'), (50, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cryptmount depends on:
ii  libc6               2.38-13
ii  libcryptsetup12     2:2.7.2-2
ii  libdevmapper1.02.1  2:1.02.196-1+b1
ii  libgcrypt20         1.10.3-3
ii  libudev1            256~rc4-1

Versions of packages cryptmount recommends:
ii  e2fsprogs  1.47.1-1
ii  udev       256~rc4-1

Versions of packages cryptmount suggests:
ii  dmsetup  2:1.02.196-1+b1

-- Configuration Files:
/etc/cryptmount/cmtab changed [not included]

-- no debconf information

[toc] | [next] | [standalone]


#1202436

FromLeandro Lisboa Penz <lpenz@lpenz.org>
Date2024-06-27 13:10 +0200
Message-ID<ITVaN-5Y0i-7@gated-at.bofh.it>
In reply to#1200552
Package: cryptmount
Version: 6.2.0-2
Followup-For: Bug #1072996

Dear Maintainer,

FWIW I am also observing this, but with a slightly different symptom:

$ cryptmount crypted
e2fsck 1.47.1 (20-May-2024)
/dev/mapper/crypted: clean, 456/28672 files, 58320/114688 blocks
[cryptmount-mount]: /home/l/crypted: fsconfig system call failed: /dev/mapper/crypted: Can't lookup blockdev.
       dmesg(1) may have more information after failed mount system call.
unable to stat() device node
Failed to remove device-mapper target "crypted"

dmesg said only:

[9999.9999] loop2: detected capacity change from 0 to 262144

So the system has been able to detect the size of the device, though it
still failed.

Adding "flags=nofsck" to cmtab also fixed my case.



-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (520, 'testing'), (510, 'stable'), (150, 'unstable'), (120, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.8.12-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cryptmount depends on:
ii  libc6               2.38-13
ii  libcryptsetup12     2:2.7.2-2
ii  libdevmapper1.02.1  2:1.02.196-1+b1
ii  libgcrypt20         1.10.3-3
ii  libudev1            256.1-2

Versions of packages cryptmount recommends:
ii  e2fsprogs  1.47.1-1
ii  udev       256.1-2

Versions of packages cryptmount suggests:
ii  dmsetup  2:1.02.196-1+b1

-- Configuration Files:
/etc/cryptmount/cmtab changed:
syncrypted {
  dev=$(HOME)/crypted.vol
  dir=$(HOME)/crypted
  fstype=auto
  flags=nofsck
  keyformat=luks
}


-- no debconf information

[toc] | [prev] | [next] | [standalone]


#1204687

FromAgustin Martin <agmartin@debian.org>
Date2024-07-18 00:10 +0200
Message-ID<J1l0u-2PRp-3@gated-at.bofh.it>
In reply to#1202436
On Thu, Jun 27, 2024 at 11:58:34AM +0100, Leandro Lisboa Penz wrote:
> Package: cryptmount
> Version: 6.2.0-2
> Followup-For: Bug #1072996
> 
> Dear Maintainer,
> 
> FWIW I am also observing this, but with a slightly different symptom:
> 
> $ cryptmount crypted
> e2fsck 1.47.1 (20-May-2024)
> /dev/mapper/crypted: clean, 456/28672 files, 58320/114688 blocks
> [cryptmount-mount]: /home/l/crypted: fsconfig system call failed: /dev/mapper/crypted: Can't lookup blockdev.
>        dmesg(1) may have more information after failed mount system call.
> unable to stat() device node
> Failed to remove device-mapper target "crypted"
> 
> dmesg said only:
> 
> [9999.9999] loop2: detected capacity change from 0 to 262144
> 
> So the system has been able to detect the size of the device, though it
> still failed.
> 
> Adding "flags=nofsck" to cmtab also fixed my case.
...

> -- Configuration Files:
> /etc/cryptmount/cmtab changed:
> syncrypted {
>   dev=$(HOME)/crypted.vol
>   dir=$(HOME)/crypted
>   fstype=auto
>   flags=nofsck
>   keyformat=luks
> }

Hi,

Seems that this is affecting LUKS systems. I cannot reproduce this in a non
LUKS device I also hace here.

Regards,

-- 
Agustin

[toc] | [prev] | [next] | [standalone]


#1204936 — Bug#1072996: /dev/mapper/ nodes being renamed

Fromdeb-52fba5@lostmaths.uk
Date2024-07-20 15:30 +0200
SubjectBug#1072996: /dev/mapper/ nodes being renamed
Message-ID<J2ijU-3tMv-1@gated-at.bofh.it>
In reply to#1200552
Thanks Agustin & Leandro for highlighting this issue, and for finding a
workaround.

After some investigation, I think I have narrowed the problem down to
changes in behaviour of the automatic setup of entries in the /dev/
filesystem with the newer trixie tooling. It appears that although it
was safe to assume that cryptmount devices would always be named
"/dev/mapper/<target_name>", there is a tendency for these to be
automatically renamed into symlinks of the form
"/dev/disk/by-id/dm-name-<target_name>". This even appears to occur when
mke2fs is run on a a device in /dev/mapper/, which subsequently disappears.

I'm currently exploring how best to handle this portably within
cryptmount, perhaps via dm_device_get_name(), but it's obviously awkward
that we can no longer just use dm_dir() as the path prefix for devices
created by cryptmount.

RW Penney

[toc] | [prev] | [next] | [standalone]


#1205222 — Bug#1072996: /dev/mapper/ nodes being renamed

FromAgustin Martin <agmartin@debian.org>
Date2024-07-23 11:30 +0200
SubjectBug#1072996: /dev/mapper/ nodes being renamed
Message-ID<J3k0i-46Qf-11@gated-at.bofh.it>
In reply to#1204936
On Sat, Jul 20, 2024 at 02:11:41PM +0100, deb-52fba5@lostmaths.uk wrote:
> Thanks Agustin & Leandro for highlighting this issue, and for finding a
> workaround.
> 
> After some investigation, I think I have narrowed the problem down to
> changes in behaviour of the automatic setup of entries in the /dev/
> filesystem with the newer trixie tooling. It appears that although it
> was safe to assume that cryptmount devices would always be named
> "/dev/mapper/<target_name>", there is a tendency for these to be
> automatically renamed into symlinks of the form
> "/dev/disk/by-id/dm-name-<target_name>". This even appears to occur when
> mke2fs is run on a a device in /dev/mapper/, which subsequently disappears.

Hi,

Thanks for caring of this.

Seems that there are some strange differences between what happens when
plain cryptsetup is used and when is cryptmount what is used. I am not sure
that cryptmount is the only one to blame here, may be has just triggered a
problem somewhere else.

I have been trying to look more carefully at what happens externally in
both cases (for cryptmount, only with flags=nofsck, which should be enough
for a first approach). Results are shared below in the hope they can add
something useful.

Regards,

### ------- The cryptmount way (using flags=nofsck) -------

$ cryptmount LUKS-test

Succeeds, but no  LUKS-test under /dev/mapper.
Device is accesible under mount point /media/luks-testdir

$ find /dev -name '*LUKS-test*'
/dev/disk/by-id/dm-name-LUKS-test

# cryptsetup status LUKS-test
/dev/mapper/LUKS-test is active and is in use.

with no LUKS-test entry under /dev/mapper.

# grep -ri LUKS-test /var/ 2> /dev/null
Relevant line:
/var/log/syslog:2024-07-23T10:26:11.807221+02:00 mybox (udev-worker)[29914]: dm-7: Failed to create/update device symlink '/dev/mapper/LUKS-test', ignoring: File exists

# find /sys/ -iname '*LUKS-test*'

# grep -ri LUKS-test /sys/ 2> /dev/null
/sys/devices/virtual/block/dm-7/dm/name:LUKS-test

$  cryptmount -u LUKS-test
Target "LUKS-test" does not appear to be mounted

$ mount:
 /dev/mapper/LUKS-test on /media/luks-testdir type ext4 (rw,relatime,stripe=8191)

# umount /dev/mapper/LUKS-test
succeeds even if /dev/mapper/LUKS-test is not present

# cryptsetup close LUKS-test

OK.

### -------- The cryptsetup way ---------------------------

# cryptsetup open /dev/sdc1  LUKS-test

$ find /dev -name '*LUKS-test*'
/dev/disk/by-id/dm-name-LUKS-test
/dev/disk/by-id/dm-uuid-CRYPT-LUKS1-*******MY-DEVICE-UUID*******-LUKS-test
/dev/mapper/LUKS-test

# cryptsetup status LUKS-test
/dev/mapper/LUKS-test is active.

with LUKS-test entry under /dev/mapper (as previously reported by find).

# find /sys/ -iname '*LUKS-test*'

# grep -ri LUKS-test /sys/ 2> /dev/null
/sys/devices/virtual/block/dm-7/dm/uuid:CRYPT-LUKS1-*******MY-DEVICE-UUID*******-LUKS-test
/sys/devices/virtual/block/dm-7/dm/name:LUKS-test

# mount /dev/mapper/LUKS-test /media/luks-testdir/

mount:
/dev/mapper/LUKS-test on /media/luks-testdir type ext4 (rw,relatime,stripe=8191)

# umount /dev/mapper/LUKS-test

# cryptsetup close LUKS-test

-- 
Agustin

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.bugs.dist


csiph-web