Re: [gentoo-catalyst] catalyst related kernel problem?
On Thursday 21 February 2008, lurker wrote: On 21/02/08 18:55, Andrew Gaffney wrote: lurker wrote: But even if that fixes it, I would very much like to know what was going on. From my debugging I have pretty much confirmed that it's that find/cpio call that fails, but I cannot grasp why at all. Few bugs have left me this perplexed. We are right in the middle of a release cycle with a couple of people doing repeated catalyst builds, and nobody is hitting this bug. I know. I've had this problem since ~november, and the only other person that have reported something similar is Åsmund. It would be interesting if he could elaborate on the circumstances he got it in... I did, in fact, get it building i686 on an amd64 platform. Everything worked perfectly until, I assume, I updated my portage snapshot. I can't recall having done anything else that should affect the build, but since I could work around the problem when I located it, I didn't take the time to investigate further (or submit a bug, since I felt there were too many potential factors at the time). -- Åsmund Grammeltvedt Snap TV signature.asc Description: This is a digitally signed message part.
Re: [gentoo-catalyst] catalyst related kernel problem?
On Tuesday 08 January 2008 15:34:09 lurker wrote: Greetings, Often when I build systems with catalyst I encounter the following kernel freeze after the boot loader has completed: [ ... lots of kernel loading stuff which seems ok ... ] Freeing unused kernel memory: 172k freed request_module: runaway loop modprobe binfmt- request_module: runaway loop modprobe binfmt- request_module: runaway loop modprobe binfmt- request_module: runaway loop modprobe binfmt- request_module: runaway loop modprobe binfmt- I had an issue with the same symptoms. It turned out that after some builds, the initramfs would contain empty files instead of links to busybox. In my case, the only way I could get it to work consistently was to patch genkernel to use symbolic links instead, when setting up the initramfs. -- Åsmund Grammeltvedt Snap TV signature.asc Description: This is a digitally signed message part.
Re: [gentoo-catalyst] Zero-sized busybox binaries in livecd stage2
On Thursday 04 October 2007 14:01:57 Åsmund Grammeltvedt wrote:
On Wednesday 03 October 2007 14:05:15 Andrew Gaffney wrote:
You should try using _pre3, because
we always need testing :) Also, most of those 0-length files are
supposed to be symlinks to /bin/busybox. Do you have a /bin/bb?
I added some debug lines to the end of append_busybox in gen_initramfs.sh:
--- genkernel.orig/gen_initramfs.sh 2007-10-04 10:30:39.679681270 +0200
+++ genkernel/gen_initramfs.sh 2007-10-08 10:42:40.916698573 +0200
@@ -55,7 +55,9 @@
done
cd ${TEMP}/initramfs-busybox-temp/
+ find . -ls
find . -print | cpio ${CPIO_ARGS} --append -F ${CPIO}
+ cat ${CPIO} | cpio --verbose -t
rm -rf ${TEMP}/initramfs-busybox-temp /dev/null
}
This gives the following result. Looks like something strange is happening with
the hardlinks. Any ideas?
16112031500 drwxr-xr-x 3 root root 16 Oct 5 15:34 .
18794096540 drwxr-xr-x 2 root root 63 Oct 5 15:34 ./bin
18794096554 -rwxr-xr-x 1 root root 396 Oct 5 15:34
./bin/udhcpc.scripts
1879409656 456 -rw-r--r-- 1 root root 462914 Oct 5 15:34
./bin/busybox.tar.bz2
1879409657 900 -rwxr-xr-x 8 root root 921344 Oct 3 16:02
./bin/busybox
1879409657 900 -rwxr-xr-x 8 root root 921344 Oct 3 16:02 ./bin/[
1879409657 900 -rwxr-xr-x 8 root root 921344 Oct 3 16:02 ./bin/ash
1879409657 900 -rwxr-xr-x 8 root root 921344 Oct 3 16:02 ./bin/sh
1879409657 900 -rwxr-xr-x 8 root root 921344 Oct 3 16:02
./bin/mount
1879409657 900 -rwxr-xr-x 8 root root 921344 Oct 3 16:02
./bin/uname
1879409657 900 -rwxr-xr-x 8 root root 921344 Oct 3 16:02
./bin/echo
1879409657 900 -rwxr-xr-x 8 root root 921344 Oct 3 16:02 ./bin/cut
drwxr-xr-x 11 root root0 Oct 5 15:34 .
drwxr-xr-x 2 root root0 Oct 5 15:34 dev
crw-rw 1 root root 5, 1 Oct 5 15:34 dev/console
crw-rw 1 root root 1, 3 Oct 5 15:34 dev/null
crw--- 1 root root 4, 1 Oct 5 15:34 dev/tty1
drwxr-xr-x 2 root root0 Oct 5 15:34 bin
drwxr-xr-x 2 root root0 Oct 5 15:34 etc
-rw-r--r-- 1 root root 97 Oct 5 15:34 etc/fstab
drwxr-xr-x 4 root root0 Oct 5 15:34 usr
drwxr-xr-x 2 root root0 Oct 5 15:34 usr/bin
drwxr-xr-x 2 root root0 Oct 5 15:34 usr/sbin
drwxr-xr-x 2 root root0 Oct 5 15:34 proc
drwxr-xr-x 2 root root0 Oct 5 15:34 temp
drwxr-xr-x 2 root root0 Oct 5 15:34 sys
drwxr-xr-x 3 root root0 Oct 5 15:34 var
drwxr-xr-x 3 root root0 Oct 5 15:34 var/lock
drwxr-xr-x 2 root root0 Oct 5 15:34 var/lock/dmraid
drwxr-xr-x 2 root root0 Oct 5 15:34 sbin
lrwxrwxrwx 1 root root3 Oct 5 15:34 lib64 - lib
drwxr-xr-x 5 root root0 Oct 5 15:34 .
drwxr-xr-x 2 root root0 Oct 5 15:34 etc
-rwxr-xr-x 1 root root21679 Oct 5 15:34 etc/initrd.scripts
-rwxr-xr-x 1 root root 1705 Oct 5 15:34 etc/initrd.defaults
drwxr-xr-x 2 root root0 Oct 5 15:34 sbin
-rwxr-xr-x 1 root root 2300 Oct 5 15:34 sbin/modprobe
lrwxrwxrwx 1 root root7 Oct 5 15:34 sbin/init - ../init
-rwxr-xr-x 1 root root19245 Oct 5 15:34 init
lrwxrwxrwx 1 root root4 Oct 5 15:34 linuxrc - init
drwxr-xr-x 3 root root0 Oct 5 15:34 lib
drwxr-xr-x 2 root root0 Oct 5 15:34 lib/keymaps
-rwxr-xr-x 2 505 users 0 May 12 2001 lib/keymaps/1.map
-rwxr-xr-x 2 505 users2823 May 12 2001 lib/keymaps/azerty.map
-rwxr-xr-x 2 505 users 0 May 12 2001 lib/keymaps/2.map
-rwxr-xr-x 2 505 users2823 May 12 2001 lib/keymaps/be.map
-rwxr-xr-x 2 505 users 0 May 12 2001 lib/keymaps/3.map
-rwxr-xr-x 2 505 users2823 May 12 2001 lib/keymaps/bg.map
-rwxr-xr-x 2 505 users 0 May 12 2001 lib/keymaps/4.map
-rwxr-xr-x 2 505 users2823 May 12 2001 lib/keymaps/br-a.map
-rwxr-xr-x 2 505 users 0 May 12 2001 lib/keymaps/5.map
-rwxr-xr-x 2 505 users2823 May 12 2001 lib/keymaps/br-l.map
-rwxr-xr-x 2 505 users 0 May 12 2001 lib/keymaps/6.map
-rwxr-xr-x 2 505 users2823 May 12 2001 lib/keymaps/by.map
-rwxr-xr-x 2 505 users 0 May 12 2001 lib/keymaps/7.map
-rwxr-xr-x 2 505 users2823 May 12 2001 lib/keymaps/cf.map
-rwxr-xr-x 2 505 users 0 May 12 2001 lib/keymaps/8.map
-rwxr-xr-x 2 505 users2823 May 12 2001 lib/keymaps/croat.map
-rwxr-xr-x 2 505
Re: [gentoo-catalyst] Missing /root
On Wednesday 19 September 2007 18:24:33 Chris Gianelloni wrote: On Wed, 2007-09-19 at 17:23 +0200, Åsmund Grammeltvedt wrote: However, it may just create it with USE=build. Check the vdb in your stage1 to see what package owns the /root directory. ccache, apparently. Baselayout _should_ also create /root, but something seems to go wrong along the way. I guess I should rebuild and check the logs. Please do. If you find it to be an issue with baselayout, please file a bug so we can get it fixed before we start our next release. Hm, I haven't had time to actually check if this happens, but the current theory is this: Baselayout creates /root, but avoids becoming the owner by generating /usr/share/baselayout/mkdirs.sh and then running it in pkg_preinst. When ccache is unmerged at the end of the stage build, it removes /root, since its the sole owner. Does that seem plausible? -- Åsmund Grammeltvedt Snap TV signature.asc Description: This is a digitally signed message part.
Re: [gentoo-catalyst] Missing /root
On Wednesday 03 October 2007 14:00:58 Andrew Gaffney wrote: Åsmund Grammeltvedt wrote: On Wednesday 19 September 2007 18:24:33 Chris Gianelloni wrote: On Wed, 2007-09-19 at 17:23 +0200, Ã…smund Grammeltvedt wrote: However, it may just create it with USE=build. Check the vdb in your stage1 to see what package owns the /root directory. ccache, apparently. Baselayout _should_ also create /root, but something seems to go wrong along the way. I guess I should rebuild and check the logs. Please do. If you find it to be an issue with baselayout, please file a bug so we can get it fixed before we start our next release. Hm, I haven't had time to actually check if this happens, but the current theory is this: Baselayout creates /root, but avoids becoming the owner by generating /usr/share/baselayout/mkdirs.sh and then running it in pkg_preinst. When ccache is unmerged at the end of the stage build, it removes /root, since its the sole owner. Does that seem plausible? Sure, that explanation is very plausible. Since ccache isn't enabled by default and most of us don't use it for release building, we never would have seen it. It may even be the reason that wolf31o2 recommends that it not be used. In that case, may I suggest the following? :) --- catalyst-2.0.5_pre3.orig/files/catalyst.conf2007-10-03 14:23:34.060538959 +0200 +++ catalyst-2.0.5_pre3/files/catalyst.conf 2007-10-03 14:24:07.503755367 +0200 @@ -31,7 +31,7 @@ # the -a option to the catalyst cmdline. -p will clear the autoresume flags # as well as your pkgcache and kerncache # ( This option is not fully tested, bug reports welcome ) -# ccache = enables build time ccache support (highly recommended) +# ccache = enables build time ccache support (not recommended) # distcc = enable distcc support for building. You have to set distcc_hosts in # your spec file. # kerncache = keeps a tbz2 of your built kernel and modules (useful if your -- Åsmund Grammeltvedt Snap TV signature.asc Description: This is a digitally signed message part.
Re: [gentoo-catalyst] Zero-sized busybox binaries in livecd stage2
On Wednesday 03 October 2007 14:05:15 Andrew Gaffney wrote: You should try using _pre3, because we always need testing :) Heh, I did take a quick look at pre3 earlier, but it actually crashed when building busybox. If I'm lucky, it's even related to my problems. If not, you'll at least get another bug. :) Also, most of those 0-length files are supposed to be symlinks to /bin/busybox. Do you have a /bin/bb? Nope, those files are it. -- Åsmund Grammeltvedt Snap TV signature.asc Description: This is a digitally signed message part.
Re: [gentoo-catalyst] Missing /root
On Wednesday 03 October 2007 16:12:29 Andrew Gaffney wrote: I just tried to reproduce it with a stage3-amd64-2007.0, and I can't. The only reason is that there is a .keep file in /root, which was put there by baselayout's mkdirs.sh script. Unless something has changed with baselayout in the tree since the 2007.0 snapshot, your problem lies elsewhere. Looking at the current stable in the tree (1.12.9-r2), it still does 'kdir /root' unconditionally. Are you using baselayout-2 or something? Great, now I can't reproduce it either. I disabled ccache, rebuilt the stages and observed that /root was present. However, after re-enabling ccache, /root's still there. Odd, but at least it works for me now. -- Åsmund Grammeltvedt Snap TV signature.asc Description: This is a digitally signed message part.
Re: [gentoo-catalyst] Missing /root
On Wednesday 19 September 2007 18:24:33 Chris Gianelloni wrote: On Wed, 2007-09-19 at 17:23 +0200, Åsmund Grammeltvedt wrote: However, it may just create it with USE=build. Check the vdb in your stage1 to see what package owns the /root directory. ccache, apparently. Baselayout _should_ also create /root, but something seems to go wrong along the way. I guess I should rebuild and check the logs. Please do. If you find it to be an issue with baselayout, please file a bug so we can get it fixed before we start our next release. Also, are you using baselayout-2 or the latest stable? 1.12.9-r2. -- Åsmund Grammeltvedt Snap TV signature.asc Description: This is a digitally signed message part.
[gentoo-catalyst] Missing /root
Hi. I just noticed that /root is missing from my stage3 (stage 2 as well. It's present in stage1). Do I need to take some special care in order to have it show up? -- Åsmund Grammeltvedt Snap TV signature.asc Description: This is a digitally signed message part.
Re: [gentoo-catalyst] Missing /root
On Wednesday 19 September 2007 17:02:50 Andrew Gaffney wrote: Åsmund Grammeltvedt wrote: Hi. I just noticed that /root is missing from my stage3 (stage 2 as well. It's present in stage1). Do I need to take some special care in order to have it show up? I thought that baselayout owned it, but it doesn't appear that it does (on my local system). It appears that baselayout has some workarounds related to this: http://bugs.gentoo.org/show_bug.cgi?id=9849, causing it to create but not own the files. However, it may just create it with USE=build. Check the vdb in your stage1 to see what package owns the /root directory. ccache, apparently. Baselayout _should_ also create /root, but something seems to go wrong along the way. I guess I should rebuild and check the logs. -- Åsmund Grammeltvedt Snap TV signature.asc Description: This is a digitally signed message part.
Re: [gentoo-catalyst] libtool dependencies in stage3
On Tuesday 28 August 2007 16:32:39 Mike Frysinger wrote: On Tuesday 28 August 2007, Åsmund Grammeltvedt wrote: Still, is it impossible for features to carry over from packages in the bootstrap stage and affecting depending packages before the dependency is reemerged, without this being a bug in the depending package? speaking generally, probably ... but here, it is a bug in attr, pure and simple ... it should not be using the host libtool Ok, I'm mostly trying to justify messing with /var/db/pkg to myself. Cleaning it out and bootstrapping from there seems like it would reduce the impact of such bugs. -- Åsmund Grammeltvedt Snap TV signature.asc Description: This is a digitally signed message part.
Re: [gentoo-catalyst] libtool dependencies in stage3
On Tuesday 28 August 2007 19:56, Chris Gianelloni wrote: On Tue, 2007-08-28 at 10:51 -0400, Mike Frysinger wrote: On Tuesday 28 August 2007, Åsmund Grammeltvedt wrote: On Tuesday 28 August 2007 16:32:39 Mike Frysinger wrote: On Tuesday 28 August 2007, Åsmund Grammeltvedt wrote: Still, is it impossible for features to carry over from packages in the bootstrap stage and affecting depending packages before the dependency is reemerged, without this being a bug in the depending package? speaking generally, probably ... but here, it is a bug in attr, pure and simple ... it should not be using the host libtool Ok, I'm mostly trying to justify messing with /var/db/pkg to myself. Cleaning it out and bootstrapping from there seems like it would reduce the impact of such bugs. then you'd hit things like portage going crazy over package collisions ... or in the scenario where the older stage had an older version and the newer version has different files so you're left with orphaned cruft ... Correct. There is a reason that we moved *away* from removing the /var/db/pkg stuff for stage1. This is it. I see. Thanks for the clarifications! -- Åsmund Grammeltvedt Snap TV -- [EMAIL PROTECTED] mailing list
