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
Maybe this is related? http://forums.gentoo.org/viewtopic-p-7219378.html
(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.
This one snagged me as well.
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.
+1 broke my system completely. bugs like this should be solven within hours, instead of days/weeks ;)
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...
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.
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.
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...
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.
(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
*** Bug 453522 has been marked as a duplicate of this bug. ***
(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.
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.
(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.
(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"
(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)?
after nearby one month, there is a fix now in portage for it in sight?
(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.
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*
(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.
*** Bug 464334 has been marked as a duplicate of this bug. ***
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
*** Bug 465760 has been marked as a duplicate of this bug. ***
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/ ...
(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).
(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.
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.
* 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.
pax-utils-0.7 works for me? how can i tast further?
to remove dep on 0.5 so i can upgrade other things i installed genkernel with --nodeps but thats break emerge -DuN @world
afaik, there's nothing for me (pax-utils) to do here, so un-cc myself
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)
(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.
(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.
(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'?
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?
Masking =sys-kernel/genkernel-3.4.45 and >=app-misc/pax-utils-0.5 seems to work.
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
> 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
(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?
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?
(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.
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.
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.
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)...
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.