After emerge sys-apps/util-linux with USE="loop-aes" got crash on patching files util-linux-ng-2.15-20090511.diff. I think this version is not for sys-apps/util-linux-2.16. Reproducible: Always Steps to Reproduce: 1. emerge sys-apps/util-linux 2. crash on patching file 3. Actual Results: >>> Preparing source in /var/tmp/portage/sys-apps/util-linux-2.16/work/util-linux-ng-2.16 ... * Applying util-linux-ng-2.15-20090511.diff ... * Failed Patch: util-linux-ng-2.15-20090511.diff ! * ( /var/tmp/portage/sys-apps/util-linux-2.16/work/util-linux-ng-2.15-20090511.diff ) * * Include in your bugreport the contents of: * * /var/tmp/portage/sys-apps/util-linux-2.16/temp/util-linux-ng-2.15-20090511.diff-32074.out * * ERROR: sys-apps/util-linux-2.16 failed. * Call stack: * ebuild.sh, line 49: Called src_prepare * environment, line 2172: Called epatch '/var/tmp/portage/sys-apps/util-linux-2.16/work/util-linux-ng-2.15-20090511.diff' * environment, line 1140: Called die * The specific snippet of code: * die "Failed Patch: ${patchname}!"; * The die message: * Failed Patch: util-linux-ng-2.15-20090511.diff! * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/sys-apps/util-linux-2.16/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-apps/util-linux-2.16/temp/environment'. * Expected Results: Patching with no problem :-)
I check: USE="crypt -loop-aes nls slang unicode" emerge util-linux Working and compiling with no problem ;-) So like always problem with patch :-)
Could we _please_ get some basic QA before you pop out new util-linux packages? At this point, I frankly don't even care if you drop loop-aes support, but having to go package.mask every new release for a week or two (and this week's new e2fsprogs and e2fsprogs-libs) because the patch for a very commonly enabled USE flag isn't tested and breaks every time.
The usual problem with loop-aes USE flag... Someone please inform the maintainer of that loop-aes patch about the new util-linux release or else we cannot fix this bug...
This one's especially fun because it results in a missing libuuid and libblkid, breaking most of the rest of your system for reasons that are not immediately obvious.
(In reply to comment #4) > This one's especially fun because it results in a missing libuuid and libblkid, > breaking most of the rest of your system for reasons that are not immediately > obvious. Completely unrelated to this bug.
(In reply to comment #5) > (In reply to comment #4) > > This one's especially fun because it results in a missing libuuid and libblkid, > > breaking most of the rest of your system for reasons that are not immediately > > obvious. > > Completely unrelated to this bug. > How? A user with USE=loop-aes does an emerge -u world, which pulls in the new versions of e2fsprogs-libs, which deletes the libraries it had provided in previous versions, but are now provided by util-linux...which fails to emerge. End result: important libraries do not exist on the system because of this bug. Unless I'm missing something?
(In reply to comment #6) > How? A user with USE=loop-aes does an emerge -u world, which pulls in the new > versions of e2fsprogs-libs, which deletes the libraries it had provided in > previous versions, but are now provided by util-linux...which fails to emerge. > End result: important libraries do not exist on the system because of this bug. > Unless I'm missing something? > You're suffering from changes which were discussed in bug #269378 This has nothing to do with the loop-aes patch so please stop spamming this bug with unrelated problems.
(In reply to comment #3) > The usual problem with loop-aes USE flag... Someone please inform the > maintainer of that loop-aes patch about the new util-linux release or else we > cannot fix this bug... > Exactly the same thing happened when upgrading from 2.14 to 2.15 ... :-[ The 2.16 ebuild pulls in http://loop-aes.sourceforge.net/updates/util-linux-ng-2.15-20090511.diff.bz2. There's also util-linux-ng-2.15-20090526.diff.bz2 and util-linux-ng-2.15.1-20090624.diff.bz2 available at http://loop-aes.sourceforge.net/updates/. Has anybody tried those? I'm afraid I don't know how to reproduce the ebuild manually. BTW: In case that there's nobody by the name of "Someone" reading this thread, I've sent a mail to Jari Ruusu, asking him for a 2.16 patch. krgds /markus
Upstream 2.15.1-20090624 doesn't work, btw. This is now blocking sys-apps/hal-0.5.13-r1, which fixes bug 270956 and bug 278642. If you can't afford the time to test the patches when you make a release or upstream is too slow, perhaps it's time to re-evaluate supporting them. Looking at the rejects and patch, I can see why this is such a major undertaking every time util-linux is updated. There is little attempt in the patch to integrate with existing code, and most of the reject is on automatically-generated files (Makefile.in). For a patch that adds functionality, it replaces a lot of code, some seemingly blindly. Even so, having _really_ looked at the code for the first time I'm turning off USE=loop-aes and uninstalling loop-aes; it and this are too much brain damage.
I've been watching this go on for months; can we just punt the loop-aes from util-linux? IMHO, it's not worth the trouble it's causing...
(In reply to comment #10) > I've been watching this go on for months; can we just punt the loop-aes from > util-linux? IMHO, it's not worth the trouble it's causing... Well, it IS the most straight-forward approach there is at the moment, pity it's getting replaced by dm-crypt. Especially if you have organized your encrypted content (as I have) on a file basis, not as partitions (files are sooo much easier to backup, versionize etc.)
Ditto, too useful to get rid of. Many thanks to Jari for the patches, and spanky for updating the ebuilds. :-)
doing dm-crypt on loop back files is trivial there really isnt any overhead for base-system here as loop-aes failures are ignored. complaining on Gentoo bugzilla will change nothing until upstream loop-aes releases a new patchset. not sure why people waste their time with comments on these bugs. comment #9 is a good example of noise.
(In reply to comment #13) > doing dm-crypt on loop back files is trivial 3 commands instead of 2, so 33.33% overhead ;-) BTW, I got a mail back from Jari. The new patch seems to be ready: http://loop-aes.sourceforge.net/updates/util-linux-ng-2.16-20090725.diff.bz2 http://loop-aes.sourceforge.net/updates/util-linux-ng-2.16-20090725.diff.bz2.sign krgds /markus
the init.d handlers for dm-crypt automate the loop back + mount, so the only thing you need to do is put in your password i'll probably update the patchset todayish
*** Bug 279105 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > the init.d handlers for dm-crypt automate the loop back + mount, so the only > thing you need to do is put in your password On a multiuser 7x24 system and per-user encryption? > > i'll probably update the patchset todayish > Thanks!
I have just stumbled over something I totally fail to understand. If it is OT on this bug, please forgive me, but at the moment I would not know where else to ask (hints of course welcome). Following spanky's hint I have removed loop-aes from USE and rebuilt/upgraded util-linux and the whole plethora on my test system. As a result I could no longer loop-bind and mount my old encrypted files, as expected ("Wrong fs type or superblock" error when mounting). BUT: # dd if=/dev/zero of=new.crypt.file [...] # losetup -e aes /dev/loop/N new.crypt.file [Enter passphrase] # mke2fs /dev/loop/N # mount -oloop /dev/loop/N /mnt/target again gives me what I had before - an encrypted, loop-backed file system ... ! I thought that this was exactly what I needed loop-aes for...? From those results, though, I must deduct that my assumption was wrong. Can anybody help me understand? # equery belongs losetup * Searching for losetup ... sys-apps/util-linux-2.16 (/sbin/losetup) # equery uses util-linux * Searching for util-linux ... [ Legend : U - flag is set in make.conf ] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for sys-apps/util-linux-2.16: U I + + crypt : Add support for encryption -- using mcrypt or gpg where applicable - - loop-aes : include support for Loop AES encryption + + nls : Adds Native Language Support (using gettext - GNU locale utilities) - - old-linux : Add support for linux-2.4 and older - - selinux : !!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur - - slang : Adds support for the slang text display library (it's like ncurses, but different) - - uclibc : Enable uclibc specific patches and build or link uclibc + + unicode : Adds support for Unicode
(In reply to comment #18) > I have just stumbled over something I totally fail to understand. If it is OT > on this bug, please forgive me, but at the moment I would not know where else > to ask (hints of course welcome). > > Following spanky's hint I have removed loop-aes from USE and rebuilt/upgraded > util-linux and the whole plethora on my test system. As a result I could no > longer loop-bind and mount my old encrypted files, as expected ("Wrong fs type > or superblock" error when mounting). > > BUT: > > # dd if=/dev/zero of=new.crypt.file [...] > # losetup -e aes /dev/loop/N new.crypt.file > [Enter passphrase] > # mke2fs /dev/loop/N > # mount -oloop /dev/loop/N /mnt/target > again gives me what I had before - an encrypted, loop-backed file system ... ! > > I thought that this was exactly what I needed loop-aes for...? From those > results, though, I must deduct that my assumption was wrong. Can anybody help > me understand? > > > # equery belongs losetup > * Searching for losetup ... > sys-apps/util-linux-2.16 (/sbin/losetup) > # equery uses util-linux > * Searching for util-linux ... > [ Legend : U - flag is set in make.conf ] > [ : I - package is installed with flag ] > [ Colors : set, unset ] > * Found these USE flags for sys-apps/util-linux-2.16: > U I > + + crypt : Add support for encryption -- using mcrypt or gpg where > applicable > - - loop-aes : include support for Loop AES encryption > + + nls : Adds Native Language Support (using gettext - GNU locale > utilities) > - - old-linux : Add support for linux-2.4 and older > - - selinux : !!internal use only!! Security Enhanced Linux support, this > must be set > by the selinux profile or breakage will occur > - - slang : Adds support for the slang text display library (it's like > ncurses, but > different) > - - uclibc : Enable uclibc specific patches and build or link uclibc > + + unicode : Adds support for Unicode > If you don't need loop-aes then you can disable to use flag. However in your case you actually need loop-aes so you would keep your loop-aes USE flag and simply mask the newest version of util-linux until it has been properly patched.
(In reply to comment #19) > > If you don't need loop-aes then you can disable to use flag. However in your > case you actually need loop-aes so you would keep your loop-aes USE flag and > simply mask the newest version of util-linux until it has been properly > patched. > OK, but why do I need it if I can still create and use aes-encrypted loop-backed files with util-linux without the loop-aes USE flag? It's just a matter of temporarily copying the content from the old device-file to an unencrypted directory, upgrading, creating a new device and then moving the content there. What am I missing?
http://sources.gentoo.org/sys-apps/util-linux/util-linux-2.16.ebuild?r1=1.2&r2=1.3
Yes, vapier, let's call it noise when someone has actually sat down and read the patchset (instead of blindly applying it) and calls your ability to maintain an ebuild into question. Call me stupid (which you will), but isn't making sure all your USE flags work properly before release basic QA? Any new dev would be ground up for making such a mistake, likely by you - what excuses you from that?
Another suggestion: how about for future updates mask new versions of util-linux (or just the loop-aes USE flag) until a proper loop-aes patch is released?
there is no way i'm going to make loop-aes a required part of util-linux feel free to keep pointlessly bitching as that is likely to make me simply drop this crap
Leave vapier alone so that we who use this may continue to do so. We've e-mailed Jari in the past, he's willing to patch for us when he can, and we'll continue to do so as util-linux progresses in the future. Until he or vapier say "No!", this is an arrangement we're willing engage in (where "we" is defined as myself and the last 3-4 folks who've filed new issues for new versions, and requested new patches). I know there are others out there who do not comment on the new-patch-bugzilla when it is filed, and simply wait for everything to settle, but use the feature anyway. I was one of them, as a matter of fact, for multiple versions before the last two or three. Only recently have I decided to ask Jari early so that all of us can benefit. Were I a better human being, I'd learn it and offer him a patch to save him work! Do NOT ruin it for all of us.
The problem is not loop-aes, rather it is that util-linux is a critical core package (containing useful bits like 'fsck', 'mount', and 'dmesg') maintained by an arguably experienced developer who, for the last several releases, publishes a known-broken build and leaves it that way until a user contacts upstream and asks them for an updated patch.
No, this is a USE flag issue. If the issue is not loop-aes, then there is no issue at all. Users who don't use it won't enable it. It doesn't get simpler.
This bug shows up again in version 2.16.1. The patch of util-linux-ng-2.16-20090725.diff failed. If loop-aes USE flag is turned off, this error won't show up.
