I can confirm that this issue still seems to affect simple-cdd 0.6.9 on
bookworm as of mid-May 2023 (including debian-cd version 3.2.1).
I too have tried 'export FORCE_FIRMWARE=1' together with 'export
NONFREE_COMPONENTS="non-free non-free-firmware"',
'mirror_components="main non-free non-free
Thanks, Helge - that's very helpful.
I'll roll this into the next release of cryptmount.
Your changes should also be visible in the (new) GitHub repository at
https://github.com/rwpenney/cryptmount/commit/e631e0d98238618c455f409292618f624ab80c3a
Danke, Helge.
I'll include your updated translations in the next (bugfix) release of
cryptmount.
Kind regards,
RW Penney
I think I've found the origin of the problem, and this is related to a
change made within libcryptsetup during January 2017, in the function
device_internal_prepare(). This now checks that both getuid() and
geteuid() return zero before attempting to configure a loopback device.
Other areas of libcr
Hello Andrey,
Thanks for finding this issue with cryptmount, and for your helpful
stack traces and configuration information.
I am still investigating this issue, and have created a new test
specifically for LUKS partitions within ordinary files to help
narrow-down the source of the problem.
Coul
Hello Guillem,
Thanks for your suggested improvement to the cryptmount init.d script,
and for your helpful patch.
I have just released version 5.2.1 of cryptmount, which incorporates
your improvements. I hope this will soon be available as a Debian
package.
Kind regards,
RW Penney
Thanks for reporting this bug.
I think I have diagnosed the problem - this is probably due to a change
in behaviour of /sbin/fsck, where it now relies on the PATH
environmental variable to find /sbin/fsck.ext3 etc. instead of just
searching /sbin and a few other standard places. That is a signific
cryptmount-5.1-3 is available now at
http://www.rwpenney.org.uk/software/index.html#cryptmount .
I am hoping my sponsor will be able to upload it into Sid soon.
Hello Andreas,
Thanks for reporting this bug.
I have already been working on a cleaner version of the postinst script
making better use dh-systemd, which should fix other piuparts problems
relating to unwanted files left after uninstallation.
I hope to have a 5.1-3 available very soon.
Th
David,
Thanks for finding this issue with the cryptmount-setup script.
I'm currently looking into a fix that will form part of the next
upstream release of cryptmount.
In case you haven't already found a work-around, the cryptmount
man-page describes (in the "example usage" section
For info, attached is a patch (relative to cryptmount-5.1-1)
which I believe fixes the automake issue, as well as the outstanding
lintian warnings.
diff --git a/debian/changelog b/debian/changelog
index 86f7fa1..eba7e8b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+cryptmo
Thanks for your bug-report.
I have already been working on fix for this issue, and have
cryptmount-5.1-2 awaiting upload with the support of my sponsor.
For the time being, these packages are available at
http://www.rwpenney.org.uk/software
The new build-system uses debhelper v7 and dh-autorecon
Hello Gilles,
Thanks for your bug report about cryptmount, and the
helpful reference to bug #759263.
I've just re-run the cryptmount test-suite on my Jessie test
system, and all the tests seem to pass. I suspect this means that the
problem you're having is not related to bug #75926
This bug seems to be related to apparent incompatibilities between the
latest libcryptsetup and libgcrypt11. Preliminary experiments with
libgcrypt20 indicate that the problems with non-privileged access to
LUKS partitions can be fixed simply by compiling with libgcrypt20-dev
in place of libgcrypt1
Hello Dave,
Thanks for your helpful bug report.
It would appear that this issue is related to changes in libcryptsetup
between versions 1.6.4 and 1.6.6 (which has just entered
debian-testing). The issue you've identified may be related to changes
in libcryptsetup connected with allowing non-privil
Hello Steve,
Thanks for identifying this issue with @ETCDIR@,
and for filing a bug-report.
I've attached a patch which should sort out the issue.
I hope to have an updated release of cryptmount available soon.
Kind regards,
RW Penney
diff --
Hi Don,
Thanks for your efforts in patching this bug in cryptmount.
As maintainer, I'm sorry that I wasn't able to get a full version
of the package uploaded to the Debian servers as promptly as I would
have liked. Hopefully version 4.3.1-1 will be available in sid within
the next
Hello Teodor,
Thanks for finding this issue with the cryptmount build-system.
I believe the problem is easily fixed by removing the explicit
dependency on 'libdevmapper' within the debian/control file.
I've attached a patch which seems to sort out the problem on
my debian-
severity 656346 fixed
thanks
It would appear that the symptoms may have been caused by attempting
to execute 'cryptmount --prepare' on a device that already had a
mounted filesystem. This condition is apparently trapped by
the device-mapper library.
--
To UNSUBSCRIBE, email to debian-bugs-dist
Hello,
Thanks for your bug report.
I think you'll need to provide some basic information about how
you're using cryptmount before I can make any attempt to resolve
this bug report.
I have frequently tested 'cryptmount --prepare' on a wide range
of linux distros, including
Hi George,
You may like to know that cryptmount-4.3 will now have
support for simple environmental variables within /etc/cryptmount/cmtab
so that you can use something like 'mountoptions=uid=$(USERNAME)' to
give you slightly more flexibility when mounting VFAT partitions.
This feat
Hi George,
Thanks for your feedback on cryptmount.
Have you tried using the 'mountoption' parameter in your
/etc/cryptmount/cmtab? One of the options for mounting fat/vfat
filesystems is uid=???, which looks like it might be suitable for
setting the ownership of the mounted filesys
Hello Paul,
Thanks for spotting this issue, and for your patch.
As this may affect the interpretation of the 'startsector' and
'numsectors' parameters in users' /etc/cryptmount/cmtab files, I think
it safest to incorporate this fix into the next release of cryptmount
rather than an
Hello Harri,
Thanks for flagging this issue with cryptmount & chroot.
As per previous correspondence on bug#551533, I don't think this causes
failure of cryptmount's postinst script, but merely leads to modprobe reporting
that is was unable to run successfully.
Based on a recipe within the udev
Hello Vefa,
Thanks for your bug report, and for your helpful patch.
I'll make sure your patch is included in future releases
of cryptmount, and hope that you will remain a "mostly happy" cryptmount
user at least until then.
Kind regards,
RW
Harri,
Thanks for your bug-report.
It's not clear that this is a bug in cryptmount, and it
likely that the problems you're having are very dependent on the
details of your 'chroot' filesystem.
It would appear that the absence of the '/lib/modules/...' files
within your chr
Hello Petter,
Thank you for finding this bug in cryptmount's init.d scripts,
and for your helpful patches.
I have now merged your patches (with minor modifications
to the dependency on $syslog) to create a new upstream version, 4.0.1,
which should now be available at http://www.sou
Hello Ryo,
Could you check that you are using "fsoptions=uid=1000"
rather than "opts=..." in your /etc/cryptmount/cmtab?
I've had a quick look at the parser within cryptmount-4.0
and can't see any obvious reasons why using "fsoptions" with a parameter
that includes an equals sign s
Hi Dan,
Could you check that you are using cryptmount-3.1.2, which still
hasn't entered the 'testing' release yet? (Only 3.1.1 is in 'testing'
as of 16th March.) Running 'cryptmount --version' should confirm this.
I've just re-run cryptmount's 'mudslinger' testing routings from
ver
This is pretty easy to fix with a call to gcry_check_version() within
kmgrcy_init_algs().
I've attached a patch that should be a temporary fix for version 3.1.1.
I'm in the process of preparing an updated release (3.1.2), together with an
improved version 4.0.
RWP
+-- on Tue, Feb 24, 2009 at 04
Dear Kai,
Many thanks for your email - I would be delighted to support any
effort to produce a German localization of cryptmount.
As regards the "user-%lu" string, this is issued when someone
tries to unmount a filesystem that was mounted by a different user. The
message is suppose
Hello Julien,
Thanks for your suggestion about cryptmount.
I'm not convinced that this is a problem with either the
upstream package, or with the debian build. I can find no reference
to any strip/ld -s/install -s in the upstream package; an ordinary
"make install" of the upstream
Hi Carl,
Thanks for your bug report.
This is indeed a sensible feature request, and your suggested fix
is a workable solution. My slight reservation is that 'cryptmount -ua'
will only deal with targets that are listed in /etc/cryptmount/cmtab
(ignoring any created via the --config-
Erich,
Thanks for reporting the non-compliances in cryptmount's init-script,
and for your helpful patch. I've incorporated your patch and tried to
make the script more LSB compliant in its support for the 'status'
argument and in its return-codes.
Before I issue a revised version o
Package: wnpp
Version: 1.0
Severity: wishlist
I would like to propose the package 'cryptmount' (version 1.0.1) for
inclusion in the debian distributions.
cryptmount is a utility for on-demand user-mode mounting of
encrypted filesystems based on the device-mapper (dm-crypt) infrastructure
of the 2
35 matches
Mail list logo
