Re: [gentoo-catalyst] catalyst related kernel problem?
On 21/02/08 05:40, Chris Gianelloni wrote: On Wed, 2008-02-20 at 21:38 +0100, lurker wrote: genkernel fails to add busybox with cpio (this is with genkernel-3.4.9 and catalyst-2.0.6_pre6): Please try catalyst-2.0.6_pre8, which is pretty new and should work just fine for whatever you need. Also, check out genkernel-3.4.10_pre3, which I literally just added to the tree. Also, my system runs stable amd64 Gentoo, but I run catalyst in a i686 chroot to protect my main system. Could that have anything to do with this? Ehh, this very well could be causing you all kinds of problems. I have now tried running catalyst-2.0.5 natively from my amd64 system (i.e. no chroot) and I still got the same error. Even with the latest genkernel. I emerged 2.0.6_pre9, but it crashed during action sequence clean on livecd-stage1, complaining about that the chroot's kerncache directory couldn't be deleted. I might file a bug for this later if I get time, it's just that I'm really pressed getting catalyst to actually build an iso as I have a release schedule... -- gentoo-catalyst@lists.gentoo.org mailing list
Re: [gentoo-catalyst] catalyst related kernel problem?
lurker wrote: On 21/02/08 05:40, Chris Gianelloni wrote: On Wed, 2008-02-20 at 21:38 +0100, lurker wrote: genkernel fails to add busybox with cpio (this is with genkernel-3.4.9 and catalyst-2.0.6_pre6): Please try catalyst-2.0.6_pre8, which is pretty new and should work just fine for whatever you need. Also, check out genkernel-3.4.10_pre3, which I literally just added to the tree. Also, my system runs stable amd64 Gentoo, but I run catalyst in a i686 chroot to protect my main system. Could that have anything to do with this? Ehh, this very well could be causing you all kinds of problems. I have now tried running catalyst-2.0.5 natively from my amd64 system (i.e. no chroot) and I still got the same error. Even with the latest genkernel. I emerged 2.0.6_pre9, but it crashed during action sequence clean on livecd-stage1, complaining about that the chroot's kerncache directory couldn't be deleted. I might file a bug for this later if I get time, it's just that I'm really pressed getting catalyst to actually build an iso as I have a release schedule... You must have a really weird setup. Again, as part of the release cycle, many of us have been testing the latest versions of catalyst and genkernel, and we have not hit this issue, either. Kerncache has been functioning beautifully for me. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- gentoo-catalyst@lists.gentoo.org mailing list
Re: [gentoo-catalyst] catalyst related kernel problem?
2008. 02. 24, vasárnap keltezéssel 11.12-kor Andrew Gaffney ezt írta: lurker wrote: On 21/02/08 05:40, Chris Gianelloni wrote: Hi, I'm new here but I have a little experience building livecd. Today I completed a customized livecd successfully, using: genkernel-3.4.10_pre3 catalyst-2.0.6_pre9 I use ~x86 Before I had some problems with genkernel, but those bugs are solved in the new releases. Cheers, István -- BSA. Mert megérdemlitek. Open Source. Mert megérdemlem. -- BSA. They value it. Open Source. The value. It. -- http://www.osbusiness.hu -- gentoo-catalyst@lists.gentoo.org mailing list
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 21/02/08 05:40, Chris Gianelloni wrote: On Wed, 2008-02-20 at 21:38 +0100, lurker wrote: genkernel fails to add busybox with cpio (this is with genkernel-3.4.9 and catalyst-2.0.6_pre6): Please try catalyst-2.0.6_pre8, which is pretty new and should work just fine for whatever you need. Also, check out genkernel-3.4.10_pre3, which I literally just added to the tree. Also, my system runs stable amd64 Gentoo, but I run catalyst in a i686 chroot to protect my main system. Could that have anything to do with this? Ehh, this very well could be causing you all kinds of problems. Alright, but what (and why) exactly? I used this setup flawlessly for months before this error came out of nowhere. I'm not sure what I did for it to start appearing in the first place. Since catalyst does all of its building in storedir or /var/tmp/catalyst, by default. In fact, it won't do anything outside of /var/tmp/catalyst, and then each target is built in a chroot, also. So, building a typical package with default settings, you end up extracting to /var/tmp/catalyst/tmp, then chrooting into there, before anything else is done. Again, it is safe to run on your main install. The only files it cares about from your running system are all in /etc/catalyst or /var/tmp/catalyst and nowhere else, unless you configure it to do so. When I set up that chroot I didn't know that catalyst was able to generate x86 stages from amd64 systems, so that was my reason for creating it. I will install catalyst and genkernel on my main system instead and work from there, and if that fails upgrading to the latest versions. 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. -- gentoo-catalyst@lists.gentoo.org mailing list
Re: [gentoo-catalyst] catalyst related kernel problem?
lurker wrote: When I set up that chroot I didn't know that catalyst was able to generate x86 stages from amd64 systems, so that was my reason for creating it. I will install catalyst and genkernel on my main system instead and work from there, and if that fails upgrading to the latest versions. You don't need genkernel on your host system. It's emerged inside catalyst's chroot when it's needed. 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. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- gentoo-catalyst@lists.gentoo.org mailing list
Re: [gentoo-catalyst] catalyst related kernel problem?
On 08/01/08 15:46, Åsmund Grammeltvedt wrote:
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.
Now I'm constantly plagued by this hickup. I did my homework and
investigated this in depth.
I'm not sure this is completely the same as what Åsmund described
elsewhere in this thread. For me the hard links in /bin (of the
initramfs) to /bin/busybox works. The problem is that /bin/busybox is empty.
I dived into the code, focusing on how genkernel and catalyst works
together, and especially how genkernel generate the initramfs. After
patching in some primitive print_info debugging I discovered that
genkernel fails to add busybox with cpio (this is with genkernel-3.4.9
and catalyst-2.0.6_pre6):
In append_busybox() in genkernel-3.4.9/gen_initramfs.sh:36, busybox is
appended to the initramfs on line 101, which looks like this:
find . -print | cpio ${CPIO_ARGS} --append -F ${CPIO}
I added debug prints of the size of the current initramfs (i.e. ${CPIO})
both before and after the above command, and it turns out that only 2048
bytes of data is added. Since the busybox executable that _should_ be
added at that time is 1080 Kb big, it's obviously here everything goes
wrong which was confirmed by extracting it. /bin/busybox is just and
empty executable. This happens no matter if I use kerncache or not.
Also, I have confirmed that there is a good busybox executable in ./bin
from the directory the above command runs from.
But why? When I do the exact same series of commands manually myself it
works. Obviously most people doesn't experience this problem either so
it has to be something with my system. Add to this the randomness of the
problem, that it works sometimes.
I would _really_ appreciate any input on this. I will gladly do any sort
of debugging if you just give my a few pointers on where to look and
what to do cause I'm completely lost now.
Also, my system runs stable amd64 Gentoo, but I run catalyst in a i686
chroot to protect my main system. Could that have anything to do with this?
--
gentoo-catalyst@lists.gentoo.org mailing list
Re: [gentoo-catalyst] catalyst related kernel problem?
On Sat, 2008-01-12 at 02:20 +0100, lurker wrote: 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. After upgrading to busybox-1.8.2 I've not experienced this any more. Perhaps it's just a coincidence due to the random nature of this problem. Are you talking about the host system or in your genkernel.conf ? -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-catalyst] catalyst related kernel problem?
On 12/01/08 17:49, Chris Gianelloni wrote: On Sat, 2008-01-12 at 02:20 +0100, lurker wrote: 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. After upgrading to busybox-1.8.2 I've not experienced this any more. Perhaps it's just a coincidence due to the random nature of this problem. Are you talking about the host system or in your genkernel.conf ? What I did was simply to add busybox-1.8.2 to the stage3 build, then rebuild the livecd stages and generate the iso. But now I realise that it probably doesn't have anything to do with what genkernel do later on (?) as genkernel seems to use its own busybox (version 1.1.3) which is uses for its initrd images. So I guess I just was lucky... -- gentoo-catalyst@lists.gentoo.org mailing list
Re: [gentoo-catalyst] catalyst related kernel problem?
On Sat, 2008-01-12 at 18:15 +0100, lurker wrote: On 12/01/08 17:49, Chris Gianelloni wrote: On Sat, 2008-01-12 at 02:20 +0100, lurker wrote: 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. After upgrading to busybox-1.8.2 I've not experienced this any more. Perhaps it's just a coincidence due to the random nature of this problem. Are you talking about the host system or in your genkernel.conf ? What I did was simply to add busybox-1.8.2 to the stage3 build, then rebuild the livecd stages and generate the iso. But now I realise that it probably doesn't have anything to do with what genkernel do later on (?) as genkernel seems to use its own busybox (version 1.1.3) which is uses for its initrd images. So I guess I just was lucky... Well, sometimes luck counts... =] -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-catalyst] catalyst related kernel problem?
On 08/01/08 15:46, Åsmund Grammeltvedt wrote: 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. After upgrading to busybox-1.8.2 I've not experienced this any more. Perhaps it's just a coincidence due to the random nature of this problem. -- gentoo-catalyst@lists.gentoo.org mailing list
[gentoo-catalyst] catalyst related kernel problem?
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 know this might very well be something linux kernel specifig and thus not a catalyst issue, but, as I said, I only seem to enounter it while using catalyst to build the system and never otherwise. Does anyone have some input on this? If relevant, I'm running gentoo-sources-2.6.23-r3 with the attached config, and these are the catalyst spec files I use (but I have had the same problem with other similar configs/specs): https://tor-svn.freehaven.net/svn/incognito/trunk/arch/x86/livecd-stage1.spec https://tor-svn.freehaven.net/svn/incognito/trunk/arch/x86/livecd-stage2.spec Cheers! # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-gentoo-r3 # Mon Jan 7 18:51:24 2008 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y # CONFIG_KALLSYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y # CONFIG_BUG is not set # CONFIG_ELF_CORE is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_HPET_TIMER=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set # CONFIG_X86_UP_APIC is not set # CONFIG_X86_MCE is not set
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] catalyst related kernel problem?
Åsmund Grammeltvedt wrote: 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. It would be nice if you would file a bug about this with as much information as you have. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- gentoo-catalyst@lists.gentoo.org mailing list
Re: [gentoo-catalyst] catalyst related kernel problem?
On 08/01/08 15:46, Åsmund Grammeltvedt wrote: 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. Interesting. Care to share any of the details? I'm not as well-versed in catalys as I would like.. -- gentoo-catalyst@lists.gentoo.org mailing list
