On the automatic update to sys-apps/util-linux-2.19.1 (supposed to be stable) this package silently ignores the loop-aes USE flag and breaks your system as no loop-aes encrypted mounts will work any more. Which is very bad as you will only notice this problem later at a reboot or remount when you don't remember the util-linux upgrade any more. Depending on what you have encrypted this renders the system unfunctional and the rather unclear error message "ioctl: invalid parameter" on the mount command is hard to trace back to it's source. it took me two hours to chase down the source of ths error as the ubgrade of util-linux was way back and the error only showed up later on reboot! Sorry for the rant, but this must not happen! If you drop a system-critical USa flag, don't ever do it silently. MARK loop-aes as incompatible by blocking the package or at least throw a big fat warning! Reproducible: Always Steps to Reproduce: 1. Have a system with partitions encrypted by loop-aes 2. Do periodic emerge --sync && emerge -avuDN world 3. Voila suddenly days after such an upgrade your partitions don't mount any more. Actual Results: Errorr: ioctl: invalid parameter on every mount of any encrypted valume (using loop-aes) Expected Results: On the emerge -avuDN world the loop-aes package should show up as blocked if you have the use-flag loop-aes set. Or at the very least a big fat warning should show. Also the error message could be a bit more explicit, how about "invalid parameter: -K requires loop-aes patch, this util-linux is unpatched" Silently dropping the loop-aes support and simply ignoring the USE flag without any warning is almost setting a trap for all loop-aes user and is nasty to trace back. Current work-around: echo ">sys-apps/util-linux-2.19" >> /etc/portage/package.mask emerge -avuDn world This is really an annoying bug!
loop-aes is gone in util-linux on permanent basis (for the foreseen future) *** This bug has been marked as a duplicate of bug 354451 ***
Please re-read the BUG report again - if you have done so you did not understand it. This BUG report is not about the missing support of loop-aes in util-linux. If the maintainer choose to remove that support, ok. Too bad. It is about the IMPROPER and annoying way to do this silently and in an intransparent fashion. It is obvious that this dependancy is critical to running systems. It has really cost me 2h of my time to trace down the source of the suddenly failing mounts, because 1) The upgrade to util-linux-2.19.1 took place some time back and as the volumes were mounted already no error came. 2) Only now after a reboot the whole system failed, and that even with a relatively unclear error. Thats also why I was quite annoyed and hard-masked util-linux on my system now for the forseeable future. But the correct action would be to fix this situation properly by blocking the conflicting packages. Or why do you want to let other people waste their time by running into this trap as well??? Therefore please reopen and fix it in a way that creates an error or warning on the upgrade of util-linux!
Just a minor note: awhile ago somebody decided to restrict access to bug 354451, so marking this one as a duplicate of it may be seen as aggravating. Having said that (and partially agreeing on the no warning part), I don't see how such bug can get a positive effect, unless you'd count loop-aes getting p.masked as one.
> Having said that (and partially agreeing on the no warning part), I don't see > how such bug can get a positive effect, unless you'd count loop-aes getting > p.masked as one. That is indeed the point: It would have saved me some time chasing this bug if the util-linux-2.19.1 package had masked loop-aes. I would have seen the problem on the upgrade run and have known whats up. It would still help people who haven't run into that "incompatibility trap" yet. Now I had to first find out after the reboot that went wrong (days after the util-linux upgrade) what was causing this "ioctl: Invalid argument" error and then I had to p.mask the new util-linux version to force a downgrade. And I believe a package can list another package (such as loop-aes) as "I can't be installed together with this", or not? Also any warning would have helped a lot. I mean, c'mon, you didn't have to be a genius to figure out that some systems would break down after a reboot if you silently discard that support plus USE flag...
If I'm understanding correctly, without any knowledge of loop-aes itself, the package sys-fs/loop-aes needs to be installed in any case? If so, then a blocker like !sys-apps/util-linux[-loop-aes] could be committed to sys-fs/loop-aes. Or something like: if has_version "sys-apps/util-linux[-loop-aes]"; then die "util-linux is missing loop-aes support, terminating" fi Moving to loop-aes maintainers to handle this in sys-fs/loop-aes ebuild.
Or this bug could serve as removal request of sys-fs/loop-aes altogether if it's not useful anymore without util-linux having loop-aes support.
(In reply to comment #6) > Or this bug could serve as removal request of sys-fs/loop-aes altogether if > it's not useful anymore without util-linux having loop-aes support. Removal seems to be in order: http://bugs.gentoo.org/show_bug.cgi?id=354451#c21
(In reply to comment #7) > (In reply to comment #6) > > Or this bug could serve as removal request of sys-fs/loop-aes altogether if > > it's not useful anymore without util-linux having loop-aes support. > > Removal seems to be in order: http://bugs.gentoo.org/show_bug.cgi?id=354451#c21 I don't know that that was the point of c21. As per your request, I will dig into this some. Please don't go forward with any removals in the mean time. Thanks!
To clarify this: 1. All (well, since I use it) previous versions of sys-apps/util-linux honoured the "loop-aes" USE flag and installed a version that works perfect with loop-aes. 2. Now, util-linux-2.19.1, suddenly started to silently ignore this use flag and the installed loop-aes package and installs a version that does not work with loop-aes. 3. The system will continue to work for a while, as the loop-aes devices are already mounted likely. As soon as a remount/reboot occurs the mount suddenly fails, which can be quite critical depending on what is on these devices. Suggested possible fixes: 1) Throw a big fat warning whenever util-linux-2.19.1 gets installed into a system with loop-aes installed. Something like "warning, this version has no loop-aes support, your volumes will not mount with this version!" or perhaps better 2) Install a blocker line like !sys-fs/loop-aes to the new (from 2.19.1 I belive) versions of util-linux. The wanted result (im an no gentoo packaging guru, pls correct if I see it wrong) should be that any attempt to upgrade/install util-linux of version 2.19.1 should fail with a message that loop-aes is blocking it, provided that is already installed. The admin can then decide if he wants to remove loop-aes or stay with the older version of util-linux. (Or install a patched util-linux from an overlay or manually) Is that so far clear?
I'd say quite clear and the result has a pretty good chance to be like I wrote in comment 3: http://dev.c1pher.net/index.php/2011/06/loop-aes-should-it-be-treecleaned/ I still wonder why exactly is bug 354451 restricted.
commented on the blog. I wouldn't see why one would want to drop loop-aes from the tree. The package is absolutely stable - the problems described in this bug were entirely created by the way how util-linux handled the obvious dependencies on a loop-aes enabled system. I hope to get this fixed, simply, so that no incompatible version of util-linux installs "silently" on my system while I don't want this. Obvious, or?
Hmm, let me think: - it patches away generic parts of the kernel to work - it needs a patch in util-linux to be accessed ... Well, take a look here, too: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614808
Ok. This is fixed in CVS for versions 3.6b[-r1] and 3.6c. Notes for people this affects, if you are still using util-linux-2.19* it is *going* to force a downgrade and will block the newer versions. It's not the prettiest solution, but it should world. If you loop-aes is broken, just emerge -u world and things should fix themselves. I also became aware that the patches for 2.19* are apparently out, so I will see if I can prod vapier to get those into the tree. I am sorry for the headache this has cause so far. Hopefully we can prevent this in the future. 13 Jun 2011; Dane Smith <c1pher@gentoo.org> -loop-aes-3.5b.ebuild, -loop-aes-3.6a.ebuild, loop-aes-3.6b.ebuild, loop-aes-3.6b-r1.ebuild, +loop-aes-3.6c.ebuild, -files/loop-AES-v3.5b-20101231.diff: *Change DEPEND in 3.6b[-r1] to require +loop-aes in util-linux. Fixes bug 370635. *Add new version 3.6c. *Remove old versions / patches. *Add myself to metadata that way I actually get CC'd on bugs. Closing.
Thanks a lot, confirming that the problem is fixed: Calculating dependencies... done! [ebuild U ~] sys-fs/loop-aes-3.6c [3.6b-r1] USE="extra-ciphers padlock -aes-ni -keyscrub" 246 kB Total: 1 packages (1 upgrades), Size of downloads: 3,524 kB !!! One or more updates have been skipped due to a dependency conflict: sys-apps/util-linux:0 (sys-apps/util-linux-2.19.1::gentoo, ebuild scheduled for merge) conflicts with >=sys-apps/util-linux-2.12r[crypt,loop-aes] required by (sys-fs/loop-aes-3.6c::gentoo, ebuild scheduled for merge) ...so it will block util-linux upgrade until this encorporates the loop-aes patch for now. Good, that should prevent the reported problems.
