My encrypted partitions (swap and home) are no longer mounted during system boot since today's cryptsetup-update. Downgrading to cryptsetup-1.1.2 solves the problem. This is in dmcrypt: swap=crypt-swap source='/dev/sda4' pre_mount='mkswap -f -L swap ${dev}' target=crypt-home source='/dev/sda7' key='/path/to/key' Relevant part of fstab: LABEL=home /home ext4 noatime 0 2 LABEL=swap none swap sw 0 0 Typing "cryptsetup -d /path/to/key /dev/sda7 crypt-home" also worked, so it was no problem with cryptsetup itself. I had the feeling, that the boot process completely ignores the dmcrypt config file, so I copied dm-crypt-start.sh and dm-crypt-stop.sh from cryptsetup-1.1.2 to /lib64/rcscripts/addons/ which also solved my problems. So it seems to me that there is something wrong with these two scripts. Reproducible: Always Steps to Reproduce: 1. upgrade to cryptsetup-1.1.3-r1 2. reboot Actual Results: No encrypted swap is created and crypt-home is not luksOpen'ed Expected Results: Create crypt-swap and luksOpen crypt-home Portage 2.1.9.25 (default/linux/amd64/10.0/no-multilib, gcc-4.4.4, glibc-2.11.2-r3, 2.6.36.2 x86_64) ================================================================= System uname: Linux-2.6.36.2-x86_64-Intel-R-_Core-TM-2_CPU_6600_@_2.40GHz-with-gentoo-1.12.14 Timestamp of tree: Sun, 02 Jan 2011 16:45:02 +0000 distcc 3.1 x86_64-pc-linux-gnu [disabled] app-shells/bash: 4.1_p7 dev-java/java-config: 2.1.11-r1 dev-lang/python: 2.6.6-r1, 3.1.2-r4 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 1.12.14-r1 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.13, 2.65-r1 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.4-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.30-r1 (sys-kernel/linux-headers) ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=x86-64 -pipe -mmmx -msse -msse2 -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/openvpn/easy-rsa /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -march=x86-64 -pipe -mmmx -msse -msse2 -msse3" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps y" FEATURES="assume-digests binpkg-logs distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://de-mirror.org/distro/gentoo/ http://gentoo.mneisen.org/ http://gentoo.tiscali.nl/ http://gentoo.mirror.pw.edu.pl/ http://gentoo.wheel.sk/ http://gentoo.telcom.net.ua/ http://gentoo.supp.name/ http://gentoo.virginmedia.com/ http://gentoo.moskalevskyi.name/ http://gentoo.prz.rzeszow.pl" LANG="de_DE.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="de" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://deltaflyer.subnet148.xyz/gentoo-portage" USE="3dnow 3dnowext X a52 aac accessibility acl acpi additions aim alsa amd64 ao bash-completion battery berkdb bidi bzip2 cairo caps cdda cddb cdinstall cdio cdparanoia cdr chroot cli consolekit cracklib crypt css cups cxx d dbus dell device-mapper dhclient dhcp dhcpcd disk-partition dlna dmraid dri dts dvb dvd dvdr emerald encode exif expat extra extras faac faad fat fax fbcon ffmpeg firefox firefox3 flac fontconfig foomaticdb fortran ftp fts3 fuse gallium gdbm gif gimp gles glib glibc-omitfp glitz gmp gnutls gpm gps graphite graphviz gtk gucharmap hpcups hpijs hpn http httpd hybrid-auth iconv icq icu idn ieee1394 imagemagick imap imlib inotify inquisitio iostats ipv6 irc jabber java java6 jingle joystick jpeg jpeg2k kpathsea kqemu lame laptop latex latex3 lcms ldap libnotify libsamplerate lightning lirc llvm lm_sensors logrotate loop-aes lua lua-cairo lua-imlib lvm lzma lzo mad matroska mbox md5sum mdadm mjpeg mmx mmxext mng modules motif mp3 mp4 mpeg mplayer msn mudflap nano-syntax ncurses network-cron networkmanager nfs nfsv3 nfsv4 nls nntp nptl nptlonly nsplugin ntfs ntp nvidia ogg opengl openmp otr pam pam_ssh parport pcre pdf perl plugins pm-utils pmu png policykit pop ppds pppd pvr python python3 qt3support qt4 quicktime rar rdesktop rdesktop-vrdp readline remote rss rtsp samba scanner science screen screenshot sdl server session sidebar smime smp smtp snmp sound sse sse2 sse3 sse4 sse4a sse5 ssh ssl ssse3 startup-notification stream suid svg sysfs tcl tcpd teletext tex4ht tftp threads thunderbird tiff tk truetype udev udisks unicode urandom usb userlocales v4l v4l2 vaapi vboxwebsrv vcd vde video vim-pager vim-syntax vim-with-x virtualbox vlm vorbis wav wavpack webdav webdav-neon wicd wifi wma wxwidgets x264 xattr xcb xcomposite xetex xine xinerama xml xorg xrandr xscreensaver xterm xterm-color xulrunner xv xvid xvmc yahoo youtube zip zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev joystick keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="intel nv radeon vesa" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Now I had some time to look over these two scripts and do some tests. The problem is, that they do not recognize the variable ${myservice} any more. If I use the new dm-crypt-start.sh and dm-crypt-stop.sh and replace : ${SVCNAME:=${myservice}} in both files with : ${SVCNAME:="dmcrypt"} things are working again.
(In reply to comment #0) > My encrypted partitions (swap and home) are no longer mounted during system > boot since today's cryptsetup-update. Downgrading to cryptsetup-1.1.2 solves > the problem. > Same probleme here.
That's interesting: I echoed $myservice into a file /wtf, to see which service name the script was setting. This is the content after booting: cat /wtf localmount So $myservice is set to localmount => the dm-scripts search a file called /etc/conf.d/localmount (which doesn't exist), and so they mount nothing at all.
Same here. Looks like the patch from #338876 breaks the whole thing for baselayout-1 users - i.e. anyone using stable.
Guys this is stable.
ALL: You went back to 1.1.2 from 1.1.3-r1. Could you please confirm if 1.1.3(-r0) works? Wolfram: Your changes from bug 338876 might have broken other systems. However I'm concerned that the fix proposed here would break your new functionality.
Confirmed, cryptsetup-1.1.3 works fine here. That's no surprise, this version uses exactly the same dm-crypt-start.sh and dm-crypt-stop.sh as cryptsetup-1.1.2 (diff shows no differences between them).
All test have been done on my stable amd64 system: sys-fs/cryptsetup-1.1.2: works upgrade to sys-fs/cryptsetup-1.1.3: works upgrade to sys-fs/cryptsetup-1.1.3-r1: doesn't work downgrade to sys-fs/cryptsetup-1.1.3: works again
It's very strange problem, my patch is pretty simple and shouldn't break anything. Yeah, I didn't tested my patch on baselayout-1, so, could you do the following tests: Test A: 1) Create /etc/conf.d/dmcrypt.something 2) cd /etc/init.d && ln -s dmcrypt dmcrypt.something 3) Try to start dmcrypt.something Test B: 1) replace 'ebegin "Setting up dm-crypt mappings"' with 'ebegin "Setting up dm-crypt mappings for ${SVCNAME%.*}"' in dm-crypt-start.sh 2) Try to run dmcrypt service and post output here Note: all works fine on baselayout-2. For me.
Have you read my comment #3? The dmcrypt-init-script is only for baselayout-2. On baselayout-1, dmcrypt-mappings obviously get started through localmount. I'm no expert, but a quick look in localmount shows on lines 65/66: # Start dm-crypt mappings, if any start_addon dm-crypt As I already stated, $myservice is set to localmount (instead dmcrypt on baselayout-2), so the new scripts set $SVCNAME to localmount (instead of dmcrypt) and search for a file called /etc/conf/localmount, which doesn't exist. So dm-crypt-start.sh decides in line 253 if [[ -f /etc/conf.d/${SVCNAME} ]] && [[ -x /sbin/cryptsetup ]] ; then to do nothing at all, because ! -f /etc/conf.d/${SVCNAME}. As long as dmcrypt was hardcoded, everything worked, since it searched for /etc/conf.d/dmcrypt even when started from localmount.
Is it possible to override SVCNAME before dmcrypt invoking?
(In reply to comment #11) > Is it possible to override SVCNAME before dmcrypt invoking? > Sorry I don't understand what you mean by that. Running /etc/init.d/dmcrypt start on baselyout-1 gives * The dmcrypt init script is written for baselayout-2 * Please do not use it with baselayout-1 If I change : ${SVCNAME:=${myservice}} #174256 to : ${SVCNAME:="dmcrypt"} #174256 in dm-crypt-start.sh it works. But I recognized that during bootup he tries to do the dmcrypt-mapping twice. One time before and one time after the fschk. The diff between the old and the new version really is small. In fact, it shows two lines, where dmcrypt was hardcoded in the old version. My guess is, that this was meant to be hardcoded, at least for baselayout-1.
Maybe it'll really better to maintain two different versions of dmcrypt stuff for both baselayouts?
(In reply to comment #13) > Maybe it'll really better to maintain two different versions of dmcrypt stuff > for both baselayouts? > Sadly, I can't help you with this decision. The only thing I know is: there is a really big regression for all stable users which should be solved asap. For all stable users, the current workarounds are: * Stay with cryptsetup-1.1.[23] * Use dm-crypt-start.sh and dm-crypt-stop.sh from cryptsetup-1.1.[23] * Change the line shown in comment #12 in dm-crypt-start.sh and dm-crypt-stop.sh. On my systems, the bootscripts try to do the mapping twice, the first time the mapping works, the second time they recognize that the partitions are already mapped. imho cryptsetup-1.1.3-r1 should even be hardmasked for baselayout-1.
I think this should cover BOTH sides for now. Potentially with a check for BL1 as well. Might need to introduce one more variable if changing myservice has external effects. # Bug #350399: on BL1, we need to handle compatability [ "${myservice}" == "localmount" ] && myservice="dmcrypt" : ${SVCNAME:=${myservice}} #174256
Can we please get testers for BOTH BL1 and BL2 to try my one-line change from comment #15?
BL1, amd64: I added the proposed line to dm-crypt-start.sh While booting the system the dmcrypt mappings get established again, but too late (after "Mounting local filesystems"), i.e. it doesn't work, because encrypted filesystems get neither fscked nor mounted.
Same problem here like in comment #17. I did some more tests and created some files, which show a part of my bootup messages: 01-cryptsetup-until-1.1.3.bootup-messages shows the startup messages with cryptsetup-1.1.[23]. Notice that even here, "* Setting up dm-crypt mappings ..." occurs twice, one time before and one time after "* Mounting local filesystems ..." Here only the first time it occurs the mappings are done. 02-cryptsetup-1.1.3-r1-with-first-patch-bootup-messages shows the bootup messages with : ${SVCNAME:="dmcrypt"} #174256. Here the mappings are done twice, but the second time the startup scripts output "dm-crypt mapping ??? is already configured". 03-cryptsetup-1.1.3-r1-with-second-patch-bootup-messages shows the bootup messages with the patch from comment #15. Here only the second time the mappings are done. As this occurs after mounting the local filesystems, this patch only works partly.
Created attachment 259045 [details] Bootup messages with cryptsetup-1.1.[23]
Created attachment 259047 [details] Bootup messages with : ${SVCNAME:="dmcrypt"}
Created attachment 259048 [details] Bootup messages with [ "${myservice}" == "localmount" ] && myservice="dmcrypt"
With BL-1, the addon is first run from "checkfs" and only later from "localmount", so maybe the line from comment #15 plus an analogous one for "checkfs" would do. can't test right now.
Confirmed. [[ "${myservice}" == "checkfs" || "${myservice}" == "localmount" ]] && myservice="dmcrypt" : ${SVCNAME:=${myservice}} works here on my machine exactly like setting : ${SVCNAME:="dmcrypt"} in the start and stop-scripts.
should be fixed now http://sources.gentoo.org/sys-fs/cryptsetup/files/1.1.3-dm-crypt-start.sh?r1=1.3&r2=1.4
I think your fix breaks post_mount hooks (I don't use them, so I didn't test it, but obviously dm_crypt_execute_localmount() will not execute now). My proposal (not tested yet): * revert your changes * add: local conf_file=/etc/conf.d/dmcrypt [[ ${SVCNAME} != ${SVCNAME%.*} ]] && conf_file=${conf_file}.${SVCNAME#*.} * replace /etc/conf.d/${SVCNAME} with ${conf_file} and apply the same changes to dm-crypt-stop.sh This should find the conf file in all cases without messing with SVCNAME and still allow multiple rc scripts, even for baselayout-1 users.
(In reply to comment #25) > I think your fix breaks post_mount hooks (I don't use them, so I didn't test > it, but obviously dm_crypt_execute_localmount() will not execute now). > My proposal (not tested yet): > > * revert your changes > * add: > local conf_file=/etc/conf.d/dmcrypt > [[ ${SVCNAME} != ${SVCNAME%.*} ]] && conf_file=${conf_file}.${SVCNAME#*.} > * replace /etc/conf.d/${SVCNAME} with ${conf_file} > and apply the same changes to dm-crypt-stop.sh > > This should find the conf file in all cases without messing with SVCNAME and > still allow multiple rc scripts, even for baselayout-1 users. > I don't know if it's related to post_mount hooks but I can't open any cryptsetup volumes because during every execution of cryptsetup it just throws an segfault with cryptsetup-1.1.3-r1 this didn't happen practically making my system unusable since this also happens with cryptsetup-1.2.0* Jan 10 15:49:36 lupus kernel: [ 54.774523] cryptsetup[6474]: segfault at ffffffffffffffff ip ffffffffffffffff sp 00007ffffdd265b8 error 14 afaik a very similar message also occured with cryptsetup-1.2.0-r1 please make systems usable again ! thanks !
it is not related. try another bug. this one in particular makes no mention at all of segfaults.
(In reply to comment #27) > it is not related. try another bug. this one in particular makes no mention > at all of segfaults. > yes, sorry - I just realized that it must be a toolchain-related issue
*** Bug 351081 has been marked as a duplicate of this bug. ***
Created attachment 259566 [details, diff] fix post_mount for baselayout-1.12.14-r1
Comment on attachment 259566 [details, diff] fix post_mount for baselayout-1.12.14-r1 this has whitespace damage, and i dont think it fixes all the issues
Created attachment 259589 [details, diff] updates to start and stop
I'd like to chime in and say that the committed fix is still causing the mappings to be run twice and isn't closing the mappings properly on shutdown. This ended up corrupting all my LVM metadata, which is especially unpleasant to recover from when everything's encrypted.
(In reply to comment #33) > I'd like to chime in and say that the committed fix is still causing the > mappings to be run twice and isn't closing the mappings properly on shutdown. > I also noticed that the new scripts do not luksClose the partitions. For that reason I keep using cryptsetup-1.1.2's scripts until this whole mess is really fixed.
said comments are useless. if you actually want to help out, test the proposed patches. or sit quietly and wait for someone else to.
My apologies for warning others that stable packages have the potential to trash their entire system. With regards to the patches, since you asked so nicely, I tested the latest one. init still attempts to setup dmcrypt mappings twice, except this time it fails completely. Errors reported are both file not found at like 304 of dm-crypt-start.sh: /etc/conf.d/checkfs & /etc/conf.d/localmount respectively.
The patch is missing one instance of /etc/conf.d/${SVCNAME} almost at the very bottom of 1.1.3-dm-crypt-start.sh. After fixing that, the script works for me. Michael: The script has to run twice. Once before the file systems are mounted to set up the mappings and once after the file systems are mounted to run the post_mount commands. In both cases it prints "Setting up dm-crypt mappings" to the console. So there's no error here. Btw. the scripts from 1.1.2 don't call luksClose either as far as I can see.
Martin: thanks. ive fixed that and pushed out 1.1.3-r3 http://sources.gentoo.org/sys-fs/cryptsetup/files/1.1.3-dm-crypt-start.sh?r1=1.4&r2=1.5 http://sources.gentoo.org/sys-fs/cryptsetup/files/1.1.3-dm-crypt-stop.sh?r1=1.1&r2=1.2 if people have new issues, file new bugs
