-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello James,
sorry for the late reply ...
Am 26.05.2011 17:08, schrieb jdiet...@fastmail.fm:
> After installing and setting up cryptsetup, I noticed that the root
> filesystem wasn't getting mounted read-only on shutdown anymore, thus
> causing it to be unclean on the next startup.
>
> Specifically, one of the last messages printed to the screen during the
> shutdown sequence was now this:
> Mounting root filesystem read-only...mount: / is busy
> Failed
>
> Then when the system was starting up again, fsck.reiserfs reported
> "Filesystem is NOT clean".
>
> This was very repeatable, so I did some investigation.
>
> I have just one device in my crypttab:
> # <target name> <source device> <key file> <options>
> name /name.enc_vol none
> precheck=un_blkid,check=blkid,cipher=aes-cbc-essiv:sha256,size=256,hash=ripemd160
>
> So I was surprised to discover *two* loopback devices configured:
>
> saturn:/home/jdietrch# losetup -a
> /dev/loop0: [0801]:15801 (/name.enc_vol)
> /dev/loop1: [0801]:15801 (/name.enc_vol)
> saturn:/home/jdietrch#
>
> Further investigation revealed the reason: The function
> handle_crypptab_line_start() checks to make sure the target device
> doesn't exist. If it does exist, the function exits with "return 0". But
> it doesn't remove the loopback device that was set up earlier in the
> function. So I added a call rm_lo_setup just before the "return 0" and
> now I only have one loopback device as expected:
>
> saturn:/home/jdietrch# losetup -a
> /dev/loop0: [0801]:15801 (/name.enc_vol)
> saturn:/home/jdietrch#
>
> Also, the message at the end of the shutdown sequence now says this:
> Mounting root filesystem read-only...done
>
> And when the system starts up again, fsck.reiserfs reports that the
> "Filesystem is clean"
>
> Here is the change I made as a patch:
>
> --- cryptdisks.functions.original 2011-03-11 04:05:53.000000000
> -0500
> +++ cryptdisks.functions 2011-05-26 10:46:18.000000000 -0400
> @@ -556,6 +556,7 @@
> # Make sure that target device doesn't exist
> if [ -b "/dev/mapper/${dst}_unformatted" ] || [ -b
> "/dev/mapper/$dst" ]; then
> device_msg "$dst" "running"
> + rm_lo_setup
> return 0
> fi
>
> I don't know if this is the correct or best way to fix problem noted at
> the beginning of this message, but in any case cryptsetup shouldn't
> prevent the system from shutting down cleanly.
>
> In case it matters, my system is running up-to-date squeeze.
>
> Let me know if you need any more information, or if there is anything
> else I can do to help.
Thanks a lot for this investigation. But the cryptsetup package changed
the way it handles loopback devices in the meantime. Upstream cryptsetup
has loopback support integrated since version 1.2.0. Therefore, I
removed all loopback-code from the Debian-specific scripts. Please give
the cryptsetup packages from Debian/testing a try, and see, whether it
fixes the problems for you. Unfortunately it's not possible to install
them flawlessly on Debian/Squeeze. In case that you don't have the
possibility to test a Debian/testing system, I can prepare cryptsetup
packages for you which work on Debian/Squeeze.
Greetings,
jonas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJODPWZAAoJEFJi5/9JEEn+q5kP/R6l6anTkAeRdRoPbf/DU9xj
KihxWW50NEc5KtbWhQLIoHK4dBVdf7RyP6xxdtQT7+BVmbClhHAQGD5Xp3vw5vHp
v/Ekt6vNUYv81yWZUAYwSmP6hBBwTwznsQJYUc+sDF2tWqoC2CTxuHgj+J6/YAAF
0sowAXDKcLdK31WmMJrR50OixJQt+TFKPDtECpB84Hs7UJgvTkRs7O9ZVZJlfSbq
qXCu9mWARlEC8Ybf37rfI8QVqrsJvrr/tHuVGwdCM3WwOunaRnxpLswFC5GElDlz
2ZP5weFHsa2AhOWv1Rx0Q5rvlrFfefO49RmoWvRDMi3I//Uw1FG9b01gC4kN15JN
WkBJkj4n3bdH0OMaNSHw7nNsE5of/EcNFh1fuTc05ESn54zGJomuqd/rd1uqSe/l
K7T5ItwQc6eAVofdsSl6TJ0jpglpYHW4FayNDXJisg8v1l28Rk85UObJzRXscMTx
BsEdg2L98Oy3wmmaSpe7+M2oNnxpa30aWUX784j1xa4wJEJFjJetrq5O7y7rm2M+
wP/5PV7wq9Kh68mx5Dv9e6ajVyzEVy1UMdpCqxHh6a/zSk4g3o9DI7L+ADGSm+zx
t0PvB4RmlWIxxoqxXVA7T+SZAeFBncUjSAyRro1ptxzAHrkbZ32CPxejYQGA1KMx
hTyl/4nloNxcRzhJsRCH
=eggZ
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
