Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 450688 - sys-kernel/genkernel-3.4.40-r1 do not copy binary file but dependency libs after upgrade app-misc/pax-utils-0.6
Summary: sys-kernel/genkernel-3.4.40-r1 do not copy binary file but dependency libs af...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: genkernel (show other bugs)
Hardware: AMD64 Linux
: Normal critical with 6 votes (vote)
Assignee: Gentoo Genkernel Maintainers
URL:
Whiteboard:
Keywords:
: 453522 464334 465760 (view as bug list)
Depends on: 464380
Blocks:
  Show dependency tree
 
Reported: 2013-01-07 08:13 UTC by Yi-Chieh Wang
Modified: 2013-06-07 19:34 UTC (History)
27 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch to make use of "-l" if lddtree is new enough (0001-Make-copy_binaries-compatible-with-lddtree-from-pax-.patch,1.41 KB, patch)
2013-02-07 12:50 UTC, Xake
Details | Diff
emerge --info output from my failing system (emerge_--info.txt,14.74 KB, text/plain)
2013-06-07 11:29 UTC, Thomas Deutschmann (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yi-Chieh Wang 2013-01-07 08:13:38 UTC
After upgrading app-misc/pax-utils from 0.5 to 0.6 (both unstable), the lddtree changes it output format. Before 0.5, "lddtree /sbin/zpool" shows "zpool => /sbin/zpool (interpreter => /lib64/ld-linux-x86-64.so.2) ...". But in 0.6, it shows "/sbin/zpool (interpreter => /lib64/ld-linux-x86-64.so.2) ...". This behavior breaks the function "copy_binaries" in gen_initramfs.sh, which extracts the binaries with awk. This BUG happens when copy_binaries is called only (enable ZFS, multipath, luks ... etc).

Reproducible: Always

Steps to Reproduce:
1. emerge -1 \=app-misc/pax-utils-0.6
2. genkernel --loglevel=5 --zfs initramfs
Actual Results:  
The log shows no /sbin/zfs, /sbin/zpool installed in the initramfs

Expected Results:  
/sbin/zfs, /sbin/zpool should be installed in the initramfs
Comment 1 Lukas Elsner 2013-01-09 22:57:28 UTC
Maybe this is related?

http://forums.gentoo.org/viewtopic-p-7219378.html
Comment 2 Yi-Chieh Wang 2013-01-12 14:19:38 UTC
(In reply to comment #1)
> Maybe this is related?
> 
> http://forums.gentoo.org/viewtopic-p-7219378.html

Yes, exactly caused by >=app-misc/pax-utils-0.6

I think genkernel should be patched If pax-utils won't change lddtree back?

I've patched gen_initramfs.sh temporary for using.
Comment 3 MrPenguin07 2013-01-13 09:32:14 UTC
This one snagged me as well.
Comment 4 RB 2013-01-19 17:05:29 UTC
This is breaking all genkernel options that use copy_binaries:
 - e2fsprogs
 - blkid
 - multipath
 - zfs
 - luks/cryptsetup

I would increase the importance to "blocker" if I could, it produces unbootable intrds for any systems relying on the above.
Comment 5 Lukas Elsner 2013-01-19 17:23:31 UTC
+1

broke my system completely. bugs like this should be solven within hours, instead of days/weeks ;)
Comment 6 Mike Auty (RETIRED) gentoo-dev 2013-01-19 22:14:36 UTC
It's difficult to raise this to blocker since it only affects certain setups, but since it can completely bork other setups I've upgraded it to critical.

@genkernel, at the very least this should get a dep requiring <=pax-utils-0.5 until this can be successfully resolved...
Comment 7 RB 2013-01-19 22:27:26 UTC
I can understand and appreciate that.  Of course, my current workaround (echo ">app-misc/pax-utils-0.5" >> /etc/portage/package.use) helps, altering the genkernel deps would be more granular.
Comment 8 Ghent 2013-01-21 16:37:42 UTC
It took many hours of searching and some direction from some kind folks in freenode's #funtoo to find this, so I'd like to make the additional notation that this is also affecting anything using mdadm.

The /sbin/{mdadm,mdmon} binaries do not get copied into the initrd, and on a reboot you're stuck with no working mdadm raids.

Not fun.  This is definitely something that should be marked as a blocker, as it probably affects a large portion of people who use any of the options/configurations mentioned above.
Comment 9 Mike Auty (RETIRED) gentoo-dev 2013-01-22 00:53:47 UTC
Ok, I've added the <pax-utils-0.6 dependency to the latest stable version (which is also the latest version) as a temporary measure.  I don't know whether it'll impact existing installations, but I couldn't easily add a bump as stable.  Hopefully therefore, for the time being, this shouldn't be a major issue, but this is a temporary fix that still needs resolving.

I'm CCing the pax-utils maintainers as well, in case they can help or shed any light on the syntax change...
Comment 10 Marios Andreopoulos 2013-01-22 01:21:03 UTC
I have a hardened installation and a non-hardened one, both ~amd64.

On the hardened, pax-utils-0.6 do not cause any problems.

On the non-hardened I have the same problem as the others, rendering any new kernel/initramfs unbootable.
Comment 11 SpanKY gentoo-dev 2013-01-22 02:10:26 UTC
(In reply to comment #9)

use the -l (--list) option to lddtree rather than parsing the raw output

alternatively, depend on pax-utils[python] and use `lddtree --copy-to-tree` so there's nothing for genkernel to implement

either way, i don't see a bug in pax-utils here
Comment 12 Jeroen Roovers (RETIRED) gentoo-dev 2013-01-22 16:17:52 UTC
*** Bug 453522 has been marked as a duplicate of this bug. ***
Comment 13 Xake 2013-02-07 12:16:28 UTC
(In reply to comment #11)
> (In reply to comment #9)
> 
> use the -l (--list) option to lddtree rather than parsing the raw output
> 
> alternatively, depend on pax-utils[python] and use `lddtree --copy-to-tree`
> so there's nothing for genkernel to implement
> 
> either way, i don't see a bug in pax-utils here

Well, we need to keep our own old implementation anyways so we can work with <pax-utils-0.6 (i.e. any stable version of pax-utils).
And we do not copy the files as is, but pass them through cpio.
However I will look into "lddtree -l" if that output format will be stable.
Comment 14 Xake 2013-02-07 12:50:39 UTC
Created attachment 338222 [details, diff]
Patch to make use of "-l" if lddtree is new enough

Please apply this patch and test both with pax-utils-0.5 and pax-utils-0.6. I have tested it on my system, but I never had problems with pax-utils-0.6 to begin with, probably as my systems are hardened.
Comment 15 Xake 2013-02-07 13:00:28 UTC
(In reply to comment #14)
> Created attachment 338222 [details, diff] [details, diff]
> Patch to make use of "-l" if lddtree is new enough
> 
> Please apply this patch and test both with pax-utils-0.5 and pax-utils-0.6.
> I have tested it on my system, but I never had problems with pax-utils-0.6
> to begin with, probably as my systems are hardened.

@maintainers,

I will apply this patch upstream in a day or two unless objections were heard. Could someone please roll a new release then and add to portage? No need to stabilize just yet, but could be nice to have for genkernel-testing but also to not limit pax-utils users in ~arch.
Comment 16 SpanKY gentoo-dev 2013-02-19 08:01:13 UTC
(In reply to comment #14)

the -l option should stand by itself.  you can also unify things better:

(
if lddtree -V > /dev/null 2>&1 ; then
	lddtree -l "$@"
else
	lddtree "$@" \
		| tr ')(' '\n' \
		| awk  '/=>/{ if($3 ~ /^\//){print $3}}'
) \
	| sort \
	| uniq \
	| cpio -p --make-directories --dereference --quiet "${destdir}" \
	|| gen_die "Binary ${f} or some of its library dependencies could not be copied"
Comment 17 Xake 2013-02-20 07:06:48 UTC
(In reply to comment #16)
> (In reply to comment #14)

wrt -l, yeah I know. found it while submitting, but it seems like i forgot to change patch.

Thanks for your suggestion, I totally forgot that was possible...
If I cannot break it, is it ok if I commit it (that specific function in genkernel is published as CC0, unlike the rest of genkernel)?
Comment 18 tman 2013-02-27 14:05:18 UTC
after nearby one month, there is a fix now in portage for it in sight?
Comment 19 Xake 2013-02-27 17:20:18 UTC
(In reply to comment #18)
> after nearby one month, there is a fix now in portage for it in sight?

The fix is there. It is to either let portage downgrade pax-utils or use the -9999 as it has the patch minus vapiers suggestions.
Comment 20 Kolbjørn Barmen 2013-03-03 13:47:25 UTC
Not to sound impatient or anything, but will this be fixed in portage anytime soon? I mean, it's been dragging on for a couple of months now *mind boggles*
Comment 21 Richard Yao (RETIRED) gentoo-dev 2013-04-01 19:36:36 UTC
(In reply to comment #20)
> Not to sound impatient or anything, but will this be fixed in portage
> anytime soon? I mean, it's been dragging on for a couple of months now *mind
> boggles*

The genkernel developers have been extremely busy, but it seems that I have found some time to hack on genkernel. My plan is to tag a new release in a few days.
Comment 22 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-04-03 15:13:08 UTC
*** Bug 464334 has been marked as a duplicate of this bug. ***
Comment 23 tman 2013-04-04 05:45:44 UTC
how far are we?

 * IMPORTANT: 1 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.

[nomerge      ] sys-kernel/genkernel-3.4.45 
[ebuild     UD]  app-misc/pax-utils-0.5 [0.6]
[ebuild     U ] app-i18n/ibus-1.5.1-r2 [1.5.1-r1]
[ebuild     U ] app-misc/mc-4.8.8 [4.8.7-r1]
[nomerge      ] x11-misc/bumblebee-3.1 
[nomerge      ]  x11-base/xorg-drivers-1.14 
[ebuild     U ]   x11-drivers/nvidia-drivers-313.30 [313.26]

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

app-misc/pax-utils:0

  (app-misc/pax-utils-0.6::gentoo, installed) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (app-misc/pax-utils-0.5::gentoo, ebuild scheduled for merge) pulled in by
    <app-misc/pax-utils-0.6 required by (sys-kernel/genkernel-3.4.45::gentoo, installed)


system updated
TuX cornix # geany &
[1] 19221
TuX cornix # ulite 

 * IMPORTANT: 1 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.

[ebuild     U ] app-i18n/ibus-1.5.1-r2 [1.5.1-r1]
[ebuild     U ] app-misc/mc-4.8.8 [4.8.7-r1]
[nomerge      ] x11-misc/bumblebee-3.1 
[nomerge      ]  x11-base/xorg-drivers-1.14 
[ebuild     U ]   x11-drivers/nvidia-drivers-313.30 [313.26]
[nomerge      ] sys-kernel/genkernel-3.4.45 
[ebuild     UD]  app-misc/pax-utils-0.5 [0.6]
[blocks B     ] =app-misc/pax-utils-0.5 ("=app-misc/pax-utils-0.5" is blocking sys-kernel/genkernel-3.4.45)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (sys-kernel/genkernel-3.4.45::gentoo, installed) pulled in by
    sys-kernel/genkernel required by @selected

  (app-misc/pax-utils-0.5::gentoo, ebuild scheduled for merge) pulled in by
    >=app-misc/pax-utils-0.1.17 required by (sys-apps/portage-2.1.11.60::gentoo, installed)
    >=app-misc/pax-utils-0.1.19 required by (sys-apps/sandbox-2.6-r1::gentoo, installed)
    >=app-misc/pax-utils-0.1.10 required by (sys-libs/glibc-2.17::gentoo, installed)
    >=app-misc/pax-utils-0.2.1 required by (sys-kernel/genkernel-3.4.45::gentoo, installed)
    <app-misc/pax-utils-0.6 required by (sys-kernel/genkernel-3.4.45::gentoo, installed)

system updated
Comment 24 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-04-13 09:12:09 UTC
*** Bug 465760 has been marked as a duplicate of this bug. ***
Comment 25 Attila Jecs 2013-04-13 10:31:18 UTC
dreamer ~ # emerge -av genkernel

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     UD ] app-misc/pax-utils-0.5 [0.7] USE="caps (-python%)" 0 kB
[ebuild  N     ] sys-kernel/genkernel-3.4.45  USE="cryptsetup -crypt (-ibm) (-selinux)" 0 kB
[blocks B      ] =app-misc/pax-utils-0.5 ("=app-misc/pax-utils-0.5" is blocking sys-kernel/genkernel-3.4.45)

Total: 2 packages (1 downgrade, 1 new), Size of downloads: 0 kB
Conflict: 1 block (1 unsatisfied)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (sys-kernel/genkernel-3.4.45::gentoo, ebuild scheduled for merge) pulled in by
    genkernel

  (app-misc/pax-utils-0.5::gentoo, ebuild scheduled for merge) pulled in by
    >=app-misc/pax-utils-0.1.19 required by (sys-apps/sandbox-2.6-r1::gentoo, installed)
    >=app-misc/pax-utils-0.1.17 required by (sys-apps/portage-2.1.11.62::gentoo, installed)
    >=app-misc/pax-utils-0.1.10 required by (sys-libs/glibc-2.17::gentoo, installed)
    <app-misc/pax-utils-0.6 required by (sys-kernel/genkernel-3.4.45::gentoo, ebuild scheduled for merge)
    >=app-misc/pax-utils-0.2.1 required by (sys-kernel/genkernel-3.4.45::gentoo, ebuild scheduled for merge)


For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked

dreamer ~ # man emerge
dreamer ~ # emerge -av genkernel --nodeps

These are the packages that would be merged, in order:

[ebuild  N     ] sys-kernel/genkernel-3.4.45  USE="cryptsetup -crypt (-ibm) (-selinux)" 0 kB

Total: 1 package (1 new), Size of downloads: 0 kB

Would you like to merge these packages? [Yes/No] 

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) sys-kernel/genkernel-3.4.45
 * genkernel-3.4.45.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                      [ ok ]
 * dmraid-1.0.0.rc16-3.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                   [ ok ]
 * mdadm-3.1.5.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                           [ ok ]
 * LVM2.2.02.88.tgz SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                              [ ok ]
 * busybox-1.20.2.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                        [ ok ]
 * open-iscsi-2.0-872.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                     [ ok ]
 * fuse-2.8.6.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                             [ ok ]
 * unionfs-fuse-0.24.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                     [ ok ]
 * gnupg-1.4.11.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                          [ ok ]
>>> Unpacking source...
>>> Unpacking genkernel-3.4.45.tar.bz2 to /var/tmp/portage/sys-kernel/genkernel-3.4.45/work
>>> Source unpacked in /var/tmp/portage/sys-kernel/genkernel-3.4.45/work
>>> Preparing source in /var/tmp/portage/sys-kernel/genkernel-3.4.45/work/genkernel-3.4.45 ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/sys-kernel/genkernel-3.4.45/work/genkernel-3.4.45 ...
>>> Source configured.
>>> Compiling source in /var/tmp/portage/sys-kernel/genkernel-3.4.45/work/genkernel-3.4.45 ...
>>> Source compiled.
>>> Test phase [not enabled]: sys-kernel/genkernel-3.4.45

>>> Install genkernel-3.4.45 into /var/tmp/portage/sys-kernel/genkernel-3.4.45/image/ category sys-kernel
 * Copying files to /var/cache/genkernel/src...
>>> Completed installing genkernel-3.4.45 into /var/tmp/portage/sys-kernel/genkernel-3.4.45/image/

ecompressdir: bzip2 -9 /usr/share/man

>>> Installing (1 of 1) sys-kernel/genkernel-3.4.45
 * checking 214 files for package collisions
>>> Merging sys-kernel/genkernel-3.4.45 to /
--- /var/

...
Comment 26 Xake 2013-04-13 21:55:49 UTC
(In reply to comment #25)

This is a runtime problem, and has nothing to do with if the merge of genkernel is possible with newer versions of pax-utils or not (in fact the install of genkernel is more or less some seds, and some copying so all its deps are runtime deps, really).

And the fix for this is in genkernel git. We only need to roll a release.

So stop add noise to this bugreport, the only thing left here in this bugreport is for you to either try genkernel-9999 and report back if it failed too with this problem, or wait for a release to hit portage (at which time this bug will be closed).
Comment 27 tman 2013-04-13 23:29:36 UTC
(In reply to comment #26)
> (In reply to comment #25)
> 
> This is a runtime problem, and has nothing to do with if the merge of
> genkernel is possible with newer versions of pax-utils or not (in fact the
> install of genkernel is more or less some seds, and some copying so all its
> deps are runtime deps, really).
> 
> And the fix for this is in genkernel git. We only need to roll a release.
> 
> So stop add noise to this bugreport, the only thing left here in this
> bugreport is for you to either try genkernel-9999 and report back if it
> failed too with this problem, or wait for a release to hit portage (at which
> time this bug will be closed).

i am using:
sys-kernel/genkernel-9999
app-misc/pax-utils-0.7


and i can conform that the problem still exist:

 Gentoo Linux Genkernel; Version 3.4.45
* Running with options: --oldconfig --menuconfig all

* Using genkernel.conf from /etc/genkernel.conf
* Sourcing arch-specific config.sh from /usr/share/genkernel/arch/x86_64/config.sh ..
* Sourcing arch-specific modules_load from /usr/share/genkernel/arch/x86_64/modules_load ..

* Linux Kernel 3.8.7-gentoo for x86_64...
* .. with config file /etc/kernels/kernel-config-x86_64-3.8.7-gentoo
* kernel: --mrproper is disabled; not running 'make mrproper'.
*         >> Running oldconfig...
* kernel: --clean is disabled; not running 'make clean'.
* kernel: >> Invoking menuconfig...


*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.

*         >> Compiling 3.8.7-gentoo bzImage...
^[[A^[[A*         >> Not installing firmware as it's included in the kernel already (CONFIG_FIRMWARE_IN_KERNEL=y)...
*         >> Compiling 3.8.7-gentoo modules...
*         >> Generating module dependency data...
* Copying config for successful build to /etc/kernels/kernel-config-x86_64-3.8.7-gentoo
* busybox: >> Using cache
* initramfs: >> Initializing...
*         >> Appending base_layout cpio data...
*         >> Appending auxilary cpio data...
*         >> Copying keymaps
*         >> Appending busybox cpio data...
*         >> Appending modules cpio data...
*         >> Appending blkid cpio data...
Traceback (most recent call last):
  File "/usr/bin/lddtree", line 647, in <module>
    sys.exit(main(sys.argv[1:]))
  File "/usr/bin/lddtree", line 616, in main
    elf = ParseELF(p, options.root, ldpaths)
  File "/usr/bin/lddtree", line 328, in ParseELF
    for t in segment.iter_tags():
  File "/usr/lib64/python3.2/site-packages/elftools/elf/dynamic.py", line 63, in iter_tags
    tag = self.get_tag(n)
  File "/usr/lib64/python3.2/site-packages/elftools/elf/dynamic.py", line 77, in get_tag
    return DynamicTag(entry, self._elffile)
  File "/usr/lib64/python3.2/site-packages/elftools/elf/dynamic.py", line 32, in __init__
    setattr(self, entry.d_tag[3:].lower(), dynstr.get_string(self.entry.d_val))
AttributeError: 'NoneType' object has no attribute 'get_string'
*         >> Appending modprobed cpio data...
*         >> Compressing cpio data (.xz)...
* 
* Kernel compiled successfully!
* 
* Required Kernel Parameters:
*     root=/dev/$ROOT
* 
*     Where $ROOT is the device node for your root partition as the
*     one specified in /etc/fstab
* 
* If you require Genkernel's hardware detection features; you MUST
* tell your bootloader to use the provided INITRAMFS file.

* WARNING... WARNING... WARNING...
* Additional kernel cmdline arguments that *may* be required to boot properly...

* Do NOT report kernel bugs as genkernel bugs unless your bug
* is about the default genkernel configuration...
* 
* Make sure you have the latest ~arch genkernel before reporting bugs.
Comment 28 Attila Jecs 2013-04-14 13:17:54 UTC
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U  ] dev-php/xdebug-client-2.2.2 [2.2.1] USE="-libedit" 245 kB
[ebuild     U  ] dev-libs/vala-common-0.20.1 [0.20.0] 2,567 kB
[ebuild     U  ] media-libs/libpng-1.6.1-r1:0/16 [1.6.1:0/16] USE="apng (-neon) -static-libs" 0 kB
[ebuild     UD#] app-misc/pax-utils-0.5 [0.7] USE="caps (-python%)" 0 kB
[ebuild     U  ] dev-php/xdebug-2.2.2 [2.2.1] PHP_TARGETS="php5-4 -php5-3 -php5-5%" 0 kB
[ebuild     U  ] app-text/poppler-0.22.3:0/36 [0.22.2-r2:0/35] USE="curl cxx jpeg lcms png qt4 tiff utils -cairo -cjk -debug -doc -introspection -jpeg2k" 2,169 kB
[ebuild     U  ] media-gfx/nomacs-1.0.0 [0.4.0] USE="-raw" 0 kB

Total: 7 packages (6 upgrades, 1 downgrade), Size of downloads: 4,980 kB

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

app-text/poppler:0

  (app-text/poppler-0.22.3::gentoo, ebuild scheduled for merge) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (app-text/poppler-0.22.2-r2::gentoo, installed) pulled in by
    app-text/poppler:0/35=[cxx,jpeg,lcms,tiff,xpdf-headers(+)] required by (net-print/cups-filters-1.0.30::gentoo, installed)

app-misc/pax-utils:0

  (app-misc/pax-utils-0.7::gentoo, installed) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (app-misc/pax-utils-0.5::gentoo, ebuild scheduled for merge) pulled in by
    <app-misc/pax-utils-0.6 required by (sys-kernel/genkernel-3.4.45::gentoo, installed)


It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously.  If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously. You may want to try a larger value of
the --backtrack option, such as --backtrack=30, in order to see if
that will solve this conflict automatically.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.


The following mask changes are necessary to proceed:
 (see "package.unmask" in the portage(5) man page for more details)
# required by sys-kernel/genkernel-3.4.45
# required by @selected
# required by @world (argument)
# /etc/portage/package.mask/pax-utils:
=app-misc/pax-utils-0.5

NOTE: The --autounmask-keep-masks option will prevent emerge
      from creating package.unmask or ** keyword changes.
Comment 29 Attila Jecs 2013-04-14 13:18:45 UTC
* Gentoo Linux Genkernel; Version 3.4.45
* Running with options: --lvm --mdadm --luks initramfs

* Using genkernel.conf from /etc/genkernel.conf
* Sourcing arch-specific config.sh from /usr/share/genkernel/arch/x86_64/config.sh ..
* Sourcing arch-specific modules_load from /usr/share/genkernel/arch/x86_64/modules_load ..

* Linux Kernel 3.8.7-gentoo for x86_64...
* .. with config file /etc/kernels/kernel-config-x86_64-3.8.7-gentoo
* busybox: >> Using cache
* initramfs: >> Initializing...
*         >> Appending base_layout cpio data...
*         >> Appending auxilary cpio data...
*         >> Copying keymaps
*         >> Appending busybox cpio data...
*         >> Appending lvm cpio data...
*           LVM: Adding support (compiling binaries)...
* lvm: >> Using cache
*         >> Appending mdadm cpio data...
*               MDADM: Skipping inclusion of mdadm.conf
*               MDADM: Adding support (compiling binaries)...
*               MDADM: Using cache
*         >> Appending luks cpio data...
* Including LUKS support
*         >> Appending modules cpio data...
*         >> Appending blkid cpio data...
*         >> Appending modprobed cpio data...
*         >> Compressing cpio data (.xz)...

* WARNING... WARNING... WARNING...
* Additional kernel cmdline arguments that *may* be required to boot properly...
* add "dolvm" for lvm support
* add "domdadm" for RAID support
* With support for several ext* filesystems available, it may be needed to
* add "rootfstype=ext3" or "rootfstype=ext4" to the list of boot parameters.

* Do NOT report kernel bugs as genkernel bugs unless your bug
* is about the default genkernel configuration...
* 
* Make sure you have the latest ~arch genkernel before reporting bugs.
Comment 30 Attila Jecs 2013-04-14 13:19:16 UTC
pax-utils-0.7
works for me?
how can i tast further?
Comment 31 Attila Jecs 2013-04-14 13:21:03 UTC
to remove dep on 0.5
so i can upgrade other things
i installed genkernel with --nodeps
but thats break emerge -DuN @world
Comment 32 SpanKY gentoo-dev 2013-04-14 22:22:05 UTC
afaik, there's nothing for me (pax-utils) to do here, so un-cc myself
Comment 33 Juergen Rose 2013-04-19 04:18:59 UTC
Is there any chance that we get a new version of genkernel which will work with current pax-utils?
I still get:

root@impala:/root(2)# emerge -pvuND world
...
app-misc/pax-utils:0

  (app-misc/pax-utils-0.7::gentoo, ebuild scheduled for merge) conflicts with
    <app-misc/pax-utils-0.6 required by (sys-kernel/genkernel-3.4.45::gentoo, installed)
Comment 34 Jason Mours 2013-04-20 03:37:46 UTC
(In reply to comment #33)
> Is there any chance that we get a new version of genkernel which will work
> with current pax-utils?
> I still get:
> 
> root@impala:/root(2)# emerge -pvuND world
> ...
> app-misc/pax-utils:0
> 
>   (app-misc/pax-utils-0.7::gentoo, ebuild scheduled for merge) conflicts with
>     <app-misc/pax-utils-0.6 required by
> (sys-kernel/genkernel-3.4.45::gentoo, installed)

I masked 3.4.45 and can confirm that sys-kernel/genkernel-3.4.44.2 emerges with pax-utils-0.7. I haven't had any problems.
Comment 35 Xake 2013-04-21 07:11:30 UTC
(In reply to comment #34)
> I masked 3.4.45 and can confirm that sys-kernel/genkernel-3.4.44.2 emerges
> with pax-utils-0.7. I haven't had any problems.

And there we go again.

Genkernel never had any problem to merge with newer pax-utils, it is a *RUNTIME PROBLEM* resulting in genkernel generating a broken initramfs for some people!

This is not something that will be fixed by masking and unmasking, only by either using -9999 (where it is fixed) or waiting for a new release.

(In reply to comment #27)
> *         >> Appending blkid cpio data...
> Traceback (most recent call last):
>   File "/usr/bin/lddtree", line 647, in <module>
>     sys.exit(main(sys.argv[1:]))
>   File "/usr/bin/lddtree", line 616, in main
>     elf = ParseELF(p, options.root, ldpaths)
>   File "/usr/bin/lddtree", line 328, in ParseELF
>     for t in segment.iter_tags():
>   File "/usr/lib64/python3.2/site-packages/elftools/elf/dynamic.py", line
> 63, in iter_tags
>     tag = self.get_tag(n)
>   File "/usr/lib64/python3.2/site-packages/elftools/elf/dynamic.py", line
> 77, in get_tag
>     return DynamicTag(entry, self._elffile)
>   File "/usr/lib64/python3.2/site-packages/elftools/elf/dynamic.py", line
> 32, in __init__
>     setattr(self, entry.d_tag[3:].lower(),
> dynstr.get_string(self.entry.d_val))
> AttributeError: 'NoneType' object has no attribute 'get_string'
> *         >> Appending modprobed cpio data...

This is not this bug, but a new one (where lddtree fails for some python reason).
Open a new bug along with output from genkernel --debug and the genkernel log.
Comment 36 Juergen Rose 2013-04-21 10:30:32 UTC
(In reply to comment #35)
> (In reply to comment #34)
> > I masked 3.4.45 and can confirm that sys-kernel/genkernel-3.4.44.2 emerges
> > with pax-utils-0.7. I haven't had any problems.
> 
> And there we go again.
> 
> Genkernel never had any problem to merge with newer pax-utils, it is a
> *RUNTIME PROBLEM* resulting in genkernel generating a broken initramfs for
> some people!
> 
> This is not something that will be fixed by masking and unmasking, only by
> either using -9999 (where it is fixed) or waiting for a new release.
> 
> (In reply to comment #27)
> > *         >> Appending blkid cpio data...
> > Traceback (most recent call last):
...
> > AttributeError: 'NoneType' object has no attribute 'get_string'
> > *         >> Appending modprobed cpio data...
> 
> This is not this bug, but a new one (where lddtree fails for some python
> reason).
> Open a new bug along with output from genkernel --debug and the genkernel
> log.

I.e., it is better to mask >=pax-utils-0.6 than to mask >genkernel-3.4.44.2 to avoid the complaining from 'emerge -uvND world'?
Comment 37 Juergen Rose 2013-04-21 14:21:58 UTC
If I only mask >pax-utils-0.5, 'emerge -uvDN genkernel' fails with:

root@lynx:/root(48)# emerge -pvuND genkernel

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] sys-kernel/genkernel-3.4.45  USE="crypt -cryptsetup (-ibm) (-selinux)" 0 kB
[ebuild     U  ] sys-apps/texinfo-5.1 [4.13-r2] USE="nls -static" 0 kB
[ebuild     U  ] media-libs/fontconfig-2.10.2:1.0 [2.9.0:1.0] USE="doc -static-libs" 0 kB
[blocks B      ] =app-misc/pax-utils-0.5 ("=app-misc/pax-utils-0.5" is blocking sys-kernel/genkernel-3.4.45)

Total: 3 packages (2 upgrades, 1 new), Size of downloads: 0 kB
Conflict: 1 block (1 unsatisfied)

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:



If I mask >pax-utils-0.5 and =sys-kernel/genkernel-3.4.45, 'emerge -uvDN genkernel' fails with:

root@lynx:/root(50)# emerge -pvuND genkernel

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] sys-kernel/genkernel-3.4.44.2  USE="crypt -cryptsetup (-ibm) (-selinux)" 0 kB
[ebuild     U  ] sys-apps/texinfo-5.1 [4.13-r2] USE="nls -static" 0 kB
[ebuild     U  ] media-libs/fontconfig-2.10.2:1.0 [2.9.0:1.0] USE="doc -static-libs" 0 kB
[blocks B      ] =app-misc/pax-utils-0.5 ("=app-misc/pax-utils-0.5" is blocking sys-kernel/genkernel-3.4.44.2)

Total: 3 packages (2 upgrades, 1 new), Size of downloads: 0 kB
Conflict: 1 block (1 unsatisfied)



If I mask >=sys-kernel/genkernel-3.4.44.2, 'emerge -uvDN genkernel' fails with a similar error. What to do?
Comment 38 Juergen Rose 2013-04-21 15:22:18 UTC
Masking =sys-kernel/genkernel-3.4.45 and >=app-misc/pax-utils-0.5 seems to work.
Comment 39 Ling Kun 2013-04-28 02:39:52 UTC
The latest portage also have version conflict:

[ebuild     UD ] app-misc/pax-utils-0.5 [0.7]
[ebuild  N     ] sys-kernel/genkernel-3.4.45  USE="-crypt -cryptsetup (-ibm) (-selinux)" 
[blocks B      ] =app-misc/pax-utils-0.5 ("=app-misc/pax-utils-0.5" is blocking sys-kernel/genkernel-3.4.45)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (sys-kernel/genkernel-3.4.45::gentoo, ebuild scheduled for merge) pulled in by
    genkernel

  (app-misc/pax-utils-0.5::gentoo, ebuild scheduled for merge) pulled in by
    >=app-misc/pax-utils-0.1.17 required by (sys-apps/portage-2.1.11.62::gentoo, installed)
    <app-misc/pax-utils-0.6 required by (sys-kernel/genkernel-3.4.45::gentoo, ebuild scheduled for merge)
    >=app-misc/pax-utils-0.2.1 required by (sys-kernel/genkernel-3.4.45::gentoo, ebuild scheduled for merge)


Masking =sys-kernel/genkernel-3.4.45 and >=app-misc/pax-utils-0.5  +1
Comment 40 白川間瀬流 2013-04-28 10:50:34 UTC
> Masking =sys-kernel/genkernel-3.4.45 and >=app-misc/pax-utils-0.5  +1

Either that or

$ echo "app-misc/pax-utils -~amd64 -~x86" >> /etc/portage/package.accept_keywords
Comment 41 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-04-28 11:22:13 UTC
(In reply to comment #40)
> > Masking =sys-kernel/genkernel-3.4.45 and >=app-misc/pax-utils-0.5  +1
> 
> Either that or
> 
> $ echo "app-misc/pax-utils -~amd64 -~x86" >>
> /etc/portage/package.accept_keywords

You only need to mask >=app-misc/pax-utils-0.5 since that dependency atom exactly matches the versions which genkernel doesn't support. You don't need to mask =sys-kernel/genkernel-3.4.45 as that won't improve the situation. You can't rely on changing keywords since you then rely on the stabilization of pax-utils and introduce the chance you need to mask them instead in the future anyway. The first approach works just fine, no need to suggest any alternatives...

So, can we please limit discussion towards getting rid of the blocker?
Comment 42 Mike Auty (RETIRED) gentoo-dev 2013-04-28 16:01:43 UTC
I think we're really just waiting on the genkernel team to roll a new release.

Richard, you said you may be able to tag a new release in a few days, but that was at the start of April.  The patch has been in the genkernel source since early February, but there hasn't been another release since then.  It looks like it's been 5 months since the last release, whereas they used to be released almost monthly for the better part of a year.  Do we need more staff on the genkernel team?  What's the best to make progress here?
Comment 43 Richard Yao (RETIRED) gentoo-dev 2013-06-04 00:38:09 UTC
(In reply to Mike Auty from comment #42)
> I think we're really just waiting on the genkernel team to roll a new
> release.
> 
> Richard, you said you may be able to tag a new release in a few days, but
> that was at the start of April.  The patch has been in the genkernel source
> since early February, but there hasn't been another release since then.  It
> looks like it's been 5 months since the last release, whereas they used to
> be released almost monthly for the better part of a year.  Do we need more
> staff on the genkernel team?  What's the best to make progress here?

Being inundated by email, the best way to contact me is by highlighting me on IRC. Everyone on the genkernel team has obligations in other areas that tend to make them rather overextended, so more people would definitely help us work through bugs quickly.

Anyway, I have tagged genkernel 3.4.46 and it is in the main tree. It should fix this issue.
Comment 44 Craig Andrews gentoo-dev 2013-06-05 01:28:25 UTC
The genkernel-3.4.46.1.ebuild still contains this:

RDEPEND="${DEPEND}
                cryptsetup? ( sys-fs/cryptsetup )
                app-arch/cpio
                >=app-misc/pax-utils-0.2.1
                <app-misc/pax-utils-0.5
                !<sys-apps/openrc-0.9.9"

I thought the resolution of this bug would include removing the " <app-misc/pax-utils-0.5" part of the expression.

So in my opinion, this bug is not fixed.
Comment 45 Mike Auty (RETIRED) gentoo-dev 2013-06-06 20:12:59 UTC
You're quite right, I tested building a system that copies additional binaries (cryptsetup) using pax-utils-0.7 with genkernel-3.4.46.1 and it worked fine.  I've therefore bumped 3.4.46.1 to -r1 in the tree, which no longer features the restriction on a maximum version of pax-utils.  Hopefully this fixes this bug fully.
Comment 46 Thomas Deutschmann (RETIRED) gentoo-dev 2013-06-07 11:29:25 UTC
Created attachment 350336 [details]
emerge --info output from my failing system

Hi,

this doesn't work for me. On my system, after I upgraded to app-misc/pax-utils-0.7 and sys-kernel/genkernel-3.4.46.1-r1 I cleaned genkernel's cache in /var/temp/genkernel and regenerated the initramfs using "genkernel initramfs".

Then I rebooted the system.

The reboot failed, because mdadm was unable to assemble my RAID:
http://666kb.com/i/ceqmb2g7b64dlai0r.jpg

Booting from a normal, working initramfs on my system looks like:
http://666kb.com/i/ceqmbyhwaprw6ongb.jpg

genkernel output (from 'genkernel initramfs'):
# genkernel initramfs
* Gentoo Linux Genkernel; Version 3.4.46.1
* Running with options: initramfs

* Using genkernel.conf from /etc/genkernel.conf
* Sourcing arch-specific config.sh from /usr/share/genkernel/arch/x86_64/config.sh ..
* Sourcing arch-specific modules_load from /usr/share/genkernel/arch/x86_64/modules_load ..

* Linux Kernel 3.8.13 for x86_64...
* .. with config file /etc/kernels/kernel-config-x86_64-3.8.13
* busybox: >> Applying patches...
*           - 1.18.1-openvt.diff
*           - busybox-1.20.1-mdstart.patch
*           - busybox-1.20.2-glibc-sys-resource.patch
*           - busybox-1.7.4-signal-hack.patch
* busybox: >> Configuring...
* busybox: >> Compiling...
* busybox: >> Copying to cache...
* initramfs: >> Initializing...
*         >> Appending base_layout cpio data...
*         >> Appending auxilary cpio data...
*         >> Copying keymaps
*         >> Appending busybox cpio data...
*         >> Appending lvm cpio data...
*           LVM: Adding support (compiling binaries)...
* lvm: >> Applying patches...
*           - lvm2-2.02.72-no-export-dynamic.patch
* lvm: >> Configuring...
* lvm: >> Compiling...
*       >> Copying to bincache...
*         >> Appending mdadm cpio data...
* 		MDADM: Adding support (compiling binaries)...
* mdadm: >> Compiling...
*       >> Copying to bincache...
*         >> Appending luks cpio data...
* Including LUKS support
*         >> Appending modules cpio data...
*         >> Appending blkid cpio data...
*         >> Appending modprobed cpio data...
*         >> Compressing cpio data (.xz)...
Comment 47 Mike Auty (RETIRED) gentoo-dev 2013-06-07 19:34:31 UTC
Thomas, I suspect your problem is more likely a change in the version of the code used for mdadm between the previous version and the new one.  There's no indication that the mdadm binary cannot be found (which is what this issue is about).  You should file a new bug and assign it to the genkernel maintainers directly if possible.