The new versions does _not_ include the crypto-patch, this is an real showblocker (at least
So sad that this crypto-thing is not included in official kernel-tree, it is also missing in
util-linux. So sad too, that there is also very rar support in gentoo. There where several
gentoo-sources without the crypto-patch (beside the fact that gentoo-sorces is the only
kernel suppoting it and is not at current date this time) and now it is also missing in
Steps to Reproduce:
Not able to mount any crypto-filesystem, -k flag in losetup is missing...
To mount my crypto-partitions etc.
The epatch-Line for the crypto-Patch is commented out. The patch is from 2.11z (or
earlier), does it work with 2.12?
Have you tested this with the version 2.12? It has theoretical crypto support.
I cannot test this side, so if you don't mind, just have a look.
Sure, i've tested it and thatsway i've filed this bug. Crypto-support was included in prior
versions but is missing in 2.12. Just check if your losetup-command supports encryption and the
-k option, that should be a very simple test and does not depend on any crypto-filesystem (or
whatever). I've downgraded to 2.11z-r7 and now it's working again.
I've reinstalled 2.12 just to prove it's not working. This is what i get:
toral init.d # /sbin/losetup -e twofish -k 128 /dev/loop0 /dev/hda2
/sbin/losetup: invalid option -- k
/sbin/losetup loop_device # give info
/sbin/losetup -d loop_device # delete
/sbin/losetup [ -e encryption ] [ -o offset ] loop_device file # setup
toral init.d # /sbin/losetup -e twofish /dev/loop0 /dev/hda2
ioctl: LOOP_SET_STATUS: Invalid argument
This is the output from loetup from 2.11z-r7 (which works fine):
toral ebuilds # losetup
losetup loop_device # give info
losetup -d loop_device # delete
losetup [ options ] loop_device file # setup
where options include
--offset <num>, -o <num>
start at offset <num> into file.
--pass-fd <num>, -p <num>
read passphrase from file descriptor <num>
instead of the terminal.
--encryption <cipher>, -e <cipher>
encrypt with <cipher>.
Check /proc/crypto/cipher for available ciphers.
--keybits <num>, -k <num>
specify number of bits in the hashed key given
to the cipher. Some ciphers support several key
sizes and might be more efficient with a smaller
key size. Key sizes < 128 are generally not
--phash <hash>, -P <hash>
specify <hash> to use for hashing the passphrase
(supported: rmd160old, sha256, sha384, sha512)
Come on guys, i'm really disappointed. This is a real blocker but nothung changed for nearly
days. There is even no assignment to some Responsible. As long as this problem is not solved,
the current ebuild has to be masked (in my humble opinion).
I've done some investigation, but was'nt able to find an crypto-patch for 2.12 (the one from
2.11z does'nt seem to work). It seems in current 2.5.x kernels is an new Crypto-API included,
which prevents us from patching util-linux any longer, but as long gentoo-sources is 2.4.20 we
still need this (gentoo-) crypto-Patch as included in 2.11*.
I'll keep looking for an patch...
Just to support your case: I've had exactly the same experience. Since all my productive sources
(that's what I earn my money with) are on an encrypted filesystem on a laptop, I _had_ to go
back to version 2.11z-r7 for now.
Thats exactly my problem! I've no problems at my desktops at home, but my laptops uses
crypto-fs of course (as everybody should).
Still no action from the gentoo-guys. I thought gentoo is cool and secure...
To be fair the AES-loop project currently has no patch for util-linux-2.12 either, maybe they are having problems making it work?
isn't this a reason for masking this ebuild?
I just checked on this ebuild and its ~arch masked (as of July 29th)
Now here is a tip, Try not to depend (for you jobs sake) on ebuilds that are ~arch masked. This means its in development and or is not stable for said arch yet.
Me too. I had to revert back to version 2.11z-r7. Can't mount any encrypted filesystems via the loopback device with 2.12.
Yes, this is why it is ~arch masked. We need testing of it, but until there
is a new patch for the crypto stuff, or until somebody ports the patch ...
I do not use crypto, and as it is a high risk patch, I'll rather not try to
port it, as I could then be opening holes ...
Created attachment 16144 [details]
failed patch output
i uncommented the crypto patch line in the 2.12 ebuild, which failed with the attached output
2.12 and on probably wont have crypto support from what I understand, as that version and on are somehow supposed to already tie into the crypto hooks of the 2.6 kernels.
I also had some problems recently with crypto support (running a 2.4.22-ac1 kernel and util-linux 2.12). But I just tried the 2.6.0-test5 kernel and now it works. Seams like the new util-linux is incompatible with 2.4 kernels. Let's hope the stable 2.6 comes soon...
Just to add my 2 cents and resume the situation: As of 2.4.22, they included
cryptoapi with mainstream kernel. As far as I can see it's a backport from
the 2.5/2.6 line and kerneli.org no longer provides a cryptoapi patch for
.22 or later. However, vanilla .22 does not provide the cryptoloop functionality.
kerneli.org still provide a patch for .22 to add cryptoloop support. Now,
such a patched .22 kernel does NOT work correctly with util-linux-2.11z-r6,
which is the current stable version in portage.
However it seems to work fine with util-linux-2.12 (which is no big surprise
as 2.12 specifically adds support for the 2.6 type cryptoapi stuff). However
what they did not add in 2.12 is the -k flag to specify the keysize of the
encryption key. Result: All existing encrypted partitions won't mount unless
they were encrypted with whatever 2.12 uses as default keysize (which I think
is only 32 bit if I read the source code correctly).
Thus, what we need is a patch to add the -k flag functionality into util-linux
2.12, then make sure that 2.11z is used for pre .22 kernels and the patched
2.12 for post .22 kernels.
Created attachment 18674 [details, diff]
-k support patch
This patch adds -k support to losetup, note this is ONLY the short option.
This patch works for _ME_ I must stress that it works for ME, in theory it
should work for anyone using a 2.6 beta kernel with crypto api support
configured, but I cannot / will not garuntee that.
This patch is largely derived from re-coding parts of the 2.11y patch that
in portage, but with a few changes to accomodate the 2.6 crypto api etc..
2.4 Kernel users sorry, but while running util-linux with this patch crypto
filesystems didnt work for me, I didnt try too hard though so someone feel
to look at it.
All in all, be careful when using this.
Just a thought: If the package does not have "crypt" support, I would remove
the USE flag from IUSE, so that unsuspecting users (like me) aren't mislead
to believe it _would_ have support for cryptoloop.
Does anybody know about an up-to-date 2.4-kernel-source which includes the
crypto-api (incliding crypto-loop) which is inlcuded in the outdated gentoo-sources?
The crypto-patch in ac-sources seems to incompatible with the old _and_the
new version of util-linux!? Any help? If i use kernel-2.6 i've several problems
to get my pcmcia-devices working (especialy ISDN), so in conclusion gentoo
(at least an up to date gentoo) is not usable for laptops in the moment (no
crypto-filesystem for 2.4-kernels which every laptop needs, limited pcmcia-supported
when using 2.6-kernels which is needed by many/some laptops)...
Again: Please mask util-linux-2.12 or introduce an special USE-Flag (or whatever)
to filter it out...
Guys, i found an acceptable solution which may also work for you. Due to
the fact, that the former/old crypto-api is incompatible with util-linux
i decided to upgrade to kernel-2.6. Unfortunatly this is not an good idea
for laptop-users, 'cause there are some essential things not working properly
(f.i. PMCIA and special keys found on some laptops). But i created an new
crypto-filesystem using the new crypto-api from kernel 2.6. Now that i've
been forced to downgrade back to kernel-2.4 i found that in current releases
the new crypto-api is also included (did'nt know about that fact before,
'cause gentoo-sources ist still hopeless outdated). The only thing you have
to do, is to patch any vanilla-[prepatch-]sources with the cryptoloop-jari
patch and VOILA, your problems are gone. Unfortunatly it will not work using
the aa-sources - in that case you'll get some patching warnings and compilation-errors.
The good thing is, you will also be fully compatible to kernel 2.6 in this
point, where the cryptoloop seemsto be part of the official branch (in case
anybody knows why, and why not in kernel-2.4 please let me know).
To the gentoo guys: I'll leave this as a blocker, because there is no source-ebuild
in gentoo for kernel-2.4 including cryptoloop along with the new crypto-api,
so the current unmasked util-linux is still not usable. If you are interessted
i'll take care of an source-ebuild based on vanilla-sources or better vanilla-prepatch-sources
including the cryptoloop-patch. Also i've some ideas which other ebuilds
could tolerate an update...
To be honest here this package just seems to be in state of transition and
seems to be the only thing blocking unix-linux-2.12 from going stable as
far as I can tell. As crypto support is considered more as fluff than apart
of the core system I see no reason why it should no go stable anyway. (sorry
Also as azarah alone seems to maintains 90% of everything in "emerge system"
he tends to find himself a very busy man, so I would assume that any patches
What do you mean by "sorry crypto users"? Is gentoo just for non-laptop users?
It's a fact that util-linux is incompatible to the ancient gentoo-sources
(which is still the official kernel-source for gentoo) at least when it comes
to crypto-filesystems (i also remember some words like "gentoo is secure").
What do you mean by "patches are welcome"? IMHO the best (only acceptable?)
solution would be, to update gentoo-sources or at least to have an official
supported patched kernel-source. As i wrote before, i'll be happy to provide
you whith such an ebuild. I'll post it as an new ebuild this evening and
link a dependency from this bug to the new ebuild.
Does this make sense for you? If not please let me know, what other help
i may provide.
I'll also investigate, why cryptoloop is part of kernel 2.6 but not in current
releases of 2.4 nor the official patch-sets. I guess this problem will go
away in a while (but for now it still exist).
Just added the new ebuild for cryptoloop-sources as Bug 30984 and set a dependency
to this one. This might fix this one (or at least remove the blocking-severity).
Well, I'm currently testing a 2.4.22 based gentoo-test-sources, it'll become
gentoo-sources once all the bugs are worked out of it. Can you give it a
try and let me know if it works for you.
$ emerge gentoo-test-sources
First Impression: Looks quite good concerning the available options, but
cryptoloop is still missing (this is what we talking about). Please apply
patch-cryptoloop-jari-188.8.131.52 as well and all of us should be happy.
Applying the patch manually results in two warnings, but compiles fine. I
remember to get a lot more problems when trying to patch aa-sources & Co.
BTW: I would also recommend to apply a current prepatch, is it not included
already. Is there a list, which patches you've included in this kernel?
For me worked (I use twofish):
vanilla linux-2.4.22 + patch:
util-linux-2.12 + patches (in order):
and the program:
# losetup -e twofish -k 256 /dev/loop1 /dev/hda5
I use now:
# insmod cryptoloop
# insmod twofish
# ./hashalot rmd160 | losetup -p0 -e twofish-256 /dev/loop1 /dev/hda5
Just my 2 cents. :)
*** Bug 32502 has been marked as a duplicate of this bug. ***
Cryptoloop WFM with patches from comment 28.
Sorry for spam. Comment 27 I meant. Stupid typo.
What is going here? Now, that _you_ _have_ _forced_ everyone to switch to the new crypt-api (coming with cryptoloop-jari) you include a patch for the cryptoapi in util-linux-2.12-r1 to get the old behavior (which results in losetep requestung the keysize again).
Thats not fun anymore!
Solution for anyone who might also affected: USE -crypto in my make.conf, hoping that this would not impact other things...
Is the crypto Flag used in other ebuilds as well? If so, i would recommend a separate USE-fkag for the losetup-patch? I relly bet, this patch is also not compatible to kernel 2.6 (not tested so far)....
OK, it seems not that simple to just use USE=-crypt, because it is used in some other ebuilds as well (mozilla is one the more known of it).
Also, in a bunch of kernel-sources it is used.
So, it would a solution to split the single Flag crypt in two, lets say oldcryptoapi and the former crypt, which should not change...
I committed the util-linux-2.12-r1 ebuild with the patches
from comment #27 http://bugs.gentoo.org/show_bug.cgi?id=25192#c27
before I had even seen this bug report. I did this to fulfill my
own desire to get cryptoapi/cryptoloop with 2.6.0-testX kernels
working, and it works quite well. If you all had reviewed the
ChangeLog, you would have seen how to make it compatible via
following the thread.
is the short listing of commands showing that it is compatible with
old jari setups.
In short, the keylength is passed via the encryption method now,
e.g. -e aes-cbc-256
instead of passing a -k parameter.
Also, losetup no longer has it's own internal hashing algorithms,
so the 2.12-r1 release depends on hashalot which provides a few.
Please refer to that mailing list post for more info.
And yes, it does really work for 2.6.0 as well, I'm using it
for my local CVS repository at work.
Moving this bug away from blocker to normal.
*** Bug 34985 has been marked as a duplicate of this bug. ***
It now works for me. Thanks for the link to he mailing lists. That helped me know how to mount my loop again with the new utils.
New ebuild works as advertised.
I have to mention that to use hashalot as user, you should set the suid bit on it.
Else it won't lock the password in memory.
*** Bug 36882 has been marked as a duplicate of this bug. ***
To be honest, the current situation is somewhat unsatisfying. _Please_ could some official make an final decision what we'll do here now? This is a summary what happened (from my side of view):
- in the past (prior util-linux-2.12) all of used one crypto api, lets called old (crypto api)
- in order to use it you _had_ to patch util-linux (and also the kernel)
- introduced in kernel-2.5/2.6 we've got a new api in mainstrem sources, lets call it new crypto api
- =util-linux-2.12 just coverd the new one in
- the prior patch was against util-linux was not available for a long time
- to use the new crypto api and util-linux-2.12 you therefore had to use a (unpatched) kernel-2.5/2.6 or an 2.4 including a patch for getting support for the new crypto api (cryptoloop-jari or others) - this patch is not in gentoo-sources (please keep this in mind when making a decission!)
- also, you had to rebuild your filesystem containing the crypto-fs
- Use of the old crypto api and =util-linux-2.12 was just no possible
- we had this state from July till Dezember last year and everybode who was affected solved it is own way (there was just no support from gentoo - some used <util-linux2.12, other patched 2.4, other might have switched to 2.5/2.6 - personaly i switched to the new crypto api, using vanilla 2.4 and cryptoloop-jari, see also Bug 30984)
- sudenly, someone released a patch for the old crypto api which made his way into gentoo, not considering that this may cause again a lot of trouble
- the patch is used when somene uses the very common USE flag crypt (remember: the patch is just needed if one is using the old cryptoapi - in _no_ other case!)
- the patch is stated as compatible to both (the old and new) crypto-api, but this is not true (at least for me), see also http://www.kerneli.org/pipermail/cryptoapi-devel/2003-September/000634.html , where is stated that the patch may cause trouble
- at least for me every update of util-linux ends in trouble so i had to reemerge using "-crypt"
My recomodation is: lets introduce a new flag 'oldcryptoapi' and use it to decide if we need patching or not (most people don't need it, only some uses cryptoapi anyway and just of some them the old one). One can also think about having a flag 'newcryptoapi' to be "compatible" (to what? - it was broken anyway for half a year), but as long the new one would be default for future use use we should use the first one to know if someone wants this patch.
I really recomend to decide how to go on and close this long during bug. I'm in the process to increase the priority back to something higher, but want to get some feedback before.
Thx a lot!
Reporting failure with 2.6.1-mm1 (worked with 2.6.0-mm2) / util-linux-2.12-r4.
Can't create any loop (LOOP_SET_FD)
Seem like kernel problem or api change, as even without crypt it doesn't work.
Astralstorm: Do you have an existing filesystem or want to use/create a new one? If you have a "old" one and want it to use with kernel 2.6 try the link Brad gave above (and in Changelog) and _please_ report back if it works for you.
But to be safe for future use I'd recommend to switch to the new one, that means you don't have to patch your kernel 2.6 and you must'nt patch your util-linux (it ist consodered to work in some circumstances, but you just don't need it and it might cause trouble - like in my case).
So do the follwing steps:
1. boot your old working system (kernel, maybe old util-linux etc.) and make a backup of your cryptofs (Assuming you have a old one)
2. do a 'USE="-crypt" emerge util-linux'
3. Build your new kernel 2.6 - make sure you have cryptoloop-support and your prefered cipher included
4. boot the new kernel
5. create a new cryptofs (drop the old one if applicable)
6. restore the content of your old cryptofs to the new one
This should do the trick.
PS: I'll increase the priority of this one, there has to be a solution in the near future.
Astralstorm, one more question: Have you (re)emerged util-linux after the last working mount of your cryptofs? If so, please report the old and new version also (use 'genlop util-linux' to be sure).
there is a bug in the loop module, as stated in the changelog for
linux-2.6.2rc1 located at:
the message is:
<---- snip ---->
We need to set the hardsect_size of the loop device to that of the real
The loop device advertises a block size of 1024 even when configured over a
When burning a ext2 on a cd, and mounting it directly, I get:
when I losetup /dev/loop0 /dev/cdrom, and then try to mount, I get:
blocksize=1024; and then misaligned transfer; this results in not being able
to read the superblock.
The loop device should be changed to export the same blocksize of the
<---- snip ---->
' think this is why you had to recreate your cryptodevices...
I just wanted to chime in and add what works for me:
- vanilla kernel 2.6.3
- rmd160 | losetup -p0 -e aes-cbc-128 /dev/loop0 /dev/hda1
I've tried emerging util-linux with USE="crypt" and USE="-crypt" and both work. I have not tested compatibility with any of the other cryptoloop systems.
I'm also using lvm2 with multiple logical volumes (including swap) on top of my cryptoloop. Very cool. :-)
This cryptoloop stuff is quite a mess for the 2.4 -> 2.6 transition, but the way of the future seems to be smooth for me.
1) util-linux-2.11z-01-nfsv4.dif is redundant as nfsv4 support is already present in 2.12. Note: no error reported during build unless performing 3) below.
2) rpm build fails with
!!! ERROR: sys-apps/util-linux-2.12-r3 failed.
!!! Function dyn_rpm, Line 873, Exitcode 1
!!! Failed to integrate rpm spec file
3) For crypto, propose to replace
util-linux-2.12.diff ex http://loop-aes.sourceforge.net/loop-AES/loop-AES-v2.0d.tar.bz2
merrits: Full functionality for mount, losetup and a nice manual update.
Please have a look at this patch.
Mike Ossmann wrote:
> I've tried emerging util-linux with USE="crypt" and USE="-crypt" and both work.
Your lucky one :-).
However: this prooves that the patch is not needed (for everone)!
It still causes errors on some boxes...
1) util-linux-2.11z-01-nfsv4.dif is redundant as nfsv4 support is already present in 2.12
where do you see that fact ? the nfs4 patch applies cleanly and looking quickly at mount.c, i see no reference to 'nfs4' if we remove the patch
util-linux-2.12i now has the loop-aes patch
This bug has been open as almost long as I've been a dev. SpanKS for seeing a final resolution.
My final resolution is (for now):
# cat /etc/portage/package.use